130 lines
5.2 KiB
Markdown
130 lines
5.2 KiB
Markdown
<!-- GFM-TOC -->
|
||
* [译者序](#译者序)
|
||
* [前言](#前言)
|
||
* [专业主义](#专业主义)
|
||
* [说不](#说不)
|
||
* [说是](#说是)
|
||
* [编程](#编程)
|
||
* [测试驱动开发](#测试驱动开发)
|
||
* [练习](#练习)
|
||
<!-- GFM-TOC -->
|
||
|
||
# 译者序
|
||
|
||
作者 Bob 大叔，著有《敏捷软件开发：原则、模式与实践》《代码整洁之道》《程序员的职业素养》
|
||
|
||
对于解决问题，重要的不是问题本身，而是解决问题的方式、步骤以及反思的深度，这就是职业素养。
|
||
|
||
# 前言
|
||
|
||
由于管理者面临很大的财务和政治压力，他们无视技术人员发出的危险警告，抱着侥幸心理发射了“挑战者”航天飞机，最终导致航天飞机在高空爆炸。虽说技术人员已经做很多事情去阻止这次发射，但是并不是说做了所有他们能做的，例如他们就没有打电话去新闻台揭露此次发射的危险性。
|
||
|
||
|
||
|
||
|
||
# 专业主义
|
||
|
||
专业主义不仅意味着荣誉和骄傲，也意味着责任。
|
||
|
||
作者在自己开发的一个电话线路故障检测系统时，因为赶着在到期日交付新功能，没有对整个系统进行测试，导致了一个 bug 的出现。作者认为这是一种不负责任的表现，也就是不专业的表现。
|
||
|
||
代码中难免有 bug，但是不意味着你不用为 bug 负责。
|
||
|
||
有人把 QA 当成查 bug 的机器，等着 QA 发现 bug，而自己却不主动去发现 bug，这是不对的。
|
||
|
||
为了保证代码的正确性，需要写一些随时可以运行的单元测试，并且不断地去运行它们。
|
||
|
||
软件项目的根本原则 - 易于修改。为了让自己的软件易于修改，需要经常去修改它！
|
||
|
||
单元测试可以让程序员更有自信去修改代码，因为它会让人确信修改地是否正确。
|
||
|
||
专业素养包括以下内容：
|
||
|
||
1. 坚持学习
|
||
2. 每天练习一些简单的编程题目
|
||
3. 与他们合作，从彼此身上学到更多东西
|
||
4. 交流。通过交流表达自己的思想，发现自己的不足以及与别人思想上的差异。
|
||
5. 了解业务领域，找几本相关领域的书看。
|
||
6. 与雇主 / 客户保持一致
|
||
7. 谦逊，因为他们知道自己也可能犯错。
|
||
|
||
# 说不
|
||
|
||
对一些不合理的要求，不能只是说“试试看”，这会被当成是接受了这个要求。如果自己深知这种不合理的要求会导致严重的后果，就不能任由它发展下去，对这一要求说“不”。
|
||
|
||
说“不”时要用最详细的细节来说明，而不是烦躁地反驳。
|
||
|
||
当要求明显不合理时，可以协商一些双方都能接受的方案。
|
||
|
||
"有可能写出好代码吗" 这篇博文，讲述了一次开发一家零售商为了在"黑色星期五"能够让顾客看到商品信息商店信息以及发布优惠码等功能的 ipone 应用，最开始零售商的经理承诺说只要写个硬编码的应用就行了，但是客户所要的任何一项功能，总比它最开始时所说的要复杂许多。面对时间的紧急，客户方的不配合，以及需求的变更，让博文作者写了一堆很烂的代码，而他自己确实对那些设计模式等高级开发技术是非常热衷的。所以他认为在实际的开发中因为客户的需求等因素，很难写作自己想写的代码。Bob 认为，上面那篇博文的作者才是此次开发过程碰到的那些问题的负责人，因为他没有对那些不合理的要求说不。
|
||
|
||
# 说是
|
||
|
||
做出承诺的是三个步骤：口头上答应，放在心里，付诸行动。
|
||
|
||
缺乏承诺的词语：
|
||
|
||
1. 需要：我需要把这事做完；
|
||
2. 希望：希望今天我能完成任务；
|
||
3. 让我们：让我们把这件事做完。
|
||
|
||
缺乏承诺的人不会把重点放在自己身上，也不会明确说明一件事情的截止日期。真正的承诺是这样的“我会在...之前...”
|
||
|
||
对自己无法完全掌握的事，不要轻易承诺。
|
||
|
||
发现自己无法做到承诺，立马去调整别人对你的预期。
|
||
|
||
“试试看”说明自己对承诺的内容有点顾忌，因此不要用试试看来作为一种承诺。如果不能确信自己能达到承诺的内容而随便承诺，那么最后往往会产生严重的后果。
|
||
|
||
# 编程
|
||
|
||
要精通一项技术，要对该技术具备“信心”和“感知能力”。
|
||
|
||
状态不好的时候最好别写代码。状态不好分为：疲劳，比如熬夜；焦虑，因为外界的事情让自己不能安心下来，这个时候应该下调整好再进行编程。
|
||
|
||
进入流状态的感觉很好，觉得可以做很多事，但是流状态其实是一种浅层冥想，思维能力会下降，因此要避免进入流状态。
|
||
|
||
|
||
|
||
流状态的特点是隔绝沟通，而结对编程能够打破这种隔绝，因此结对编程能够防止进入流状态。
|
||
|
||
当自己没法继续编程时，结对编程是个好选择，结对编程时，大脑和身体会有化学变化，也就是说思维方式会改变，有助于突破当前的思维阻塞状态。
|
||
|
||
听音乐时音乐会占用一部分脑力资源，因此会导致效率下降，但是这不是绝对。
|
||
|
||
多输入一些创造性的内容，比如科幻小说等，自己的创造力也会得到提升。
|
||
|
||
调试时间也很宝贵，测试驱动开发能够降低调试的时间。
|
||
|
||
编码和跑马拉松一样，无法全程以最快的速度冲刺，只能通过保持体力和维持节奏来取得胜利。因此要保持好自己的节奏，在疲劳的时候适当休息。
|
||
|
||
定期做进度衡量，用乐观预估、标准预估和悲观预估这三个时间点。
|
||
|
||
如果自己预估的进度赶不上截止时间，不要答应在截止时间去完成，因为你知道根据自己的预估这是不可能的。
|
||
|
||
任务完成的标准通常用一个自动化的验收测试来定义。
|
||
|
||
帮助他人也会给自己带来好处，在帮助别人的时候不要让自己看起来很仓促，就像是在随便应付。一般帮助别人不需要特别多的时间。也要学会请求别人的帮助，因为自己不可能是万能的，通过别人的帮助能更好的解决问题。
|
||
|
||
# 测试驱动开发
|
||
|
||
TDD 的运行周期很短，可能一两分钟就可以运行一次程序，短周期可以快速得到反馈，反馈在开发中特别重要，一方面是提高程序员编码的激情，另一方面是能够及早发现 bug，而 bug 越早发现修改地代价也越低。
|
||
|
||
TDD 三法则：
|
||
|
||
1. 先写测试；
|
||
2. 在一个单元测试失败的时候，不要再写测试代码；
|
||
3. 产品代码能恰好通过当前失败的单元测试即可，不要多写。
|
||
|
||
TDD 优点
|
||
|
||
1. 确定性：确定当前系统是否正确；
|
||
2. 信心：程序员更有信息去修改混乱的代码，因为通过单元测试可以知道是否修改地正确；
|
||
3. 文档：单元测试是底层设计细节的文档，通过阅读单元测试能够知道程序的运行方式；
|
||
|
||
# 练习
|
||
|
||
卡塔在武术里面是一套设计好的招式，该招式模拟真实搏斗场景，习武者不断训练来让身体熟悉该招式，从而做到纯熟。编程卡塔是一套编程过程敲击鼠标和键盘的动作，练习者不是为了解决真正的问题，因为已经知道了解决方案，而是练习解决这个问题所需要的动作和决策。
|
||
|
||
瓦萨即使两人对练的卡塔。在编程领域，可以是一个人写单元测试，另一个人写程序通过单元测试。比如，一个人实现排序算法，写测试的人可以很容易地限制速度和内存，给同伴施压。
|