创新式开发探索（三） —— 反思自己的开发活动

     提纲：

     1.   没有遵从自己的生物本性来进行工作和作息， 是第一个需要反思的事情；

     2.   不重视方法， 只顾蛮干，  是第二个需要反思的事情；

     3.   没有做好有效的记录、备份工作， 是第三个需要反思的事情；

     4.   开发程序时不能知其所以然， 满足于 “It works”，  是第四个需要反思的事情；

     5.   没有建立一套行之有效的机制，来应对工作中的各种中断和异常， 是第五个需要反思的事情；

     6.   没有明确的职业/技术方向， 精力分散容易导致样样会一点却无所精通， 是第六个需要反思的事情； 

     7.   因为过去的疏忽、偷懒、 折中及各种原因而作出不明智决定，  导致现在付出更大的代价， 是第七个需要反思的事情； 

     8.   因为纵容小问题，导致未来付出更惨重的代价， 是第八个需要反思的事情；

     9.   开发程序未能充分考虑线上复杂的环境， 是第九个需要反思的事情；

     0.   不作充分规划，过早着手， 导致返工， 是第十个需要反思的事情。

      一个程序员的产能曲线应该类似正态曲线， 先逐渐上升到某个巅峰， 持续一段时间，  然后下滑。 中间可能有一两个小高峰。 因此， 正确的作法不是持续长时间作战， 而是充分利用自己最巅峰的产能时段， 完成一天的工作， 其它的时间留给休息；

      另一种说法是， 人的注意力持续时间最长为2小时， 因此， 可以2.5 小时作为单元； 工作2小时， 停顿一下， 恢复精力， 然后再继续。 反复如此。 

      牢记： 你是靠智力来获得报酬的生物， 干嘛要把自己当成机器那样使？  

          警示录： 没有遵从自己的生物本性来进行工作和作息， 是第一个需要反思的事情。

       解决方案： 充分发挥智力的力量， 调节好工作与休息， 善待身体， 身体也会给予最好的回报。

       别人走在你前面， 不是因为你不够聪明，不够勤奋， 而是因为别人掌握了一种方法。 这种方法将滚雪球似的拉开彼此的距离。 必要的勤奋是不可或缺的， 在勤奋之外， 强有力的方法成为致胜的关键。

       如果花费了比别人多得多的时间， 却依然感到捉襟见肘， 就很有必要质疑自己所采用的方法了。 为什么花费了大量时间，收效微小？ 我是否适合做这个事情？ 为什么学习新技术的进度很慢， 是因为基础薄弱， 记忆能力平凡，还是方法有问题？ 过于贪急求快？  时间安排有问题？ 规划定位不明确？  不善于利用现有环境和周边资源？ 

          警示录：   不重视方法， 只顾蛮干，  是第二个需要反思的事情。

       解决方案：  定期地停下来， 反思现状， 质疑现有方式， 思考更好的方法。 

      创新式开发探索第三篇 ——  反思自己的开发活动。

      为什么开发效率这么低？ 为什么要加班熬夜？  为什么在上班的时间无法完成该完成的任务， 学到该学到的东西？  是什么， 隐隐地谋杀着程序员原本短暂的生命？

        1.    没有有效地备份， 低水平重复做过的事情。

       最近， 接连重装了几次系统， 每次重装系统后， 都要重新搭建开发环境。 比如配置Flex开发调试环境以及各种开发工具、包、Web容器； 还有各种常用软件安装有木有？ 虽然不是什么难事， 却也无情地消耗人的时间和生命， 一次次重做也令人厌烦。

       此外， 由于没有有效地备份， 以前做的项目、数据、资源、记录等丢失， 难以找回； 尤其是一些重要的工作记录， 问过了同事却没有备份， 是不是要再问一次？ 

       2.  重复的问题重复求解

       做开发免不了要上谷歌百度搜索解答。 有时候，一些临时性问题解决了没有做有效记录， 结果下一次遇到了， 记不清楚了， 又要重新上网搜有木有？  有木有？  一定确定以及肯定是有的。

       

        警示录：

        重复， 消耗了不知多少人的青春， 人类 60% 的时间恐怕都耗费在重复的事情上了； 

        没有做好有效的记录、备份工作， 是第三个需要反思的事情。

        解决方案： 

        使用知识管理软件， 事毕记录， 事必记录， 简要记录。 在遇到同样问题时， 不必重新在网络上痛苦地搜索。

       充分重视备份工作， 理清楚有哪些必要的软件、工具和重要文件数据（专门放置在一个命名为 BackupImportant 的文件夹或目录），  定时备份。 网络， 移动硬盘。 至于软件安装， 尽量写个执行脚本， 一次性自动化搞定。 第一次花费 100% 的精力， 第二次及以后只花费5%不到的精力。

        3.  贪急求快， 不求甚解  

       人都有贪急求快的本性，  在遇到问题并且有项目进度在头上敲钟的时候， 这时候， 你很可能会直接将网上的答案Ctrl+C/V， 修改， 直至“看上去能够正常工作”（这是很大的诱惑）， 而不知其所以然。 当然， 你如果还有心情去探索其所以然， 说明你定力真的相当强。  不求甚解导致的问题就是， 什么也没有收获， 除了“解决了眼前的问题”。

       此外， 当你一次次使用 Ajax 技术开发前端应用时，是否了解过 Ajax 的内部实现原理？当你把应用部署到 tomcat 或 jetty 中时， 你是不是期望一切正常？ 如果出了异常， 一定会很郁闷， 因为通常出的错都会很莫名其妙； 当你使用框架组件的时候， 是不是期望一切OK？ 这一切看上去很神奇， 你对框架、组件内部了解甚少， 却还能正常出结果， 实在令人惊奇； 不过， 当出问题时， 一切就不那么神奇了。

         警示录：  开发程序时不能知其所以然， 满足于 “It works”，  是第四个需要反思的事情。

       解决方案：  对基本的重要的问题一定要知其所以然， 即使当时没有时间， 也要记录下来， 有时间的时候好好钻研下其内部实现。 知其所以然， 这是程序员之为程序员的根本之所在。

       4.  工作被打断， 干扰管理

       同事喊有事要探讨一下， 正巧有个临时会要开， 肚子开始抗议了， 而自己正沉浸在程序的构思实现中； 同事打电话过来， 交代事情需要去处理。 这都是避免不了的工作场景。 大多数时候， 我们可能是基于本能反应去应对各种的被打断， 或者不情愿被打断。 如果打断次数有点多得话， 就会造成较大的干扰和影响， 需要仔细管理了。 

           警示录：  没有建立一套行之有效的机制，来应对工作中的各种中断和异常， 是第五个需要反思的事情。

       解决方案：  有时间的话， 可以 “保存下现场”；  尽量做到快速切换，  放下自己的事情， 专注与别人的沟通， 这未尝不是一种磨炼。 任何时刻， 任何事情， 都可能隐藏着机遇。 少了几分钟敲代码而已， 但多出了时间去自由思考和交流。 一切都在控制之中。 Everything is in control。同事交代事情， 做一个列表， 尽量给予准确的答复， 并安排时间去完成， 培养自己的职业化素养和良好信誉。

       5.   斗志低落，无所适从

       人总是有斗志低落的时候。 一种可能是， 不知道干什么， 这是目标不明确所导致； 一种可能是， 遇到问题不知道如何求解， 这说明该向有关人士请教了； 还有一种可能是， 持续工作一段时间， 精力不足了， 这时候， 需要休息停顿一下， 恢复精力。

       解决方案： TODO List， 保证总有事情可做； 善于求教，而不是埋头苦干； 适当停顿， 停下来才能更好地前进。

        6.   对自己做的事情失去兴趣

        有木有这样的感觉：  做了两三年开发的你， 觉得有些事情， 交给一个花 3-4K 的本科生来做比自己来做更有价值， 甚至做得更好？ 做重复的功能？  花费自己最宝贵的生命力量去做那些没有太大影响力的事情和系统， 你真的想这么得过且过么？  

          警示录：  没有明确的职业/技术方向， 精力分散容易导致样样会一点却无所精通， 是第六个需要反思的事情。 

       解决方案：  不要沉迷于纯功能性的开发； 转向“解决方案” 开发；  尽早确立一个值得探索和探究的领域， 在其中深耕细作， 做出前人没有做出的东西来， 哪怕再小； 或者投入到一款新产品开发中， 这种产品能够在很大程度上影响人们的生活方式。

        7.  现在的80%是在为过去买单

        历史遗留问题总是令人头疼。 因为疏忽导致的程序错误， 需要重新修正， 重新部署（在当时多花一点点精力就能做好， 放过之后， 在一个你很忙的时候突然插上一脚， 那种滋味是很不好受的）；  由于考虑不周到， 导致一方面要改很多地方， 另一方面， 又不能尽情地改； 大学时不好好努力， 总想早点飞出去， 结果出来后四处碰壁。

 

            警示录： 因为过去的疏忽、偷懒、 折中及各种原因而作出不明智决定，  导致现在付出更大的代价， 是第七个需要反思的事情。  

        解决方案： 为了不让未来为现在买单， 请慎重仔细做出现在的决定， 不要因为偷懒而做出折中妥协的方案。现实就是这样， 你必须敢于承担一些风险， 甚至力排众议， 坚持不懈地推动事情发展和完成， 才能获得生活的馈赠。

        8.   过去的小问题会在未来放大成大故障

       有些问题， 在过去修复代价非常小， 但时隔多时， 在未来的某个时刻修复可能会付出很大的代价。 故事就发生在昨天。 有一个API调用少传了一个参数（在大多数API调用中该参数是可选的，但在少数情况下是必选的）。 如果在很久很久以前修复，几乎不是什么事； 然而， 修复发生在系统重构期间对原系统的维护，线上发布的权限控制发生了变化， 昨天发布演变成了一场故障， 导致线上服务中断了30分钟。

          警示录：  因为纵容小问题，导致未来付出更惨重的代价， 是第八个需要反思的事情。

       解决方案：  不要放过小问题， 尽早修复。 

     9.   未能充分考虑线上复杂的环境

      一条普通的子查询语句， 在 1000 条记录的表中几乎不是问题； 但在百万级以上的表中， 性能问题就很突出了。 详见《第一次项目发布的教训》。同样的程序， 在 2G 内存的机器中运行没有问题， 在 512M 内存的机器中运行就可能出问题。 开发程序不充分考虑线上复杂的环境， 就会出现各种不曾预料的问题。

           警示录： 开发程序未能充分考虑线上复杂的环境， 是第九个需要反思的事情。

        解决方案： 抽时间专门对线上环境做个调查， 弄清楚哪些因素可能对你的程序造成影响，并做些预防措施。 

       0.   未作充分规划， 过早着手，导致返工

        程序员总有点急性子， 希望尽早做出效果。 于是， 容易不作充分规划和设计就匆忙下手。 一个功能实现， 想出一个方案分三个步骤。 急急忙忙做出了第一个步骤，发现这个方案在第二个步骤有瓶颈， 或许需要付出很大代价， 或者有缺陷， 结果不得不放弃， 于是， 在第一个步骤所花费的精力和时间就这样浪费了。 

             警示录：  不作充分规划，过早着手， 导致返工， 是第十个需要反思的事情。

         解决方案：  凡事先做规划设计， 攻克可能存在的问题、困难后再动手。 不作过度设计， 但也不能不作充分的预先设计。

 

      10.  项目人少， 加班必不可免

       有时， 项目人少， 那么， 现有的人员就不得不在进度下像螺旋一样了。 但是， 也不应超出限度。 较好的一种方案是，  规划并记录每天所做的事情， 保证这些事情确实在有力地推动项目进展， 并且是一个人应该承担的正常工作量（或者超出一点）。 有凭有据， 就不必莫名其妙地被加班了。 从另一个角度来说，程序员要学会规划自己的工作， 而不仅仅是执行上级派发的指令。

      11.   不相信自己写出的代码

       软件越复杂， 越不相信自己写出的代码。 只是看上去能正常工作， 不知道隐藏了多少BUG。 学点测试的技能吧，同时， 尽量建立一套比较规范的开发方法和流程，  一次投资， 多次使用， 终生受益。

      12.  还有什么？

       继续思考 ing ...... 

        PS：

        从反思可知， 一定需要一些管理性的工具或软件， 来实行自己的知识管理和开发活动管理， 使之处于可控有序的状态， 避免那些初级问题的纠缠的。 尽早越好， 这是对编程新手的忠告， 别忙着编写程序。