《高效程序员的45个习惯》读书笔记【思维导图】

《高效程序员的45个习惯》这是一本好书,书中的观点直白、朴素,极富实践性!当然最重要的,还是要在实际项目中身体力行!

下面摘取书中要点,花了大半天时间做成思维导图,以方便随时查阅。

高效程序员的45个习惯

1 宣言

1.1 个体和交互胜过过程和工具

1.2 可工作的软件胜过面面俱到的文档

1.3 客户协作胜过合同谈判

1.4 响应变化胜过遵循计划

2 原则

2.1 (一)态度决定一切

2.1.1  做事

1)指责不会修复Bug,把矛头对准问题的解决办法,而不是人

2)一个重大的错误应该被当作是一次学习而不是指责他人的机会

2.1.2  欲速则不达

1)不要坠入快速的简单修复之中,要投入时间和精力保持代码的整洁

2)不要让开发人员孤立的编写代码

3)阅读代码的频率越高越好

4)代码复审不仅助于代码更好理解,也是发现Bug最有效的方法之一

5)防止代码难懂的重要技术就是单元测试

6)所有大型系统都非常复杂,没有一个人能完全明白所有代码,除了深入 了解所负责的那部分代码,需要从更高层面来了解大部分代码,理解系统 各个功能块之间是如何交互的

7)实际工作中,可以先快速修复问题,即为了应对紧急情况,但事后一定好细致分析

2.1.3  对事不对人

1)询问你的队友,并提出你的顾虑

2)礼貌待人,负面的评论和态度会扼杀创新

3)必须把重点放在解决问题上,而不是极力证明谁的主意更好

4)能容纳自己并不接受的想法,表明你的头脑足够有学识

5)设计充满了妥协,工作中不感情用事是需要克制力,展现成熟大度来

6)团队能公正地讨论一些方案的优点和缺点

2.1.4  排队万难,奋勇向前

1)动手去做比光抱怨好得多

2)当发现问题时,不要试图掩盖问题,要诚实、勇敢说出实情,并与团队一起寻求好的解决办法

2.2 (二)学无止境

2.2.1  跟踪变化

1)迭代增量式的学习:每天计划用一段时间来学习新技术

2)了解最新行情:阅读博客、maillist等

3)参加线下技术活动

4)参加研讨会议

5)阅读好书

6)不需要精通所有技术,但要清楚知道行业的动向

7)明白为什么需要这项新技术,它试图解决什么样的问题?它可以被用在什么地方?

2.2.2  对团队投资

1)一个学习型的团队才是好的团队

2)每周要求团队中的一个人主持讲座,介绍新技术、工具或者书籍

3)坚持有计划有规律地举行讲座:持续、小步前进才是敏捷

2.2.3  懂得丢弃

1)学习新技术时,多问问自己,是否还在沿用旧的态度和方法

2)新技术会让人感到一点恐惧,但你的确需要学习它

2.2.4  打破砂锅问到底

1)为了解决问题,你需要知道许多可能的影响因素

2)当找人询问任何相关的问题时,让他们耐心地回答你的问题

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

2.2.5  把握开发节奏

1)许多不成功的项目中,基本上都是随意安排工作计划,没有任何的规律

2)敏捷项目会有一个节奏和循环,让开发更加轻松

3)最大的节拍就是迭代时间,一般是1-4周,确保每个迭代周期的时间相同很重要

4)项目开发需要有一致和稳定的节奏

5)在每天结束的时候,测试代码,提交代码,没有残留代码

6)不要搞得经常加班

2.3 (三)交付用户想要的软件

2.3.1  让客户做决定

1)开发者需要知道哪些是自己决定不了的

2)具体到游戏行业,客户分两类,一类是项目策划,他们是需求的提出者 故在设计开发前,需要与之作深入的沟通,明确他们的意图;一类是玩家, 他们是最终使用者,开发者可以站在玩家角度去分析策划案的价值和作用

2.3.2  让设计指导而不是操纵开发

1)时刻谨记,此阶段提出的设计只是基于你目前对需求的理解 而已,一旦开始了编码,一切都会改变

2)敏捷开发中,少用文字,多用图表来表达设计意图,常用序列图和类图

3)设计满足实现即可,不要过于详细

4)好的设计就是能适应变化的需要

