在公司实习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、一点点的成功也是一个很大的激励，小而可达到的目标会让每个人全速前进。
第二篇：程序员45个好习惯
优秀来自好的习惯。怎样成为优秀的开发人员？图灵公司最近热销的《高效程序员的45个习惯》一书给出了很好的解答，非常值得一读。 这本书的英文原版荣获了有软件奥斯卡之称的Jolt生产效率大奖，在Amazon上也是好评如潮。第一作者Venkat Subramaniam博士是Agile Developer公司创始人，敏捷开发方面的权威人士，精通各种开发技术。第二作者Andy Hunt更是大名鼎鼎的人物，是敏捷宣言的创始人，著名图书出版公司Pragmatic Programmers的创始人。他有两本书大家应该都是知道：经典的Ruby教程《Programming Ruby》还有许多开发人员的最爱《程序员修炼之道》。
译者团队则由著名的敏捷咨询公司ThoughtWorks咨询师钱安川和InfoQ中文站敏捷社区首席编辑、《程序员》杂志前副主编郑柯组成，可以信赖。
值得一提的是，这本书很像《程序员修炼之道》在敏捷时代的续篇。风格和写法都很神似。下面是从书中摘出的45个习惯标题，每个标题下面的文字是我读此书的笔记摘要。另外，图灵公司还在官方博客上提供了几个章节免费阅读（下面给出了链接）。
强烈推荐大家将这些打印出来，贴在自己的办公桌旁边的墙上，学习实践。 态度篇
1. 做实事
不要抱怨，发牢骚，指责他人，找出问题所在，想办法解决。对问题和错误，要勇于承担。
2. 欲速则不达
用小聪明、权宜之计解决问题，求快而不顾代码质量，会给项目留下要命的死角。
3. 对事不对人
就事论事，明智、真诚、虚心地讨论问题，提出创新方案。
4. 排除万难，奋勇前进
勇气往往是克服困难的唯一方法。
学习篇
5. 跟踪变化
新技术层出不穷并不可怕。坚持学习新技术，读书，读技术杂志，参加技术活动，与人交流。要多理解新词背后的所以然，把握技术大趋势，将新技术用于产品开发要谨慎。
6. 对团队投资
打造学习型团队，不断提高兄弟们的平均水平。
7. 懂得丢弃
老的套路和技术，该丢，就得丢。不要固步自封。
8. 打破砂锅问到底
不断追问，真正搞懂问题的本质。为什么？应该成为你的口头禅。
9. 把握开发节奏
控制好时间，养成好习惯，不要加班。
开发流程篇
10. 让客户做决定
让用户在现场，倾听他们的声音，对业务最重要的决策应该让他们说了算。
11. 让设计指导而不是操纵开发
设计是前进的地图，它指引的是方向，而不是目的本身。设计的详略程度应该适当。
12. 合理地使用技术
根据需要而不是其他因素选择技术。对各种技术方案进行严格地追问，真诚面对各种问题。
13. 让应用随时都可以发布
通过善用持续集成和版本管理，你应该随时都能够编译、运行甚至部署应用。
14. 提早集成，频繁集成
集成有风险，要尽早尽量多地集成。
15. 提早实现自动化部署
16. 使用演示获得频繁反馈
17. 使用短迭代，增量发布
18. 固定价格就意味着背叛承诺
估算应该基于实际的工作不断变化。
用户篇
19. 守护天使
自动化单元测试是你的守护天使。
20. 先用它再实现它
测试驱动开发其实是一种设计工具。
21. 不同环境，就有不同问题
要重视多平台问题。
22. 自动验收测试
23. 度量真实的进度
在工作量估算上，不要自欺欺人。
24. 倾听用户的声音
每一声抱怨都隐藏着宝贵的真理。
编程篇
25. 代码要清晰地表达意图（免费样章链接）
代码是给人读的，不要耍小聪明。
26. 用代码沟通
注释的艺术。
27. 动态地进行取舍（免费样章链接）
记住，没有最佳解决方案。各种目标不可能面面俱到，关注对用户重要的需求。
28. 增量式编程
写一点代码就构建、测试、重构、休息。让代码干净利落。
29. 尽量简单
宁简勿繁。如果没有充足的理由，就不要使用什么模式、原则和特别的技术。
30. 编写内聚的代码
类和组件应该足够小，任务单一。
31. 告知，不要询问
多用消息传递，少用函数调用。
32. 根据契约进行替换
委托往往优于继承。
调试篇
33. 记录问题解决日志（免费样章链接）
不要在同一地方摔倒两次。错误是最宝贵的财富。
34. 警告就是错误
忽视编译器的警告可能铸成大错。
35. 对问题各个击破（免费样章链接）
分而治之是计算机科学中最重要的思想之一。但是，要从设计和原型阶段就考虑各部分应该能够很好地分离。
36. 报告所有的异常
37. 提供有用的错误信息（免费样章链接）
稍微多花一点心思，出错的时候，将给你带来极大便利。
团队协作篇
38. 定期安排会面时间
常开会，开短会。
39. 架构师必须写代码（免费样章链接）
不写代码的架构师不是好架构师。好的设计都来自实际编程。编程可以带来深入的理解。
40. 实行代码集体所有制
让开发人员在系统不同区域中不同的模块和任务之间轮岗。
41. 成为指导者
教学相长。分享能提高团队的总体能力。
42. 让大家自己想办法（免费样章链接）
指引方向，而不是直接提供解决方案。让每个人都有机会在干中学习。
43. 准备好后再共享代码
不要提交无法编译或者没有通过单元测试的代码！
44. 做代码复查
复查对提高代码质量、减少错误极为重要。
45. 及时通报进展与问题（免费样章链接）
主动通报，不要让别人来问你。