1. 什么样的代码是有缺陷的呢？哪些你没把握的代码都是！
2. 如果你希望自己的软件灵活可变，那就应该时常修改它！ 该在什么时候做这些简单的小修改呢？随时！关注哪个模块，就对它做点简单的修改过来改进结构.每次通读代码的时候，也可以不是调整一下结构
3. 把switch语句改为多态结构，或者将继承层次重构成一条“命令链”
4. 每个专业软件开发人员必须精通的事项：
- 设计模式。必须能描述GOF书中的全部24种模式，同时还要有POSA书中的多数模式的实战经验。
- 设计原则。必须了解SOLID原则，而且要深刻理解组件设计原则。
- 方法。必须理解XP、Scrum、精益、看板、瀑布、结构化分析以及结构化设计等。
- 实践。必须掌握测试驱动开发、面向对象设计、结构化编程、持续集成和结对编程。
- 工件。必须了解如何使用UML图、DFD图、结构图、Petri网络图、状态迁移图表、流程图和决策图。
5. 做出承渃，包含三个步骤
- 口头上说自己将会去做
- 心里认真对待做出的承诺
- 真正付诸行动
你问IT部的人“为什么网络这么慢”，他说：“是啊。我们真得再弄些新路由器了。”听到这种回答时，你知道这件时后续不会有任何进展。
你要求项目组的某位成员在检入源代码之前先做些手工测试，他回答说：“好的。希望今天下班前能到这一步。”你会感觉明天还得再问问他在检入代码前到底做了测试没。
老板走进你的办公室，嘴上念叨着“我们的进度得再快点儿才行”。这时，你知道他的真实意思是你的进度得再快点儿。因为他自己并不会亲自参与进来。
以下示例中包含的几个用词和短语，会透露“缺乏承诺”的蛛丝马迹，要注意搜寻。
需要、应当。“我们要把这活做完。”“我需要减肥。”有人应当负责去推动这件事“”
希望/但愿。“希望明天我能完成这个任务”。“希望改天我们能再见面”
让我们（而不是让我）。 “让我们回头再见”。 “让我们把这事做完”
真正的承诺听起来是怎样的
例如：我将在....之前...（我将在周二之前完成这个任务）
6. 编码要求
- (1)首先，代码必须能够正常工作；
- (2)代码必须能够帮你解决客户提出的问题；
- (3)代码必须要和现有系统结合得天衣无缝。你的代码不能让系统变得更僵硬、更脆弱、更晦涩，必须要妥善管理好各种依赖关系；
- (4)其他程序员必须能读懂你的代码。这不仅包括写好注释这类事，还包括要精心锤炼代码，使它能够表达你的编程意图。
如果感到疲劳或心烦意乱，千万不要勉强编码。强而为之，最终只能再回头返工。
7. 测试驱动开发(TDD三项原则)
- (1)在编好失败单元测试之前，不要编写任何产品代码；
- (2)只要有一个单元测试失败了，就不要写测试代码；无法通过编译也是一种失败情况。
- (3)产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写。
8. 时间管理
会议：
（1） 如果会议让人厌烦，就离席；你可以解释说，自己抽不出更多时间用于这场会议；
（2）如果收到会议邀请，务必弄清楚指定的议题是什么，每个议题花多长时间，要取得什么成果。如果得不到确切的答案，你可以礼貌拒绝。
9. 承诺与预估
承诺是必须做到的。如果你承诺在某天做完某事，就必须按时完成，即使它意味着你必须每天工作12小时，放弃周末的休假，也不得不如此。
预估是一种猜测。它不包含任何承诺的色彩。它就不要做任何约定。预估错误无关声誉。我们之所以要预估，是因为我们不知道到底要花多少时间。
预估任务时间：三元分析法
预估是非常容易出错的，所以才叫预估。控制错误的办法之一是使用大数定律。意思是：把大任务分成许多小任务，分开预估再加总，结果会比单独评估大任务要精确很多。这样做之所以能够提高准确度，是因为小任务的预估错误几乎可以忽略，不会对总的结果产生明显影响。
10. 结对编程
结对是复查代码最好的方式。系统中不应该包含未经其他程序员复查过的代码。最有效率最有效果的代码复查方法，就是以相互协作的方式完成代码编写。
11. 有凝聚力的团队
1.发酵期
成员客服个体差异性，默契配合，彼此信任，形成真正有凝聚力的团队，是需要一些时间的，可能需要6个月，甚至1年。但是，凝聚力一旦真正形成，就会产生一种神奇的魔力。团队的成员会一起做计划，一起解决问题，一起面对问题，一起搞定一切。
团队已经有了凝聚力，但却因为项目结束了就解散了这样的团队，则是极为荒谬的。最好的做法是不拆散团队，让他们继续合作，只要不断把新项目分派给他们就行。
2.团队和项目，何者为先
试图围绕项目来构建团队。这是一种愚蠢的做法，按照这种做法，团队永远都不可能形成凝聚力。每个人都只在项目中的过客，只有一部分时间是为项目工作，因此他们永远都学不会如何默契配合。
专业的开发者组织会把项目分配给已形成凝聚力的团队，而不会围绕项目来组建团队。一个有凝聚力的团队能够同时承接多个项目，根据成员各自的意愿、技能和能力来分配工作，会顺利完成项目。
团队比项目更难构建。因此，组建稳健的团队，让团队在一个又一个项目中整体移动共同工作是比较好的做法。在组建团队时，要给予团队充足的时间，让他们形成凝聚力，一直共同工作，成为不断交付项目的强大引擎。
网友评论