分类目录归档:工作

初识 Python(二):字符串

继续学习 Python 的基础。字符串是编程语言中经常处理的数据类型,Python 中的字符串可以使用单引号作为开始和结束的起止符表示,也可以使用双引号作为开始和结束的起止符表示,不少其他的编程语言也采用这样的方式来表示字符串。

对于一个字符串中本来就包含有单引号时,使用双引号会方便一些,不用使用转义符,其他两者并无不同,使用主要看个人喜好,我比较喜欢使用双引号。

转义符在各个编程语言中都有,反斜杠后面跟需要转义的字符,常见的需要转义的字符有单引号、双引号、制表符 「\t」、换行符 「\n」等等。

除此之外, Python 还有三引号作为字符串的起止符,三引号常用于多行字符串,三个单引号和三个双引号都可以,三引号起止符之间的字符串中的所有空格、引号、制表符和换行符都会被当作字符串的一部分。三引号也可以作为多行注释。

在字符串起始的引号前加小写字母「 r 」,将忽略该引号中字符串里所有的转义字符,也就是你引号中的字符串是什么它就是什么,同样的支持单引号、双引号、三引号。

对字符串的操作就像列表一样,可以用下标,同样也可以对字符串实行切片操作,切片操作使用「字符串[m:n]」来完成。

比较常见的字符串方法。

字符大小写转换相关的方法 upper()、lower()、isupper()、islower(),其中前两个是能够将字符串全部变成大写和全部变成小写的两个方法,需要注意的是调用该方法并不会改变原有的字符串,而是生成了新的字符串;后两个方法分别判断字符串是否全部为大写或全部为小写,返回 True 或 Flase。

isupper() 和 islower() 还有一些弟弟妹妹们:

isalpha() 如果字符串中只包含字母并且不为空,对字符串调用这个方法会返回 True 。

isalnum() 如果字符串中只包含字母和数字并且不为空,对字符串调用这个方法会返回 True 。

isdecimal() 如果字符串中只包含数字并且不为空,对字符串调用这个方法会返回 True 。

istitle() 如果字符串每个词的首字母大写后面为小写并且不为空,对字符串调用这个方法会返回 True 。

字符串的连接和拆分是字符串编程中常见的操作,Python 中的字符串拆分跟很多其他编程语言类似,都是使用split() 方法,使用 split() 可以将字符串拆分成列表。字符串连接的方法使用 join() ,这让我一下想起了 SQL 中的left join 和 right join ,对字符串使用 join() 可以连接字符串。

去除字符串前后的空格也是字符串编程中常见的,Python 中使用 strip() 、lstrip() 、 rstrip() 方法取出字符串前后的空格,strip 去除首尾空格,lstrip 去除字符串首部空格,rstrip 去除尾部空格。

Python 还提供了字符串对齐的方法,这个比较有意思,分别是用于左对齐的 ljust(),用于右对齐的 rjust() 何由居中对齐的 center()。 对齐方法有两个参数,第一个参数是对齐的长度,第二个参数是用于填充对齐中空白的字符。

还有比较字符串开头和结尾是否一致的方法,分别是 startswith() 和 endswith(),可以检查字符串的头尾是否和预期的一致。

Python 中提供了不少的字符串的方法,这门编程语言对于文本处理应该是比较强大的,再配合起第三方的模块应该比较强悍,继续学习。

相关阅读

初识 Python(一)

本文首发于我的微信公众账号「时间易逝」,欢迎订阅我的微信公众账号
在微信中搜索「doevents」或用微信扫描页面右上方二维码可订阅我的微信公众账号

初识 Python(一)

人生苦短,该学学 Python ,花时间看了看 Python 基础性的内容,做个记录。

Python 是一门解释性、面向对象、动态数据类型的高级程序设计语言。

代码块间无花括号,也没有诸如 begin…end 的开始结束分隔符,每条语句也不需要用分号作为结束,以自然换行为一条语句。同一层次的代码块用缩进来区分,简洁干净。

基础数据类型同其他程序设计语言,如整型、浮点型、字符串、布尔型。

操作符也很类似,其中 * 操作符比较有意思,除了作为乘法操作符外,在用于字符串和整型值时,这个操作符就变成了字符串复制符。

比如在命令行 >>> 后输入 China * 3 回车键后会复制 China 这个字符串 3 次,输出显示。

操作符 ** 可以用于求指数,操作符 // 用于整除。

流程控制跟其他程序设计语言差不多,if 、while 、for 这些都是有的。

用 def 关键字后跟函数名和参数完成函数的定义,比如定义一个函数 say_hello ,打印输出一行字符串。

def say_hello(name):
print('Hi, ' + name)

#调用 say_hello 函数
say_hello('Eric')

