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

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

《《高效程序员的45个习惯》读书笔记.docx》由会员分享，可在线阅读，更多相关《《高效程序员的45个习惯》读书笔记.docx（8页珍藏版）》请在冰豆网上搜索。

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

在公司实习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）设立仲裁人：

仲裁人可以防止明星员工操纵会议，并及时打断假大空式发言。

仲裁人专注于调停。

（4）支持已经做出的决定。

设计充满了妥协（生活本身也是如此），成功属于意识到这一点的团队。

工作中不感情用事是需要克制力的，而你若能展现出成熟大度来，大家一定不会视而不见。

这需要有人带头，身体力行，去感染另一部分人。

8、一个团队能够很公正地讨论一些方案的优点和缺点，你不会因为拒绝了有太多缺陷的方案而伤害别人，也不会因为采纳某个不甚完美（但是更好的）解决方案而被人忌恨。

9、尽力贡献自己的好想法，没有被接纳也无需生气。

不要因为只是想体现自己的想法而对拟定的好思路画蛇添足。

10、不要轻易批评别人观点，要有充足的论据和调查，要评判出现错误的场景发生的可能性有多大。

11、在开发者眼中最好，不一定就是用户认为最好的，反之亦然，因此我们要足够尊重用户真正的需求和想法。

12、用合适的词和理由去解释为什么你不赞同这个观点或方案，并提出明确方案。

排除万难，奋勇前进

1、有问题一定要指出来，open，开放，不管谁的问题，隐藏问题都是罪过。

2、绝妙的计划会因为勇气不足而最终失败。

尽管前方很危险－－不管是真的鱼雷或是只是一个比喻－－你必须有勇气向前冲锋，做你认为对的事情。

3、当一个任务存在很大困难和风险时，尽快联系你的主管和有经验的同学，评估一下这个任务，不要凭着勇气一股脑做事。

沟通，让你的主管知道你在做什么。

4、不要试图掩盖问题，要有勇气站出来，“我现在知道了，我过去使用方法不对。

我想到了一些办法，可以解决这个问题－－如果你有更好的想法，我也很乐意听听－－但可能会花一些时间。

”这种话语让人感觉很舒服，促进大家解决问题，主动走近，提供帮助。

体现了你的真诚和勇气，赢得了他们的信任。

5、你深知怎样做才是正确的，或者至少知道目前的做法是错误的，要有勇气向其他的项目组成员，老板或者客户解释你的不同的观点。

6、遇到大规模反对意见，要反思一下，也许你是正确的，但是你没有解释清楚自己的理由。

还由种可能就是你的想法不是很正确。

7、没有马上理解那段代码，不要轻易地否定和重写他们，那不是勇气，是鲁莽。

改动别人的代码要充分理解逻辑和业务，有必要让曾经开发过这块业务的同学review改动后的代码，多部门合作时鲁莽的改动别的部门的代码可能会带来巨大的问题甚至是故障。

学无止境

1、软件开发行业是一个不停发展和永远变化的领域。

在一个企业化的社会中，只有一个人会为你负责－－你自己。

是否能跟上变化，完全取决于你自己。

公司提供足够大的平台给我，可是成长是你自己的事，自己的意愿，依靠自己的努力。

2、如果你跟踪技术变化，那么学习这些新东西对你来说就是了解这些增量变化，如果你不跟踪变化，技术变化就会显得突然并且难以应付。

3、有时也要懂得摒弃陈旧和过时的开发方法。

4、你曾经认为自己已经很明白的事情，现在也许并不是你想象中的那样，你要对没有完全理解的某些疑问不懈地深入追踪下去。

打破砂锅问到底。

跟踪变化

1、唯有变化是永恒的，你从事的是一项充满激情且不停变化的工作。

如果只是掌握了工作中需要的技术并不够，那样的工作也许几年之后就不再有了－－你会被外包或者会过时，那么你也将会出局。

通过自己学习提高自己的价值。

2、对于很多先进的技术但工作中并未使用，你也要尝试接触它们，至少做到虽然不是这方面的专家，但也不是对它们一无所知。

还可以选择若干个技术仔细研究或应用于工作中。

3、点点滴滴的跟踪技术，会使你在大的技术更新面前应对自如，此前的积累为你打下基础。

4、每天计划用一段时间来学习新技术，它不需要很长时间，但需要经常进行。

记下那些你想学习的东西－－当你听到一些不熟悉的术语或者短语时，简要地把它记录下来。

然后在计划的时间中深入研究它。

多看看，多记记，慢慢能发现最有价值的技术深入研究。

（也可以看看顶尖博客作者正在关注什么，听分享，积极加入到问答环节中，找一些关于软件开发和非技术主题的好书）

5、你不需要精通所有技术，但要清楚知道行业的动向，从而规划你的项目和职业生涯。

