最近比较懒，加上新接手的项目压力比较大，所以没有进行总结，这里自我批评一下。
前段时间在公司内网看公司同事转载的一篇博客，里面有句话很有深意，由于过去有段时间了，原文记得不太清楚，大意是说对于每个程序员在看到六个月前写的代码时，都会觉得像一坨屎，大牛例外。初看起来这句话很是无厘头，不知所云，细想起来还蛮有意思的。首先程序员的经验是随时间而逐渐积累的，现在的自己和六个月之前的自己相比，肯定是现在的自己在各方面要更进一步，所以看到六个月之前写的代码，肯定会有别样的感觉，否则这六个月就是没有进步或者说原地踏步，这对程序员来说可不是好的兆头。做程序员的都知道，代码可读性有时要让步于项目的进度，代码写的再好，如果没有按时交付，出现项目延期，不管是何种原因，黑锅是肯定跑不了的，所以按时交付项目是第一要素。按照这个思路开发出来的代码，可读性、维护性方面可想而知。所以六个月之后，换个心境再去走读之前写好的代码，可能会是另外是种想法。另外，把自己六个月前开发的代码称为一坨屎，其实是需要不少的勇气的，说明进取的心态很好。
最近在项目里评审代码的会议参加的比较多，一方面评审新进员工开发的代码，另一方面拿自己之前开发的代码给别人评审。 根据我的观察，一般程序员，包括我自己在内，在评审代码时都倾向于挑别人的代码，而在被他人提评审意见时，自觉不自觉的会给自己一层装甲，随时应对他人的意见，力争说服他人。平心而论，这个习惯是不好的。有则改之，无则加勉，他人提出的评审意见都是有道理的，只是评审意见的理由可能很难让自己认同。如果抱着应对挑刺的心态来看待评审意见，无疑是有害的。
评审新进员工代码时，我要求很严格，细微的问题都要求修改，没有耐心聆听代码开发者的解释，反而觉得相关的新进员工没有认真学习和领会，自己的态度则愈加恶劣。而在参加自己代码的评审会时，遇到暂时不能理解的评审意见时，当众质问评审人，评审人反复耐心解释之后仍然不接受意见。事后想想，真是失态，在评审会上没有表现出应有的修养和职业素质。当众 被提出尖锐的评审意见无疑是很难堪的，但是从另外一个角度考虑，为什么其他同事拿出来的代码被评审时就没有收到尖锐的评审意见，为什么其他同事在收到比较尖锐的评审意见时仍然可以保持冷静。。。
多问几个为什么对于缓解情绪是有帮助的，从小事情上就可以发现大问题。其他同事提交的代码为什么没有收到尖锐的评审意见，拿自己的代码进行对比，原因可能有如下几种：
1）代码逻辑简单，注释比较全面或者自注释；
2）针对业务问题，恰当的应用了某种设计模式；
3）代码量刚刚好，不多不少，和业务关联性不强，不需要有专门的业务知识；
4）代码符合评审标准；
而对比自己提交的代码，则存在如下几类问题：
1）代码逻辑复杂，关键路径缺少注释；
2）与业务相关，需要对业务有一定的了解，评审人走读时理解困难；
3）代码量偏多；
4）虽然应用了设计模式，但是使用方式有点偏，以至于评审人不理解，或者不赞同；
5）代码在某种程度上不符合标准。
所以自己的代码不被评审人认可也是有道理的。码农嘛，代码写不好，可是关系到吃饭的家伙。
代码评审会上失态，其实和最近一年的境遇有关。最近一年里，项目的需求偏碎片化，工作内容非常琐碎，很少有机会完整开发一个特性，基本上都是在修修补补。今年以来这个问题更加突出，项目经理给的建议是认领工作时尽量优先选大块的工作，而不要选碎片的工作。我个人觉得建议很好，但实践起来很难。原因是项目组当前人力状态不允许，很多工作内容只能我和另外一位同事承担，其他同事则在能力或者动力上不足，这导致工作认领在某种意义上成了分片包干。不知道项目经理对于这个问题如何理解，不过个人的事情只能自己操心，项目经理其实关注不了太多。所谓不在其位，不谋其政，项目和团队上的事情想多了有时间感觉自己是在瞎操心，项目经理都不着急，我是何苦呢，安心做自己的事情，拿自己那份钱就是了。但项目今年的进展不太好，我比较担心会不会影响到钱包，这可是和钱袋子有关系的事情。我现在是上有老、下有小，还有一屁股欠债，进步慢了总觉得压力大。不过写出来了，心情就好一些，压力可以释放一些。
观察项目组同事的行为其实是一件有意思的事情，很多小事情都是有关联的，从中都可以发现大道理。对于一项工作任务，如果站在项目经理的角度看，首先要有计划，其次要跟踪计划，如果某位同事认领了工作但是没有给出计划，或者计划的时间点总是把握不好，那么就会影响对这位同事的判断。对于计划估计不准，我想这可能不是大问题，计划制订的再漂亮，总是会有特别的事情跳出来打扰，影响计划的完美达成。对于搞计算机的程序员来说，处理一项工作任务时，基于职业习惯，一般都会采用分治的策略，大事化小，小事化细，总之一句话，降低风险，同时便于制订计划。如果某位同事在认领任务之后总是不能制订出计划，那么很有可能会被认为是思路不清晰，或者能力不足。这从我最近几个月辅导项目组新进员时总结得出的结论。最近几个月项目组来了几位新进员工，其中的一位毕业生在认领工作之后总是无法反馈任务计划，或者计划的时间点总是一拖再拖，这无疑影响了全组人对他的印象；另外的几个新进员工由于有一定的工作经验，明显要比毕业生上手快，但是工作习惯上存在问题，但一经指出就能马上改进，不需要特别的担心，这样的员工无疑是令人放心的。
我自己最近接手做的项目压力比较大，技术上、进度上都有较大的风险，手头上的资料很少，只能通过走读有限的材料来了解竞争对手的设计思路和方案。这时我犯了个错误，做事前没有按照惯例制订计划，输出设计分析，直接一头扑到代码里开搞。从目前来看，虽然基础代码写了不少，但由于没有划分任务小项，给出工作计划，以至于项目经理认为风险较高，需要每天例行汇报工作进展。我比较反感开会，在压力巨大的时候无疑是要命的。但项目经理是好意，任务压力再大，也要临时停下思考一下方向，保证方向正确，做正确的事情，同时明确可行的任务目标，合理降低团队内部、外部的预期。可以说，遇到问题不订计划直接扑上去开搞，也给项目经理留下了“技术情结过重，小处着眼过多，不重视整体”的坏印象。之前我还觉得自己改的蛮好的，现在看来，想要完全消除，还是需要时间来磨练自己。
今天晚上我犯的一个错误。 程序员是世界上的聪明人，心高气傲，恃才傲物。相比之下我并不聪明，但可惜的是却有聪明人的习惯，固执已见，有时得罪人也不自知，而事后总是自责。比如今天晚上在公司就因为一个技术问题而与同事直面发生了小冲突，事后细想发现其实是我自己理解出了问题，人家的方案是有可行性的，但被我生硬的拒绝了。但事情已经发生，只能明天找个机会承认错误了，希望不要影响那位同事的情绪。