江湖中之所以有「人生苦短,我用 Python」的说法,是因为 Python 有大量的库可供使用,不必重复制造轮子,使用 import 关键字引入这些库的模块即可,好像 Java 也是这么干的 ,也有些类似 C# 的 using 。

异常处理使用 try…except 来完成。

有三个数据类型值得注意,它们分别是列表、元组、字典。

列表「list」是一个值的序列,有点类似其他程序设计语言中的数组,是一种以下标 0 开始的有序值的集合,这些有序值称为列表项。针对列表有一些操作,如以切片的方式获得子列表,增加列表项,插入列表项,删除列表项,排序等。可以视列表为一个「可变的」数据类型。列表使用方括号 []定义。

元组「tuple」跟列表很类似,所不同的是元组用圆括号()定义,另外比较重要的是元组初始化后是不可改变的。

字典「dict」也是一种多值的集合,与列表相比,字典的索引「下标」可以使用多种不同的数据类型,在字典中索引「下标」被称为键,字典是一种键值对的多值集合数据类型。另外,字典是非有序的。字典使用花括号{}定义。

以上是对 Python 的一些初步认识,学习一门程序设计语言唯一的方法就是将这门程序设计语言在实际项目中投入使用,通过使用中的刻意练习获得提高。把一门程序设计语言学到用它可以进行专职工作可能需要不短的时间,但是学会它并简单的写一点能够替代重复性工作的代码还是相对较容易的。

本文首发于我的微信公众账号「时间易逝」,欢迎订阅我的微信公众账号
在微信中搜索「doevents」或用微信扫描页面右上方二维码可订阅我的微信公众账号

怎样提高开发速度

软件产品想在市场上获得竞争力,开发速度是克敌制胜的重要因素之一。基于此,在产品开发的过程中,速度是每个团队都会重点关注的指标之一,每个团队都在极力想办法提升产品开发的速度,以便在市场的赛道上奔跑中领先那么一半个身位。从我自己的角度来看,我会尝试关注以下 6 方面的工作,这可能会对团队提高开发速度带来一些帮助。

及时清理技术债务,技术债务对团队生产率的影响是非常大的。技术债务很容易产生,产生后往往又不是一个能够快速修正的工作,当技术债务积累过多时,常常会花费数月乃至数年来偿还。避免产生技术债务需要优先考虑代码质量,实际中很多团队为追求开发速度往往并不注重代码的质量,或许开始能够在赛道上领先,但在整个赛程中,随着积累的技术债务,开发速度会越来越慢,直到花费巨大的成本偿还这些债务,这个阶段往往也是模仿者/追随者弯道超车的好时机。一开始就保持时时清理技术债务从整体是会提高开发速度的,毕竟开发是伴随着整个产品的生命周期而时刻在进行的一项工作。

技术债务并不是那么容易清理,依赖于技能水平与经验,但总可以从最简单的开始。比如,当发现有重复性代码的时候,可能就产生了技术债务,对这些重复的代码进行重构,既避免了技术债务的生成,又提高了自己的技能。伴随着勤快处理问题和系统演进中的即时重构除了能够降低技术债务的累积,也是提高个人竞争力的一条道路。

提高客户参与度,开发人员往往不具备客户领域内的知识,碰到需要客户解答的领域内问题时,要么等待,要么猜测,这么一来一往之中,会拖延开发的速度。提高客户参与度,有能够随时回答开发人员问题的客户,无疑会提高开发速度。

让客户参与进来往往并不那么容易,在这方面往常中采取的措施是引入行业领域内的专家,或者把整个团队进驻到客户所在的场地,通过这种方式来提高客户参与度往往会增加一定的成本,但相比缺乏领域知识造成的开发效率低下和不专业性无疑是值得的。另外一种做法是用专人往复于客户与团队之间传递这些领域内的知识,效果取决于这个专人横向的认知广度和纵向认知的深度,在以前可能由项目经理承担这个角色,现在更多会设置产品经理岗位。

精力充沛的工作,疲倦会带来成本高昂的错误,同时疲倦也会让人难以全力以赴地工作,长时间的加班是极不可取的。短暂的透支一下精力是可能的,长期透支则代表应该寻找问题的根源了。试试在单位时间的使用上投入更多的关注,这样或许会更好一些。加班普遍的现象有一部分原因是实际上投入工作的时间并没有那么长,拉长的时间线在补充了实际工作时间的同时很容易让人精力不济。

减少对开发人员的干扰,尽量将非开发的工作交给其他能完成的人来完成,减少不必要的会议,在产品开发进行中时,跟产品开发无关的事交由另外的人处理,比如行政事务类的事由专门的人负责。另一方面的干扰来自自我,面对众多的干扰源,要求我们自律一些是重要的,这方面一方面需要团队的文化制度塑造个人,另一方面选择合适的人可能是更合适的。

