作者归档：月夜

初识 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」或用微信扫描页面右上方二维码可订阅我的微信公众账号

记 8 天没有网络的生活

发表评论

最近跟医院有些缘分，奔波游走在数家医院之间，从陪护到被感染「累？上火？」，以至于连续输了四天液，差不多过了 8 天没有网络的生活，这中间并没有错过什么很重要的信息，但无疑影响了计划。

如果没有这一遭，计划中先去武汉溜达溜达，然后现在应该在巴彦淖尔，这些计划都未成行，甚是郁闷。郁闷完后结合这次在几家医院的游走记一下感受。

刚刚启用的全国跨省医保结算系统确实方便了许多，在医保所在地登记参保信息后可方便进行结算，在办理的时候社保人员还挺认真，跨省打来电话以确认是否可用，这无疑方便了老百姓。

在本地医院间转诊却并不是随便能转的，具体规则没有时间来了解，于是通过办理出院后再入院的方式来解决，其中涵盖的检验信息依旧会重来一次，这多少跟医联体和分级诊疗有些关系，而这些同样都是设备检验出来的结果应该做到共享。在时效范围内，让患者抽一次血完成同样的检验应该是能够共享结果的而不是重复的抽血检验。从实际来看并没有感受到医联体和分级诊疗的落地。

在郑州看病就不得不说全亚洲第一大医院，最终还是来到这里，为什么？设备先进，医疗资源集中度高，有丰富的病源，以至于每每看起来它都不像个医院，更像是一个集贸市场，但来来往往闪烁着蓝灯的车提醒你，这是医院。好不容易经朋友帮忙，在这医院找了一个加床。

而我也是在这里陪护的过程中可能劳累，导致抵抗力下降以至于眼部受到感染，结膜炎，半边脸都肿了。不知是心理作用还是大医院复杂的环境导致感染的病毒也具有很强的耐药性，直到现在我的眼睛还没有好转，依旧满眼红色的血丝，为此耽误不少事，好在还有一只眼是好的。

一方面，依赖先进的医疗设备能最大程度上辅助医生获得诊断结果，以便给出救治方案；另一方面，好像干什么都需要医疗设备的辅助以便获得诊断结果，给人的感觉还真挺别扭。在别扭中我就在想，或许先来个全身核磁，再来个全身增强 CT ，然后再来个全项检验，这可能就是未来看病的标准流程吧。当然这更多的是一种善意，是一种求精准的态度。

医院是目前为数不多的能看到「传帮带」师徒体系的场景之一，在查房中师傅带着一帮徒弟们言传身教，伴随着每日对患者的望闻问切，徒弟们随着时间稳步成长，然后变成师傅，周而复始中形成医疗诊治资源的主体「医护人员」，这些人都是可爱的人，向他们致敬。

这中间有便捷的地方，比如自助查询打印、缴费、社保结算等就很便捷；亟待完善的地方也不少，比如预约检查总是不能如预约的那样、住院患者病房的居住条件、住院病区的污物管理、输液大厅的输液椅、救治之后的断线等，不管便捷也好，不便捷也好，医院这种地方还是尽量不去的好，而这些不便捷的地方可能就存在产品和服务的机会。

最后，这篇记录和上一篇「初识 Python（一）」都是用手机备忘录间断性的想起一点记录一点，在输入上虽然不如用电脑更加快捷方便，但写一点再写一点终归还是能有一些产出的，或许下次可以试试用语音转文字的方式是否会更便捷一些。

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

怎样提高开发速度

发表评论

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

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

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

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

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

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

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

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

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

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

记那些年在 IT 项目中踩过的坑

发表评论

最近进行了几次 IT／互联网项目的交流讨论，主要针对项目实施过程中碰到的问题展开，以求寻找问题的解决方案得以让项目继续向前推进。项目实施中碰到问题是很自然的事情，本以为是一些随机性的现场功能性问题，但其实并不是，在我看来这些碰到的问题是一个 IT／互联网项目比较基础的问题，结合过去项目的一些经历，说说我的看法。

在这里 IT／互联网项目包括软件开发项目、软件+硬件的系统集成项目以及现在的互联网+智慧型项目，这类项目一般面向一个行业，项目规模比较大，涉及的内容比较多，需要投入的资源比较大，这也催生了很多专门吃某一行业的项目型企业。这类项目的甲方「客户」通常会采用招标、邀标、单一来源采购、内部议标等诸多途径来选择乙方「实施方」。

