初识 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 个人就能半月完成，这应该是产品开发中的常识。

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

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

发表评论

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

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

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

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

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

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

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

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

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

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

游戏、电视与孩子的教育

发表评论

看着自己的孩子一天天在长大，我开始时不时的考虑一些孩子成长的事情，自己的孩子属于信息时代孩子们中的一员，也不知道具体从那一天开始，就对手机、平板、电视突然兴趣很大，在这些东西上干什么呢？主要是玩游戏、看视频、看动漫。再然后家里的电视就被「坏」了，手机平板也被限制了。

在成年人的观点中这样会损害眼睛，会影响学习等等还有许多的理由，然后各种才艺班或学习班就上场了，但我不喜欢这样，也不认为应该这样。造成孩子喜欢玩这些很大程度上我们应该从我们自身找找原因，而且我也从来不觉得玩游戏是不好的。

如果能陪孩子尝试寻找更多好玩的事情，孩子们一定不会就仅拘泥于游戏和动漫，缺少陪伴和发现使得孩子没有更多的选择，孩子们当然会选择能接触到的而且他最喜欢的来获得乐趣，更何况很多时候孩子第一次接触这些就是家长给他们的。

单纯简单的进行限制，又没有引导让孩子发现有乐趣的事情时，孩子应该干些什么呢？按照家长既定的逻辑实现家长的期许？可家长既定的逻辑又凭什么是正确的？更何况从游戏和动漫本身来看，我从来都不觉得它们是坏的，每个时代的人有每个时代的游戏，同样每个时代也会有每个时代让人沉迷的东西，但这些对于大部分人来说仅仅是留在心里的一段美好回忆，丝毫不会影响你做多元化的选择和你的生活。

在对我自己孩子目前玩游戏、看视频的观察和交流中，我更觉得游戏、视频可能是孩子认识事物的一个窗口，具体表现在有时候甚至能给我讲一个故事和怎么做一个机关，当然这些仅仅局限于游戏世界中的元素，我偶尔会对照社会中能对应到的跟他说说，当然作为 IT 这个行业的从业人员，我还每每给他讲讲游戏是通过编程实现的；会记得视频中间出现的广告，在街上看见后会第一时间告诉我，碰到吃的有时会想让买来尝尝，碰到好玩的玩具有时也要求购买……甚至目前被广为抨击的「王者农药」这款游戏也知道。

游戏也并不是孩子唯一关注的，玩起来也相对自觉。孩子们也期望周末带他们去他们想去的地方，也会每天看看书，也愿意尝试学习并喜欢上某些事「目前阶段就喜欢学下围棋」，但如果缺少陪伴让孩子孤独前行，这些可能终究也就不了了之了。我想我们可能需要多给孩子一些陪伴，说说家长理解的社会基本规则限制，允许孩子表述自己的观点，给孩子更多的自由，让其快乐的成长，引导其自己建立自己的好习惯。

目前我在这方面做的是远远不够的，孩子其实是有极强的求知欲的，一定程度上这些限制会不断的抹杀孩子们的求知欲，同时过于单一的窗口缺乏引导更加容易让孩子沉迷进去，在这方面更多的原因在我这个做家长的而不是孩子，但往往我们指责的却不是我们自己。

我不反感孩子们玩游戏，不反感孩子们看电视，我知道的是好玩的游戏从来都是一个世界，如果把我们现在的这个世界看作是神「上帝」创造的一个游戏世界，在很多地方跟现在好玩的游戏世界并没有太大的区别，要想玩的出类拔萃同样是极不容易的，通往出类拔萃的路径很多地方是一致的，如果这么想，可能这也是一种教育引导的方式。

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

发表评论

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

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

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

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

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

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

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

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