尽量提供优质的资源,一台电脑在手,天下我有。很大程度上开发人员的主要资源需求就是设备,不要让开发人员抱怨电脑慢、内存不足…,给他们提供优质的资源。在这些资源上省钱是毫无意义的。这方面我们可以简单的算笔账,如果每天因为设备耗去每个开发人员半小时,算算一年损耗的时间和因损耗减少的产出。

尽量谨慎地增加开发人员,除非团队人员严重不足,而且有经验的丰富员工可随时拿来用,否则开发人员的增加并不会带来速度的提升,项目往往还会进一步延期。假如开发一个产品需要 10 人月,那么并不能增加到 20 个人就能半月完成,这应该是产品开发中的常识。

将这些方法应用于开发过程中,随着时间推进,开发速度应该会有显著提高,从而使团队具有「小步快跑,试错迭代」的能力。当然有一个清晰的要达成的目标是最根本的,这就好比打仗,当团队知道为什么战斗时,具备这种能力的团队,往往每次迭代都会交付一个好结果。

本文首发于我的微信公众账号「时间易逝」,欢迎订阅我的微信公众账号
在微信中搜索「doevents」或用微信扫描页面右上方二维码可订阅我的微信公众账号

为什么让新人写产品体验报告

在当前公司的控股公司中,每当一个新人入职后,会有一项工作,就是写写产品的体验报告。我认为非常好,所以在现在的公司就沿用了这种方式。在开始的时候执行的不太好,在设定这是转正必要的一项工作后,执行情况好了许多。

我们对显而易见的利益得失很容易看到并行动,但是对很多不那么显而易见的利益得失却总是缺乏思考而非逼不能行。在看我来写产品体验报告对每个人都是有益的,尽管它不会在提交的那一刻立即转化为 RMB,甚至我觉得更应该在寻找工作时就该带一份产品体验报告,江湖中也有用产品体验报告拿到 Offer 的事例。

对新人而言,一份用心思考的产品体验报告有助于我们尽快在企业落地,以便开展工作,为企业创造价值,获取回报。

首先,通过产品体验报告,在基本技能之上,能够进一步展现自己的能力,这东西是跟真金白银相关联的。比如文案能力如何,逻辑思维能力如何,系统性思考能力如何。更具体一些的比如是否具有发现问题的能力,是否能给出问题的路径与解决办法的能力,是否具有归纳总结的能力等等。要充分相信自己,在我看过的一些产品体验报告里,不管是经验丰富的还是刚刚步入职场的同学,均能提出一些对团队很有帮助的见解,这就体现了你的能力和企业对你未来成长的期许。

其次,除了产品之外,我们还需要从团队、企业工作的方式等方面评估一下这份工作是不是适合自己,是不是自己想从事的工作,借助体验产品的过程,自然而然的会跟不同团队的成员交流,而这些有助于给自己提供决策的依据。如果评估的结果是这份工作适合自己,那么能迅速融入团队是急需的。对工作方式的认可和执行,良好的交流与沟通是能够迅速融入团队的一种途径,而围绕产品展开无疑是比较自然的。

体验一圈之后,最终我们还需要回到跟自己从事的工作岗位相关之处,不管在什么部门,需要完成什么工作,都会跟公司经营的产品「服务」有所关联,公司不同组织结构内的团队也都是围绕着公司的产品,向用户输出价值,从而获得利润。从这个角度看,不管在什么岗位上,对产品了解的越多,越有利于开展自己的工作。

对于团队而言,很多时候我们都需要花费资源寻找用户,以获得产品的反馈,每一份新人的产品体验报告正是很好的一次用户反馈。这里面除了包括很多的问题和错误之外,还有一些不同视角的观点,这可以为产品的改进提供良好的探索路径,我们在局内很多时候看熟悉了就很容易固化思维,有时候换一种思维可能面临的难题就容易解决了,要勇于接纳新的看法和观点。另外,团队的每个成员也都有义务帮助新人尽快落地,融入团队以增强团队的战斗力,除了生活中的交流之外,以对产品的交流讨论作为切入点也是极其自然和有效的。

写产品体验报告更像是把产品作为一种连接器,通过这个连接器让大家共同获益。我想在生活中我们可能有意无意就进入到写产品体验报告的状态,只不过多数都在心里写,比如我们每买一样东西可能就写了一次产品体验报告。没有这么做的企业可以尝试一下,说不定会有特别的收获。

本文首发于我的微信公众账号「时间易逝」,欢迎订阅我的微信公众账号
在微信中搜索「doevents」或用微信扫描页面右上方二维码可订阅我的微信公众账号

我眼中的传统软件企业和互联网企业

