技术人员往往太容易说“是”，总是在没有明确目标和期限的情况下，就草率给出了确认的答复，却不将其视为自己的承诺。屡见不鲜的项目延期，有相当原因就是在这种不负责任的情况下说“是”所致。
感想：在项目开始时的需求评审和设计评审很重要，并且各方都要根据工作量、资源等实际情况评估时间，给出了时间就要尽量完成，否则就不要轻易承诺需求。
要诚信，要富有荣誉感、自尊心和自豪感，要勇于承担作为一名手艺人和工程师所肩负的重大责任。这种责任包括要努力工作，出色完成任务；要擅于沟通，能够就事论事；要管理好时间，能够坦然面对艰难的“风险回报”角色。
感想：工匠精神要求不仅有熟练的技艺，还要有本职业的素养。
专业主义
做个非专业人士可轻松多了。非专业人士不需要为自己所做的工作负责，他们大可把责任推给雇主。如果非专业人士把事情搞砸了，收拾摊子的往往是雇主；而专业人士如果犯了错，只好自己收拾残局。专业主义的精髓就在于将公司利益视同个人利益。
感想：不要想着上司、公司会替自己的错误负责，要将公司利益视为自己的利益。
不要破坏软件功能，要对自己的不完美负责，失误率永远不可能等于零，但你有责任让它无限接近零：让QA找不出任何问题，每次QA找出问题时，更糟糕的是用户找出问题时，你都该震惊羞愧，并决心以此为戒；要确信代码正常运行，编写单元测试，设计易于测试的代码（TDD）；自动化QA，作为开发人员，需要有个相对迅速可靠的机制，以此判断所写的代码可否正常工作，并且不会干扰系统的其他部分。
感想：程序不可能无bug不是借口，程序员有责任做到最好。
不要破坏结构，如果你希望自己的软件灵活可变，那就应该时常修改它。要想证明软件易于修改，唯一办法就是做些实际的修改。让软件保持固定不变才是危险的。
感想：不要畏惧更改代码，越是畏惧，说明对自己编写的代码越是没底，要在一开始就设计出结构合理的代码，才是解决问题的根本。
职业道德
1、了解你的领域
每个专业软件开发人员必须精通的事项：
设计模式：必须能描述GOF书中的全部24种模式，同时还要有POSA书中的多数模式的实战经验
设计原则：必须了解SOLID原则，而且要深刻理解组件设计原则
方法：必须理解XP、Scrum、精益、看板、瀑布、结构化分析及结构化设计等
实践：必须掌握测试驱动开发、面向对象设计、结构化编程、持续集成和结对编程
工作：必须了解如何使用UML图、DFD图、结构图、Petri网络图、状态迁移图表、流程图和决策表
2、坚持学习
3、练习
4、合作
5、辅导
6、了解业务领域
最糟糕、最不专业的做法是，简单按照规格说明来编写代码，但却对为什么那些业务需求要那样的规格定义不求甚解。相反，你应该对这一领域有所了解，能辨识、质疑规格说明书中的错误
7、与雇主/客户保持一致
8、谦逊
感想：一个合格的程序员要有专业技能及业务知识，并且会不断学习
说“不”
能就是能，不能就是不能，不要说“试试看”。
专业人士敢于说明真相而不屈从于权势，专业人士有勇气对他们的经理说“不”。
感想：你的上级可能并不怕你说“不”，但是要的是你说“不”的同时能给出可视化的数据和合理的解释。
程序员也自有其工作职责所在，绝大多数程序员也知道该如何出色地尽职尽责。如果他们是专业程序员的话，他们也会竭尽所能地去追求和捍卫自身的目标。
感想：当双方各表异议相互说不时，应当用双方都能接受的解决方案来解决，这才是专业的表现。
最要说“不”的是那些高风险的关键时刻，越是关键时刻，“不”字就越具价值。
具备团队精神，意味着恪尽职守，意味着当其他队员遭遇困境时你要援手相助。有团队精神的人会频繁与大家交流，会关心队友，会竭力做到尽职尽责。真正为团队努力的人会根据自己最好的能力情况，明确说明哪些是做得到的事，哪些是做不到的事。
感想：优秀的程序员不仅在于写代码有多好多快，更在于专业的思维与行动，能根据实际情况评估工作量及风险。
许诺尝试，就意味着你承诺自己之前未尽全力，承诺自己还有余力可施。许诺“尝试”，意味着只要你再加把劲还是可以达成目标的；而且，这也是一种表示你将再接再厉去实现目标的承诺。因此，只要你许诺自己会去“尝试”，你其实是在承诺你会确保成功。这样，压力就要由你自己来扛了。如果你的“尝试”没有达到预期的结果，那就代表你失败了。如果承诺尝试，你其实也在承诺将改变自己原来的方案。你是在承认原来的方案中存在不足。如果承诺尝试，你其实是在告诉他们，你有新方案。新方案是什么？你将对自己的行为做出哪些改变？你说你在“尝试”，那么你的做法将会有何不同？
感想：不要轻易说“试一试”。要专业地在项目开始时就设计尽可能合理的计划。
成为英雄及“解决问题”的诱惑诚然巨大，只是我们要明白，牺牲专业原则以求全，并非问题的解决之道。舍弃这些原则，只会制造出更多的麻烦。
感想：我们的目标是专业地解决问题，背后的功与名只是附属品，如果直接追求结果和功与名，则和我们的原则背道而驰。
说“是”
作出承诺，包含三个步骤
1、口头上说自己将会去做
2、心里认真对待作出的承诺
3、真正付诸行动
真正的承诺：你对自己将会做某件事做了清晰的事实陈述，而且还明确说明了完成期限。
之所以没成功，是因为我寄希望于某某去做这件事，你只能承诺自己能完全掌控的事。如果最终目标依赖于他人，那么你就应该采取些具体行动，接近最终目标。
之所以没成功，是因为我不太确信是否真能完成得了。
之所以没成功，是因为有些时候我真的无能为力。如果你无法兑现承诺，那么最重要的就是尽早向你的承诺对象发出预警，越快越好，越早越好。如果你不尽早告诉他人可能的问题，就错失了让他们帮助你达成目标、兑现承诺的机会。
专业人士不需要对所有请求都回答“是”。不过，他们应该努力寻找创新的方法，尽可能做到有求必应。当专业人士给出肯定回答时，他们会使用正式的承诺，以确保各方面能 明白无误地理解承诺的内容。
感想：没有人可以保证绝对的事，但是我们可以通过量化工作、评估风险，用数据说明事实，没人会持反对意见；并且当中途出现意外时，要第一时间抛出问题，让大家帮忙实现原本的目标，或是制定另一个可行的解决方案，或是重新评估时间。
编码
具备出错感知能力，说明你已经能够非常迅速地获得反馈，能够更为快速地从错误中学习。
做好准备：
1、首先，代码必须能够正常工作
2、代码必须能够帮你解决客户提出的问题
3、代码必须要能和现有系统结合得天衣无缝
4、其他程序员必须能读懂你的代码
结对是用以应对中断的一种好方法，当你接答电话或回答其他同事的问题时，结对搭档能够维护住中断处的上下文，等到你重新回去和结对搭档一起工作时，他能够很快地帮你恢复被打断前的思维。另一种很有帮助的方法便是采用TDD，失败的测试能帮你维护住编码进度的上下文，当处理完中断重新回去时，你很清楚下一步任务便是让这个失败的测试通过。
医生不喜欢重新打开病人的胸腔去修复此前犯下的错误，律师不喜欢重新接手此前搞砸的案子。经常重新返工的医生或律师会被认为不专业。同样，制造出许多bug的软件开发人员也不专业。
管理延迟的诀窍，便是早期监测和保持透明。
要让团队和利益相关者明白这个趋势，除非另有后备预案，否则不要轻易松口退步。
如果老板无法向你清楚说明加班方案失败的后备预案，那么你就不该同意接受加班方案。
可以通过创建一个确切定义的“完成”标准来避免交付失败，最好的方法是让业务分析师和测试人员创建一个自动化的验收测试。
感想：专业的程序员，对自己写的代码负责，只要是能提高编码质量的方法都不应该拒绝
测试驱动开发
TDD的三项法则：
（1）在编好失败单元测试之前，不要编写任何产品代码
（2）只要有一个单元测试失败了，就不要再写测试代码；无法通过编译也是一种失败情况
（3）产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写
TDD是专业人士的选择，它是一项能够提升代码确定性、给程序员鼓励、降低代码缺陷率、优化文档和设计的原则。
验收测试
验收测试是业务方与开发方合作编写的测试，目的是沟通、澄清、精确化。开发方、业务方、测试方对验收测试达成共识，大家都能明白系统的行为将会是怎样。
验收测试都应当自动进行。
通常，业务分析员测试正确路径，以证明功能的业务价值；QA则测试错误路径、边界条件、异常、例外情况，因为QA的职责是考虑哪些部分可能出问题。
借助GUI背后的API来测试业务逻辑。
在持续集成系统里，失败的集成应该视为紧急情况，也就是“立刻中止”型事件。
测试策略
QA应该找不出任何错误
1、QA也是团队的一部分
2、需求规约定义者
3、特性描述者
自动化测试金字塔：单元测试->组件测试->集成测试->系统测试->人工探索测试
时间管理
感想：要追求有效的会议，会议要有目标，明确重点，数据大于争论，如果对自己的有效信息少可以选择离开；通过时间管理高效工作，如果陷入泥潭或者死胡同要及时停下工作；会议成本估算很有意思
预估
期望完成时间=（乐观预估+4*标称预估+悲观预估）/6 避免乐观预估
专业开发人员懂得如何为业务人员提供可信的预估结果，以便做出计划。如果做不到忙活着不确定能做到，专业开发人员不会给出承诺。
专业开发人员一旦做了承诺，就会提供确定的数字，按时兑现。但是大多数情况下，他们都不会做这种承诺，而是提供概率预估，来描述期望的完成时间及可能的变数。
对需要妥善对待的预估结果，专业开发人员会与团队的其他人协商，以取得共识。
压力
如果在危机中改变行为，就说明你并不真正相信常规行为中的原则。选择那些你在危机时刻依然会遵循的纪律原则，并且在所有工作中都遵守这些纪律。
协作
将代码所有权的各种隔断全部打破，由整个团队共同拥有全部代码的做法，相较于此则要好得多。
专业人士并不会仅凭一己之力从零开始创建知识，而是通过互相结对来学习系统的不同部分和业务。专业人士之所以结对，是因为结对是复查代码最好的方式。系统中不应该包含未经其他程序员复查过的代码。
团队与项目
专业的开发组织会把项目分配给已形成凝聚力的团队，而不会围绕着项目来组件团队。一个有凝聚力的团队能够同时承接多个项目，根据成员各自的意愿、技能和能力来分配工作，会顺利完成项目。
辅导、学徒期与技艺
建立一种包含学徒期、实习期和长期指引的机制已是迫在眉睫。