《高效程序员的45个习惯》读书笔记.docxVIP

在公司实习3个月发现自己技术上的差距并不是差距最大的地方，软件流程和规范上的理解和实践的差距应该最大的，因此我最近去看《高效程序员的45个习惯》，希望能通过书上的讲述结合部门的规范使自己对软件开发流程和规范有更好的理解，将来能更好的在工作中实践。这里先分享前2章的内容，我只是记一些自己有感触的地方，可能是摘抄书中的话，也可能使自己总结的话，分享给大家，也方便自勉。 ? 敏捷绪论（敏捷－－高效软件开发之道） 1、对于软件生命周期，敏捷思想和活动贯彻始终，只要有人继续使用这个软件，开发就没有结束。敏捷活动切忌不可间断。2、持续开发：很多遗留的问题只有两种情形：要么侥幸没有任何事发生，要么情况变得更糟，恶化，不可控制，很难解决，无法扭转。解决的唯一方法就是持续地推进系统前进和完善，持续集成，发现点点滴滴的问题，而不是偶尔集成，发现一大堆问题，而且问题牵扯面很广，无法短期解决。3、敏捷工具箱?Wiki、版本控制、单元测试、自动构建（持续集成） 态度决定一切 做事1、出了问题，出了故障，寻找罪魁祸首永远不是优先级最高的工作，最高的是解决问题。（不逃避问题，直面问题，解决掉它）2、“这是谁负责的？”“这是谁写的代码？”这些不是敏捷团队中应该有的话，“好，我能帮你做什么？”这才是工作中最常见的话，我们把精力直接放在解决问题上。重点是做事，不是为了自己的面子，也不是为了指责，也不要进行个人智力斗争。3、有时你有问题请别人帮忙（尤其是新人），可能没有人积极响应你的问题，这时你要积极引导对话。解释清楚你想要什么，并清晰的表明你的目的是解决问题，而不是指责或争辩。指责不能修复bug。4、一次重大的错误应该被作为是一次学习而不是指责他人的机会。团队成员一起工作，互相帮助，一起成长。5、“这不是我的错”“这都是你的错”我们不想听到“是”和“错”，我们想听到“帮”“解决”。6、可能一些误解需求、误解API调用、误解决策是团队成员都有的情况，这时需要通知团队的所有人，确保整个团队尽快消除误解，步调一致。 ? 欲速则不达1、理解代码很关键，出现一个bug，优秀的程序员会深挖一层，尽力去理解为什么要这么做，更重要的是，我这么做会不会产生别的影响。2、没有一个开发者或者架构师知道他们的业务领域的底层数据模型，这就是只求理解表面的结果。核心问题必须了解，囫囵吞枣会埋下隐患，代码会很难维护。3、写好代码，谁都可以理解，谁都可以使用，易维护，保证我们的代码是可读的和可理解的，codeReview很关键，不要让开发者孤立的写代码。4、不要坠入快速的简单修复中，要投入时间和精力保持代码的整洁、敞亮。5、在项目中，你也许不知道每块代码的每个细节，或者每个算法的每个步骤，但是你对整体的相关知识有很好的了解。（作为新人，我首先要做到的就是对整体的了解和具体负责的模块的细致研究）。6、不要急于修复一段没能真正理解的代码，这样很容易弄糟的。要解决真正的问题，不要治标不治本。7、对于大型系统，除了深入了解你正在开发的那部分代码之外，你还需要从更高层次来了解大部分代码的功能，这样就可以理解系统各个功能块之间是如何交互的。 ? 对事不对人1、谁都认为自己的设计是最好的，设计上还是要遵循“循证”的开发观点，循证就是尊重经验者的想法，遵循真正的需求。2、如果你对团队成员提出的一个建议有异议，你不要“直接否定个人能力”“指出明显的缺点，并否定其观点”，最好是“询问你的好友，并提高你的顾虑”。记住，如果能稍加注意礼貌的对待他人，将会有益于整个团队关注真正有价值的问题。（新人要注意，礼貌问题要注意，有些老员工或是外包人员，适当的礼貌会让你们交流更顺畅，毕竟技术人员天生就有点傲慢的味道，礼貌会使你的地位放低，沟通就更便捷了）3、分享并融合各种不同的想法和观点，远远胜于单个想法为项目带来的价值。要打造好的团队，氛围很重要。4、负面的评论和态度扼杀了创新，我们要把重点放在解决问题上，而不是证明谁的主意更好。5、团队中的每个人都需要自由地表达自己的观点。即使你的建议不被全盘接受，也能对最终的解决问题有所帮助。不要害怕批评，批评有利于成长，不要把批评当作包袱，记住，任何一个master都是从被批评开始的，“你不需要很出色才能起步，但是你必须起步才能变得很出色”，放开包袱，表达自己的观点。6、如果你是一个有远见的人，就一定要特别尊重别人的意见。你是一个掌舵者，一定要把握方向，深思熟虑，吸取各方意见。能容纳自己并不接受的想法，表明你的头脑足够有学识。7、有一些特殊的技术：(1)设定最终期限：防止人们陷入无休止的理论争辩之中(2)逆向思维：先是积极地看到它的正面，然后再努力地从反面去认识它，找到优点最多缺点最少的方案。(3)设立仲裁人：仲裁人可以防止明星员工