在传统软件企业工作 15 年后,转换阵地进入一家互联网企业,转眼快 3 年了,说说在这两种类型企业工作的一些感触。

先说说这家互联网企业,是做数据中心的,主要为中小企业提供互联网的基础服务,属于B2B模式。我对数据中心的理解是它主要解决数据在两个方面的问题:

  1. 数据在空间维度的传递「通信」;
  2. 数据在时间维度的传递「存储」。

围绕这两个要解决的主要问题构建一系列基于软硬件的产品,在构建产品过程中和传统软件企业的工作方式还是有很大不同的,具体体现在组织结构和产品开发方式有不小的差异。

组织结构

组织结构的不同在我看来最终会反应到对资源使用的效率与整体的协作力。

传统的软件企业对于组织结构的设定就是一棵树,从上到下逐渐扩展层级,高度取决于团队的规模,宽度取决于职能部门的规模。

这种组织结构比较好的一方面是每个组织成员对于所处的位置比较清晰,从职能内部来讲分工也比较明晰,有利于工作任务的分工,其由于职能部门的分割自带分组特性,可以把每个职能部门看成一条流水生产线。

不好的一面是跨职能部门的协作型缺乏灵活,沟通成本随着层级递增成指数增长,在多职能部门间涉及到客户时多有扯皮,就职能部门内部来讲往往资源过剩,最大的直接体现是你工作几年后发现每天都很轻松。

我所经历的工作企业大多采用这种组织结构,从搜索引擎中搜一下「组织结构」,能够看到的搜索结果中的图片也大都是这样的组织结构。

我所在的互联网企业采用矩阵式组织结构,在传统的树形组织结构上,职能部门在垂直上是由很多小团队组成的,有直接隶属于职能部门的团队,主要负责完成公用性的任务,其他的小团队则为各个产品团队人员,这种产品小团队在横向和纵向受到双重管理,具体来说,涉及到产品相关的产品经理会从横向综合调配各个职能部门中隶属于产品团队的人员,完成目标。涉及到职能部门行政管理则由职能部门统一管理,大概如下图这个样子。

OrganizationalStructure

这种组织结构好的一面是能够最大化利用资源,打通了横向的隔离,协作效率极高,比较灵活,会大大降低沟通成本。如果要开设新的产品线,从横向纵向组建相互隔离的团队即可,而这种纵横隔离也最大程度上降低了互相扯皮的发生。

比较不好的一面是对每个团队的领头人要求极高,针对每一个点要确立明确的目标并能正确的理解目标,执行目标。

这种组织结构也跟互联网产品的开发有很大的关系,每个组织都是独一无二的,还应当以自身的特点出发,其他的仅能借鉴不能套用。

产品开发方式

传统软件企业在产品开发方式上,比较依附软件工程的理论,无论是瀑布式还是RUP(统一软件开发过程)迭代式,都讲求产品的大而全的规划和论证,重文档,重流程,重测试,所以动不动一个软件产品开发好几年,每更新一次再来个半年一年的,不能说这样的产品开发方式不好,针对特殊领域的产品开发,这种方式还是很有优势的,比如在航空航天、金融等领域这样的产品开发方式还是挺有优势的。

互联网企业在产品的开发方式上跟传统软件企业略有不同,当要开发一款产品时,首先要围绕总体的目标找到假设的最核心的,最小化的可执行「产品」,快速实现后上线验证是否为用户带来了价值,根据验证的结果再做接下来的动作。

比如验证失败了(这是常态,所以互联网企业大多允许一定程度的试错),再寻找另一个假设的最小化可执行「产品」,直至找到或者承认失败。假如幸运的验证成功了,也就是找到用户了,那接下来用户自然会倒逼驱动产品的迭代发展,在这个过程中用户甚至还会帮助企业建立服务流程,考核体系,这也就是平常讲的「以用户为导向」。

这两种产品开发方式跟面对的用户类型也有不小的关系,如果用户是企业,一般企业用户追求大而全,这几年传统企业都在积极+互联网,但思考的出发点还是从大而全,从局域网向广域网,或许在这方面可以针对互联网的产品开发方式进行借鉴,在+互联网的时候先确立一个最小化的目标进行验证,毕竟这种产品开发方式的思路很大一部分就来自传统生产企业「丰田的精益生产」。

这里说的是软件产品开发相关的企业,其实传统企业都是可以借鉴一下,如果把每项业务看做一个产品,业务负责人看做一个产品经理,不论从组织结构上,还是在业务开展上都可以结合自己的特点进行尝试。

本文首发于我的微信公众账号「时间易逝」,欢迎订阅我的微信公众账号
在微信中搜索「doevents」或用微信扫描页面右上方二维码可订阅我的微信公众账号