程序员的自我修炼之道

程序员的自我修炼之道（一）

      去年刚工作那会，项目组同事给了我这本书，当时看起来挺费劲的，毕竟没有太多的实战经验，看了一会儿便束之高阁。如今闲暇之余，翻阅起来，感觉蛮有意思的。长话短说，这是一本对程序员自我修身提炼的一本秘籍。相信很多朋友都阅读过。这里主要讲述自己看后的感悟，不对之处还请前辈们多多指点一二。

书中介绍注重实效的程序员具有以下几种特质：1.早期的采纳者/快速的改编者。2.好奇。3.批判的思考者。4.有现实感。5.多才多艺。

对照了下自己，默默的合上了书。

图片发自App

书中介绍了两种开发方式，一种是曳光弹，一种是原型开发。曳光弹类似于我们现在讲到的敏捷开发，在项目初期，先简单的抛售几个点，让用户帮助我们去选择。拥抱变化，迭代周期短，人力成本与项目成本都会缩短，至少不会把太多的effort浪费掉，当然短时并不意味着高效，有些时候为了赶进度，欠了好多。但是这边会在系统中日积月累，一旦到了无法容忍的时候，也就是重构的时候了。因此，如何有效的短时高效的开发依旧是一个值得思考和探索的问题。像以前做portal的项目，由于开始没考虑清楚人员岗位权限的准确定位，没有深度挖掘业务上的增量变化。每次patch，都是伤筋动骨。开始设计开发的时候大家都很愉悦，有新的变动，也是怎样简单怎样来，渐渐的我们发现，我们选择的道路越来越窄，可供解决的方案越来越少，最终只剩下重构。因此我们开发的同时，要多花点时间好好设计，好好规划每一步，欲速则不达。个人还是比较喜欢敏捷方法论，通过看板，不仅能知道自己的目标正一步一步实现，每一个任务的完成都是一种激励，同时也有助于发散思维和挖掘深层次的东西。当遇到技术难点时，当用户的需求模凌两可时，我们可以组织workshop，构建T型表，对每个人提出的task进行批判性讨论，从而形成最终方案。原型开发就是瀑布模型，拥抱变化的能力弱，反馈周期长。好像目前用的多也就在游戏领域吧。

书中提到两种依靠巧合编程的典型：实现的偶然与隐含的假定。

实现的偶然就是在使用新技术、三方库或者其它人写的模块时，拼凑的代码碰巧工作了，那么我们就宣告胜利结束编码。曾经看过一个搞笑的代码注释：

//warning:Do not make any changes here.

//I got confused why it can run successfully. PLEASE Do not make any changes before you figure it out.

也许是上天的眷顾，功能莫名其妙就好了。当这些代码出问题时，通常会一头雾水，因为当初根本不明白它为什么会工作。隐含的假定通常就是开发者的YY，也就是神乎其神的直觉，而实际上没有任何文档或者现实数据可以依靠。我相信很多猿类们都遇到过这样的case:系统里藏了个雷，有天被你发现了，然后你三下五除二的排了它。正暗暗窃喜，控制不住的想在修复的旁边标注下你的大名......然后，就再也没有然后了，系统服务起不来了！我们常说“入坑”，这些坑可能是前人用巧合留下的，也可能是因为我们一时的小机智引起的。

因此要谨慎对待不熟悉的依赖，特别是对待第三方库的时候，仔细阅读文档，代码虽然可以工作，但并不一定正确。还有就是我们只依靠可靠的事物，对于那些未知的，要以最坏的假定来对待，不能随意的给自己磕药。

刚刚解决了一个关于重复的问题。jpa层想搜下数据，套用上面现成的代码，很快写完了。但是发现编译不通过。提示我的入参类型不对。what？idea没红色啊。猜想是不是依赖了其他包。果然有依赖，而且发现jar包是昨天的。那么jar出问题了，那么它为啥出问题不知道。只好备份它，编译又报错了，提示有重复代码？！指向了那段sql，让我深呼一口气。这机制连这都检查得出？！再也不用担心我忍不住去copy了。哎，效率有点低了。

修炼是一段旅程，时刻关注自己的技艺，保持热情。保持足够的好奇心，保持对自己输出的产品有足够的爱心。未完待续