试读《程序开发心理学（银年纪念版）》 有感

       写程序都快10年了，我怎么就没有看这本书呢？现在回想一下自己过去的10年真是快，自己也没有写出太NB的代码，就是完成功能就行了，别的真没有想过，平时也就看看技术相关的新闻、书籍，完全一个“码农”。

      虽然这本时隔25年才有机会读到，读时候有着共鸣的地方，比如项目延期、代码修改等，当然还有换工作时面试官的问题，其实本书中都已经提到。工作如果处理上下级关系如何沟通交流，书中也有提到，想想看也许我的上级已经读过此书，正用书中的方法+自己理解来管理团队。

     写了这么久的程序达到“优秀程序员”的标准了吗？

     1.技术规范

        04年毕业实习的时候作设计，后来写点asp，再后来空的时候接点私活，再后来.net，再后来，java，再后来......，最后自己在前端干了5年，说到规范，打心底说还没有一个完全的体系。也就最近两年慢慢规范js命名，css命名，并且文档化管理。之前完全是按个人爱好，想怎么写就怎么写，最多加行注释。也许是js的流行，前端的mvc框架出现，前端的工作量越来越大，如果没有规范大家就没有办法协作，代码不好维护。记得写了一个勤务打卡的功能，需要输入提示插件、自动生成时间线、时间线可控制等功能，当时赶进度，没有使用结构分层的方式写代码，后来追加功能时发现我的天，这是自己写的代码吗？完全看不懂了，二次开发这也太难了吧，为什么当时会这样写呢？瞬间明白文档的重要性，规范的重要性，后来公司要求我们整理自己的开发文档。

         2.日程计划

          计划不如变化快，这也许是开发的通病，特别是小项目，功能快要写完了，结果老板的想法又变了，又要重新来过，写完后交给老板看，老板说这不要他想要的，这种情况常常发生在不了解需要的情况下盲目动工，计划1个月完成，结果发现难度太大、老板需要不确定、客户需要不确定等，4个月过去了项目还没有完成，计划1个月的东西，4个月还没有完成，这肯定是有问题的。最终这由谁来负责呢？也许比较好的方式是先沟通，确定原型、再次和客户沟通确认功能、根据确认后的功能估计一个比较合理的开发周期这样比较妥当。

        3.适应性

         不只是客户的思维跳跃的，作为程序员思维肯定也是跳跃的，一般情况下，在不同的时间段里，解决同一个问题写出来的代码不可能完全一样。公司中也有对代码有所要求，但不会太过于限制，也只是对命名规范、代码书写规范作限制，不会说要求用什么样的算法去实现。算法的优化可能是在技术讨论会这样的场景中发生。当然对于一些新手会给于一些算法上的指导。

        4.效率

         效率这词有多方面的含义，代码执行效率、开发效率等，所以很多时候就单从项目角度看客户更看中效率，觉得快，好用这才是好软件，效率快也是需要代价的，从低层开始重构等。

        上面讨论的都是个相关的，程序开发一般情况不会是一个人全部搞定，工作中讲究的是团队合作。曾经我问一个朋友你们现在项目怎么样了？“组建一个团队从0开始相当不容易的......”。我能听出这团队从0到有这过程的艰辛。

      如何带领团队，管理本来就是一门艺术，不同的人结果是不一样的，但不能违背做人，做事的原则这是关键。本来项目开发中与团队成员之间就有可能发生争执，如果在处理其它细节上出现高高在上等这样的情况，团队成员肯定有意见的。

     本书的内容有太多东西需要我去学习，去领会。

     学无止境！加油