起因是读了浅评计算机专业的课程教育这篇文章，对于文章观点我不予评价，我还不配，但是文中推荐了一本书，即本文的标题，《代码整洁之道：程序员的职业素养》
书并不厚，内容也不硬核，读起来还是没有什么负担的
虽然名字如此，但这本书并不教导组织大型项目代码的技巧，而是一些别的东西，一些被称为“程序员的职业素养”的东西，读完给了我一个从未有过的视角，确实值得推荐，只是在尚未面临就业的当下还是稍有遥远
专业
专业意味着负责，意味着不能容忍代码中的任何一个微小的bug，意味着不能因为偷懒放弃任何一个细节的测试。这也就引出了我平时编程不怎么注意的点——测试，大量的、涉及每个模块的、自动化的测试。
TDD
Test-Driven-Develop，测试驱动开发：1.先写测试再写功能代码 2.只要不通过测试，就不要继续写代码 3.代码只通过测试就可以了，不需要多写
相比于写完一个模块再整体运行时测试，这样显然不容易产生隐性的、难以察觉的bug，当然，代价就是大量的测试代码。测试使得任何模块都可以被修改——只要还能通过测试，理论上就不会让整个系统功能崩溃，而这就意味着代码可以被放心地频繁重构、修改，所谓“屎山”也就不会出现、或至少也是可以处理的了
同时依照此流程写出的代码天然具有良好的解耦性。
然而缺点也很显然——一切优点都建立在良好的测试代码上，而这并不容易
测试从上到下也分为好多种，书中称为自动化测试金字塔：覆盖率约100%的单元测试，由程序员负责；约占单元测试一半量的组件测试，借由模拟或测试辅助技术完成，由QA完成；单元测试约20%量的集成测试，指测试大量组件的写作，以确认架构的正确；单元测试约10%的量的系统测试，确保正确的系统构造（什么意思？）；以及最后的人工探索测试，在屏幕上通过键盘屏幕完成实际探索测试
练习
音乐家的技能不是在舞台上学习的，是台下的练习，程序员也一样，要想代码写得又快又好，就必须需要练习。
书中提到了一种名为kata的练习，编程kata是一套敲击键盘和鼠标的动作，用来模拟编程问题的解决过程，解决方案是熟悉的，但是解决问题的动作和决策是可以因此得到练习的
wasa是一种两个人的kata，比如一个人写kata一个人写单元测试这样
开源项目
严谨
这本不厚的书花了大力气去讲“说‘不’”与“说‘是’”。
说“不”，也就是在实际的工作环境中，一个专业的程序员应对领导或是客户的方法
程序员总是被要求在规定的时间内完成一些任务，本文的意思是，如果是专业的软件工程师，那么对不合理的时间要求就一定要拒绝。理由很简单，基于一个客观存在的现象：
泥潭：代码失去了简单与整洁，表面上还可以继续开发工作，实际上开发效率越来越慢，且几乎不可逆
于是自然有“越从容的代码越整洁，越利于项目进行；越着急的代码越脏乱，越不利于项目完成”的结论，而时间不足对代码质量的影响自是不言而喻
程序员需要对工作量有一个相对准确的预估，书中给了几个方法：
PERT
一种避免乐观评估的方法，策略是把预估变成概率分布
三元分析法，乐观预估（O）与悲观预估（P）——概率小于三个标准差的情况，与标称预估（N）——最有可能的情况
然后 $\mu = \frac{O + 4N + P}{6}$得到期望
$\sigma = \frac{P - O} {6}$得到标准差
概率分布得以估计出来
德尔菲法
核心是“共识”，彼此独立地估计时间，然后讨论达成共识，或是别的种种方式
而说“是”则是拒绝完成任务的含糊，尤其是在工作中。一个含糊的承诺会影响团队的工作进展，所以不要说“试试”这种话，给个明确的日期。
效率
编码是一项脑力劳动，故保持工作效率是很重要的。
这个话题我已经在其它地方接触的很多了，我并不认为本书说得更好
值得一提的是作者并不赞同“心流”下编码，认为这个状态虽然是愉悦的，却不一定是注意力真的高度集中的
书中还着重强调了“结对”，也就是找个编程搭子一起，的重要性
总结
TDD的思想是那么令人着迷，它许诺的整洁与便利确实值得我花费时间去仔细去学习去应用
至于书中的其它内容，或许当我面对其境遇时，会给我提供一些参考吧
路漫漫其修远兮，至少有个方向不是？