5)先设计类的职责,再设计其方法和数据类型

1.类名

2.职责:应该做什么

3.协作者:要完成工作它要与其他们什么对象工作

6)白板、草图、便利贴都是好的设计工具,复杂的建模工具只会让你分散精力

2.3.3  合理的使用技术

1)这个技术框架真能解决问题吗

2)你将会被它拴住吗

3)维护成本是多少

4)不要开发你能下载到 东西

5)首先决定什么是你需要的,接着为这些具体的问题评估使用技术

2.3.4  保持可以发布

1)提交代码流程

1.确保自己编写的代码通过单元测试

2.检出最新代码,并再次运行测试

3.提交代码至版本管理服务器

2)持续集成系统就是在后台不停地检出、构建和测试代码的应用

3)保证你的系统随时可以编译、运行、测试并立即部署

4)如果不得不让系统长期不可以发布,则需要做一个分支版本

2.3.5  提早集成,频繁集成

1)决不要做大爆炸式的集成

2)代码集成是主要的风险来源,提早集成,持续面有规律地进行集成则可避免

3)集成和独立不是互相矛盾的,可以边进行集成,边进行独立开发

2.3.6  提早实现自动化部署

1)一开始就实现自动化部署应用

2)在不同的机器上用不同的配置文件测试依赖的问题

2.3.7  使用演示获得频繁反馈

1)每隔一周或两周,邀请所有客户,给他们演示最新完成的功能,积极获得他们的反馈

2)用Bug系统记录跟踪所有系统Bug

3)在游戏项目里,每完成一个迭代版本,尽早给策划同事及制作人演示,甚至在整个项目组测试演示 ,并收集大家反馈的Bug和建议

2.3.8  使用短迭代,增量发布

1)迭代开发是在小且重复的周期里,完成各种开发任务:分析、设计、实现、测试和获得反馈

2)游戏项目中,迭代时间最好是以一周为单位

2.3.9  固定的价格就意味着背叛承诺

1)需要根据业务复杂度、团队成员的能力水平、市场环境就诸多因素来评估项目的开发周期 这是一件很考验管理者(包括开发者)的经验与技术水平

2.4 (四)敏捷反馈

2.4.1  守护天使

1)敏捷就是管理变化的,而代码则是变化最频繁的东西

2)所谓守护天使即自动化的单元测试+后台自动构建

2.4.2  先用它再实现它

1)编程之前,先写测试

2)先写测试可以站在用户的角度来思考,并有利于消除过度复杂的设计

3)使用TDD作为设计工具

2.4.3  不同环境,就不同问题

1)在各种支持的平台和环境中运行测试用例

2.4.4  自动验收测试

1)为核心业务创建验收测试用例,这不同于单元测试

2)在游戏项目中,要分别为客户端和服务器创建验收用例,客户端侧重于表现效果验收, 服务器侧重于业务逻辑验收

2.4.5  度量真实的进度

1)每个工作日,团队成员要重新评估完成一个任务还需要多少小时

2)我的做法是每天在上班的路上想好当天要做的事情,在正式开工前,用google日历列出一天的任务列表, 列表的条目是具体可操作的工作,粒度的划分需要一定的经验,评估完工时间的单位是小时

2.4.6  倾听用户的声音

1)没有愚蠢的用户,只有自大的开发人员

2)每一个抱怨的背后都隐藏一个事实:找出真相,修复真正的问题

2.5 (五)敏捷编码

2.5.1  代码要清晰地表达意图

1)代码清晰程度的优先级应排在执行效率之前

2)编写清晰的而不是讨巧的代码

2.5.2  用代码沟通

1)不要用注释包裹你的代码

2)注释包含的信息:目的、输入、输出、异常,使用RDoc、javadoc、ndoc工具规范化注释

3)注释要说明为什么写代码,而不是解释代码做了什么

2.5.3  动态评估取舍

1)考虑性能、便利性、生产力、成本和上市时间,如果性能足够,则将注意力放在其他因素上

2)过早的优化是万恶之源

2.5.4  增量式编程

1)如果不对自己编写的代码进行测试,保证没问题,就不要连续几小时编程

2)写了几行代码之后,可以进行一次构建/测试循环,在没有得到反馈前,不要走太远

2.5.5  保持简单