对实施方来说，在做这类项目的时候，重要的是能不能围绕时间、质量、成本这三个要素完成一个可交付的产品，一个可交付的产品并不是指一个非常好的产品「据最近的朋友反馈说朝这个方向在转变」。可交付有两重含义，其一是客户能够按照约定期限给你钱，其二是内部团队有能力按照约定给用户提供产品及服务。这需要在这三个互为矛盾的要素间寻找平衡，这属于项目管理范畴，可以通过阅读相关书籍和实践获得提高。从经营的角度来讲，只要完成可交付那么这就是一个成功的项目，从这点来讲一个项目最大的坑就是怎么完成可交付，这应该是项目团队所有人时时应该考虑的事情，团队所有的协作就为获得这个结果，为此团队成员需要设定一系列的目标并完成它们。

在完成可交付的路上碰到孤立的项目是幸运的，但现在往往这样的项目很少，不孤立意味着会与其他项目发生关系，发生关系就会产生成本，很多时候这就是一个坑，常见于跟其他系统或设备的对接，我们可能会碰到其他供应商不提供接口、提供接口要收费、提供不符合我们使用的接口等诸如此类的情况。

无论什么情况，在实施过程中才发现这样问题往往会付出更大的成本，首先是时间成本，项目肯定延期；其次是费用成本，无论是那方解决问题都需要投入费用；最糟糕的是第三种情况，就是付费人家也不提供接口。

对于付费能够解决的通常会给这部分做个接口费用的报价「客户如不想支付这部分成本，必然会主动协调各方」，对于付费也不能解决的可能需要审视自己提供给客户的产品和服务，这有可能就是碰到的又一个坑，你无形中攫取了别人的利益。如果别家厂商的盈利方式是靠这个的，你的产品或服务在有意或无意的情况下分走了人家的利益，这肯定是很糟糕的。

如果提供的产品和服务的核心价值在此，客户又认可，那么可以采用不友好的方式替换掉对方，替换不是单一的设备或系统，而是要接管系统和设备后承载的所有业务。合作则是我认为比较好的选择，这就要求关注自己提供产品和服务的核心价值，尝试找出能够结盟的利益分成点，放弃涉及别人利益的地方，改造自己的产品以共同完成客户的不同方向的诉求，同时努力提高自己产品的壁垒。并行也是一种选择，并行的背后依然涉及到竞争，同时会对客户的使用多少造成不变，在自己很弱小而且提供的产品和服务的核心价值的壁垒并不那么厚的时候，很有可能只是帮助其他厂商验证了一下你的产品和服务给用户带来的价值。

在做项目的过程中，账期也是一个坑，账期是你的成本，账期也可能是你的收益，虽然做项目的过程中很少有把账期作为收益来运作的，但在不得已的时候也是可以给你的供应商一个账期以延缓资金的压力。针对成本好好的细细思量，要不看着赚钱，其实一屁股债。保持足够的现金流，尽量根据回款周期阶段性的支出成本。有不少企业项目做的不少，回款收不进来，最后企业给拖死这也是有的。

上面说到项目管理可以通过阅读相关书籍和实践已获得提高，这些获得的提高对内更有用一些，对客户来说实际更多的时候关注好人就行了，这类项目中的干系人不是单一的，很多时候往往由于忽视了不同角色的干系人就掉坑里了，比如搞定了埋单的人但是忽视了使用的人，因为这样项目失败还是蛮多的，就算项目没有失败，很多时候也是影响回款的。怎么维护好不同人的关系这其实挺复杂的，我做的并不好。在以往的项目中一般会用给他们干干活、买一些水果，小礼品什么的这样的方式接近他们，然后跟他们聊聊天。

除了上面说的之外还有很多很多的坑，比如需求的坑、选型的坑、运营的坑、部署的坑、售后的坑、安全的坑等等，要避免跨过这些坑在我看来主要取决于是否能够依据项目所在的行业，针对项目清晰的界定风险边界，而要想能够清晰的界定风险边界，就需要对这个行业组成的生态有足够的熟悉，在奔向熟悉的过程中，我们是需要支付成本的，企业为碰到的坑埋单是成本之一，成本之二是自己得花足够的时间成本来尝试理解这个行业。