6、学习新技术时，你要正确地把握自己投入的精力，因此技术选型很重要。

7、只要你在某些方面成为专家，就能使用同样的方法，很容易地成为新领域的专家。

专家的道路都是大致相同的。

8、面对每个新技术，你都要弄清这个技术能解决什么问题？

被使用在什么地方？

9、使用新技术，做决策之前，你必须评估新技术的优势，开发一个小小的原型系统，是对付技术狂热者的一剂良药。

切换技术需要决策和考量，不要狂热的追逐技术，要冷静思考。

对团队投资

1、一个学习型的团队才是较好的团队。

2、新技术要想得到使用，先要在团队内分享，让大家了解才能推广才能应用。

3、如果周围的人都比你厉害，你就会有很强的动力区追赶他们，你将会在这样的游戏中走向自己的顶峰。

和高手工作，你的资源会更多，成长的余地也更大。

4、优秀的管理者会重用那些能提高其他团队成员价值的人。

唤起每个人对技术和技巧的激情，将会对项目大有裨益。

5、不是所有的讲座都能引人入胜，有些甚至显得不合适宜。

不管怎样，都有未雨绸缪。

积累不一定有目的，点点滴滴的积累会有无法估量的成就，不要放弃一点一滴的积累。

6、学习也要持续，小步前进才是敏捷。

7、平时的工作最好要和学习分开。

懂得丢弃

1、敏捷的根本之一就是拥抱变化。

2、随着技术的发展，编写代码的开销大小远远没有维护代码的开销要大。

所以开发者的时间才是紧缺和昂贵的资源。

3、不要把太旧的态度和方法用在学习新技术上，而意识到这个问题更加困难。

要适当丢弃旧习惯和思维定势。

但是并不是完全抛弃。

在合适的环境，可以举一反三地灵活应用，但一定要保证不是习惯性地落入旧习惯。

要尽快转入新的开发环境，只有更少被旧习惯牵绊，才更容易养成新习惯。

4、已有的技能和习惯为你打下很好的基础，但不能依赖它们。

一味遵循过时的旧习惯会危害你的职业生涯。

5、没有最好的技术，只有最适合的技术。

6、对于语言的学习，要注意新版本特性上的变化。

打破砂锅问到底

1、为了解决问题，你需要很好的了解系统的全局，你需要查看所有你认为和问题相关的部分－－即便其他人觉得这并不相干。

2、为了解决需要知道许多可能的影响因素，当找人询问任何相关问题时，让他们耐心地回答你的问题，这是你的职责。

请我来解决问题，此时此刻我就是系统的Owner，我有责任了解它，了解它可能存在问题的地方。

3、你的问题甚至会帮助他们理清思路，你从一个新人角度提出的问题，给他们提供了一个新的视角，也许就帮助他们解决了一直令人困扰的问题。

你是新人或对这个系统一无所知，但你提出的问题不一定都是无知的问题，旁观者清，你也许就一个问题有用，其它都是白痴问题，那也要勇敢提出来。

但是要注意多问多看多学。

4、不停的问为什么。

不能只满足于别人告诉你的表面现象，要不停的提问直到你明白问题的根源。

5、问“为什么”，但要问到点子上，仔细思考，准确发问。

6、被提问者也许会问“为什么你问这个问题？

”想好你提问的理由，这会有助于你问出恰当的问题。

把握开发节奏

1、敏捷项目会有一个节奏和循环，让开发更加轻松。

而且很多敏捷实践必须一直进行。

我们需要更具远见，保持不同的开发节奏，这样敏捷项目的所有事情就不会突然同时发生，也不会随机发生，时间也不会不可预知。

2、如果在你工作的时候没有一个固定的最终期限（例如一天的结束），就应该好好想想了。

3、每个时间盒必须是短期的、有限的、并且要完成具体的目标。

不要改变时间，可以改变功能。

你会为设计讨论会设定一个时间盒，即到了指定的时间点，会议就结束，同时必须要做出最终的设计决策。

固定时间期限会促使你做决定。

遥遥无期的会议和讨论是没有意义的，往往先去具体的工作一个周期后，我们也许更有把握判断是否正确。

4、软件项目就像鲨鱼，你需要不停地前进，同时要清楚自己的真实进度。

（实践中寻求真理，不要主观臆断）

5、最大的节拍就是迭代时间，一般是1－4周的时间。

每个迭代周期时间相同很重要，运用有规律的开发节奏，会更容易达到目标，并确保项目不停地前进。

6、每天结束的时候，测试代码，提交代码，没有残留的代码。

7、不要搞得经常加班。

以固定、有规律的长度运行迭代。

当与其它团队合作时，你需要减慢开发节奏。

8、一点点的成功也是一个很大的激励，小而可达到的目标会让每个人全速前进。