1)除非有不可辩驳的原因,否则不使用模式、原则和高难度技术之类的东西

2)简单的解决方案必须要满足功能需求,不要过分简单

2.5.6  编写内聚的代码

1)要避免创建很大的类或组件

2)考虑实现一个简单的功能变化需要变更多少代码

2.5.7  告知,不要询问

1)开发人员绝对不应该基于被调用对象的状态做出任何决策,更不能去改变该对象的状态, 这样的逻辑应该是被调用对象的责任,而不是你的,即符合依赖倒置原则

2)要将功能和方法分为“命令”和“查询”两类

3)用发送消息或事件来代替调用函数

2.5.8  根据契约进行替换

1)通过替换遵循接中契约的类,来添加并改进功能特性

2)多使用委托而不是继承

2.6 (六)敏捷调试

2.6.1  记录问题解决日志

1)维护一个保存曾遇到的问题以及对应解决方案的日志

2)记录发生问题时应用程序、应用框架或平台的特定版本

2.6.2  警告就是错误

1)找到一种方式让编译器将警告作为错误提示出来

2)解释性语言通常也有标志,相用相关标志,然后捕获输出

2.6.3  对问题各个击破

1)不要试图马上了解系统所有细节,要想认真调试,就必须将有问题的组件或模块与其他代码分离出来

2)用原型进行分离

2.6.4  报告所有异常

1)处理或是向上传播所有的异常

2)不是所有的问题都应该抛出异常

3)报告的异常应该在代码的上下文中有实际意义

4)记录运行日志

2.6.5  提供有用的错误信息

1)提供详细的运行日志,记录运行状态

2)区分错误类型:程序缺陷、环境问题、用户错误

2.7 (七)敏捷协作

2.7.1  定期安排会面时间

1)立会:大家到公司的30-60分钟进行

1.昨天有什么收获

2.今天计划要做哪些工作

3. 面临着哪些困难

2)立会时,只能给予每个参与者很少的时间发言,如:两分钟

3)采取立会的形式需要管理层的承诺和参与

4)立会时间不要超过30分钟,10-15分钟比较理想

5)立会时,要注意报告的细节,只给出具体的进度,但不要陷入细节之中

2.7.2  架构师必须写代码

1)作为设计人员,不能理解系统具体细节,就不可能作出有效的设计

2)只通过一些高度概括的、粗略的设计图无法很好地理解系统

3)鼓励程序员参与设计,优秀的设计从积极的程序员那里开始演化

2.7.3  实现代码集体所有制

1)在团队中实行任务轮换制,让每个成员都可以接触到不同部分的代码

2)注意有些场合是不能采用代码集体所有制的,这时候,人多了反而容易误事

2.7.4  成为指导者

1)教学相长

2)分享自己的知识、经验和体会

2.7.5  允许大家自己有办法

1)作为指导者,应该鼓励、引领大家思考如何解决问题

2)用问题来回答问题,可以引导提问的人走上正确的道路

2.7.6  准备好后再共享代码

1)绝不要提交尚未完成的代码

2)完成一项任务后,应该马上提交代码

3)保证所有代码通过单元测试

4)使用持续集成是保证源代码控制系统没有问题的一种良好方式

2.7.7  做代码复查

1)代码刚完成时,是寻找问题的最佳时机

2)让不同的开发人员在每个任务完成后复查代码

3)运用静态代码检查工具,如:Similarity Analyzer、Jester

4)注意每次复查的代码量不宜过大,保持每次在1k Line以下

5)代码复查内容

1.代码能否被读懂和理解

2.是否有任何明显的错误

3.代码是否会对应用的其他部分产生不良影响

4.是否存在重复代码

5.是否存在可以改进或重构的部分

2.7.8  及时通报进展与问题

1)发布进展状态、新的想法和目前正在关注的主题,不要等别人来问题项目状态如何

2)每日立会让每个人都能明确了解最新进展和形势

3)可以作日报和周报来反馈项目进度

3 工具

3.1 Wiki

3.2 版本控制

3.3 单元测试

3.4 自动构建

4 宗旨

4.1 以人为本

4.2 团队合作

4.3 快速响应变化

4.4 可工作软件

5 核心:Just Do It!!!

【声明:若有摘录,请注明来自http://gameislife.info/archives/133】