代码整洁之道，不止于程序员需要的职业素养

代码整洁之道，不止于程序员需要的职业素养

最近在读《代码整洁之道》这本书，分享一些我的感悟。首先得说明一下这本书是一本技术类的书籍，大部分内容讲的是纯技艺方面的知识，比如测试驱动开发、阻塞、调试、编程练习等等，也就是“术”，但我分享的主要不是这方面，而是分享书中的职业素养的部分。
在还是学生的时候，做起事来就凭着真性情，想怎么弄就怎么弄，代码想怎么写就怎么写，甚至不写都可以。但到了公司，就不是任由你怎么来就怎么来，而是要有职业素养。作为职业开发人员，基本技能不够熟练，谈不上职业素养。但仅仅能迅速地编写代码，不关心代码背后的意义，不能迅速判断、解决程序运行中的各种问题，不能自信满满地为自己交付的程序承担责任，同样也谈不上职业素养。
本书主要是从态度、原则、行动方面定义专业的程序员。那么，成为一名专业的程序员需要什么样的态度、原则和行动呢？下面分享一些书中的观点。
专业主义
了解你的领域
近50年来，各种观点、实践、技术、工具与术语在我们这一领域层出不穷，如果想要成为一名专业的开发者，就需要对其中的大部分有所了解，而且要不断地扩展这一知识面。行业在迅猛发展，而有趣的是从多方面看，这种进展只是很浅层的。比如我们不再需要花12个小时苦苦等待计算机编译程序了，我们也已经可以写出GB级别的系统了，我们处在“地球村”，各种信息唾手可得。但另一方面，我们还是跟50年前一样，写着if/else和while语句。所以改变说多也不多，说少也不少。过去50年积累的知识来之不易，绝大部分在今天仍像过去一样有价值，所以开发人员必须精通其中的知识。比如设计模式、设计原则、方法（精益、看板、瀑布、结构化设计）、实践（测试驱动开发、面向对象设计、结构化编程、持续集成、结对编程）、工件（图表之类的）。
坚持学习
软件行业飞速改变，意味着软件开发人员必须坚持广泛学习才不至于落伍，不写代码的架构师必然遭殃，他们会很快发现自己跟不上时代了；不学习新语言的程序员同样也会遭殃，他们只能眼睁睁看着软件业一路发展，把自己抛在后面；学不会新规矩、新技术的开发员更可怜，他们只能再日渐沦落的时候看着身边的人越发优秀。
练习
业精于勤。真正的专业人士往往勤学苦干，以求得自身技能的纯熟精炼。只完成日常工作不足以称为练习，练习指的是工作之余专门练习技能，以期自我提升。
合作
专业的开发人员往往会更加努力地尝试与他人一起编程、一起练习、一起设计、一起计划，这样他们可以从彼此身上学到更多的东西，而且能在更短的时间内更高质量地完成更多工作。
了解业务领域
每位专业的软件开发人员都有义务了解自己开发的解决方案锁对应的业务领域。如果编写财务系统，你就得对财务领域有所了解；如果编写旅游应该程序，那么你需要去了解旅游业。你未必需要成为该领域的专家，但你需要用功，付出相当的努力来认识业务领域。
谦逊
编程是一种创造性活动。写代码是无中生有的创造过程，我们大胆地从混沌之中创造秩序。我们自信地发布准确无误的指令，稍有差错，机器的错误行为就可能造成无法估量的损失。因此，编程也是极其自负的行为。
学会说“不”
奴隶没有权利说“不”，劳工或许对说“不”有所顾虑。但是专业人士应该懂得说“不”。事实上，优秀的经理人对于敢于说“不”的人，总是求贤若渴。因为只有敢于说“不”，才能真正做成一些事情。
对抗角色
每位经理都承担着工作职责，绝大部分经理也知道该如何尽职尽责。其中一部分的工作职责，便是要竭尽所能追求和捍卫他们设定的目标。同样，程序员也自有其工作职责所在,绝大多数程序员也知道该如何出色地尽职尽责。你的经理要求你在明天之前完成登录页面，这就是他在追求和捍卫的一个目标，那是尽他的工作职责。如果你明知第二天之前不可能完成登录页面，嘴上却说”好的，我会试试的“，那么便是你失职了。这时候，尽职的唯一选择是说”不，这不可能“。然后找到双方都能接受的方案。
”为什么“重要吗？
或许你觉得应该解释下为什么“登录页面”还要花那么长时间才能完成。我的经验是，”为什么“远不如“事实”重要。事实是，“登录页面”还需要两周才能完成。而为什么需要两周，则只是个细节。尽管这样，知道”为什么”可能还是会有助经理了解并接受事实。那是最好不过的了。如果你的经理恰好有技术背景和好脾气去倾听理解，这些解释也许会有用。另一种情况则是，你的经理可能会不认同你的结论结论，他可能会告诉她不用做完整的测试和代码审查，或者可以把第12步省略掉，诸如此类。有时候，提供太多细节，只会招致更多的微观管理。
信守承诺
今天的程序员肯定得去面对诸如估算、确定最后期限以及面对面交流等沟通活动。做出承诺或许听起来令人有点害怕，但它能够帮助程序员解决在沟通中可能发生的不少问题。如果你能够一直信守承诺，大家会觉得你“是一名严谨负责的开发人员”。在我们这行中，这也是最有价值的评价。
专业的开发人员不需要对所有的请求都回答“是”。不过应该努力寻找创新的方法，尽可能做到有求必应。当他们给出肯定的回答时，他们会使用正式的承诺，以确保大家能明白无误地理解承诺的内容。
编码情景
疲劳或者焦虑下写下的代码
疲劳的时候千万不要写代码。奉献精神和职业素养更多意义上指要遵循纪律原则而非成为长时间工作的工作狂，要确保自己已经将睡眠、健康和生活方式调到最佳状况，这样才能做到在每天的8小时工作时间内全力以赴。
理想情况下，应该使用私人时间去解决私人问题。专业开发人员善于合理分配个人时间，以确保工作时间段中尽可能富有成效。也即是说，在家中时就应该专门安排时间去解决焦虑，这样就不会把焦虑情绪带到办公室里。另一方面，如果发现自己虽然人坐在办公室里，但内心的焦虑正在不断削弱工作效率，那么最好还是花上一个小时让它们先安静下来，这要好过硬逼自己去写代码，因为这样憋出来的代码以后也将不得不抛弃（如果还要与之长期相伴，那就更糟糕了）。
流态区
流态区指的是一种高效率的状态。开发人员在编写代码时会进入一种意识高度专注但思维视野会收拢到狭窄的状态，在这种状态下，他们会感到效率极高并且“绝无错误”。看到这你可能明白了：这种意识状态并非真的极其高效，也绝非毫无错误，这其实是一种“浅层冥想”状态，在这种状态下，为了追求所谓的速度，理性思考的能力会下降。
在流态区，你可能可以敲出更多的代码，但在这种状态下，你其实放弃了顾及全局，因此你很有可能会做出一些后来不得不推倒重来的决策。
写代码时听音乐
过去书中的作者习惯边听音乐边写代码，那会以为这样有助于集中注意力。直到有一天，作者回顾某个模块的代码，发现代码的注释里包含着歌词。这对作者的触动很大，作为看代码的人，是想看到这段代码试图解决的问题，而不是歌词。作者认为，听音乐无法写好代码，音乐并没有让人专注写代码，事实上听音乐还会耗费一部分宝贵的脑力资源，而这些资源本该用于编写设计良好的整洁代码。
被人打断
当你正在专心工作被人打断时，粗暴相对的回应方式通常是因为你看待流态区的态度导致的。作者提供了一些方法解决这些问题：一是结对编程，当你被打扰时，你结对的搭档能够帮你回忆被打断前的思维；二是采用TDD（测试驱动开发），失败的测试能帮你维护住编码进度的上下文，当处理完中断重新回去时，你很清楚下一步任务就是解决这个失败的测试。
中断无法避免，总有干扰打断你、消耗你的时间。发生这种情况要注意一点，也许下次也会轮到你去打断别人请求帮助。因此，礼貌地表现出乐于助人的态度才是专业的态度。
写不出代码
有的时候，就是死活写不出代码，这时候你通常会去找一些事情干，比如去查看邮件、喝喝水、翻翻书、上上微博、检查进度或看点文档。作者提供的解决方案还是结对编程，当和别人一起工作时，会发生一种生理上的变化，能够帮助人冲破阻塞继续前进。
进度延迟
管理延迟的诀窍是早期检测和保持透明。最糟糕的情况是，你一直都在告诉每个人你会按时完成工作，到最后期限来临前你还在这样说，但最终你只能让他们大失所望。不要这么做。相反，要根据目标定期衡量进度,使用三个考虑到多种因素的期限：乐观预估、标称预估、悲观预估。尽量严守这三个时间点。不要把预估和期望混淆在一起!把全部这三个数字呈现给团队和利益相关者,并每天修正这些数字。
不合理的期望
如果你呈现的这些数字可能会错过最终期限，那又该怎么办呢？举个例子，假设10天后有一个展会，我们需要在展会上展示产品。但是，你对正在开发的特性的时间预估是8/12/20。不要对在10天内全部完成特性开发抱有期望！这种期望会杀死整个项目。期望会毁掉项目进度表，玷污你的名声，期望会把你拖进大麻烦中。如果展会是10天后召开，而你的常规预估已经是12天，你是绝不可能完成任务的。要让团队和利益相关者明白这个形势，除非另有后备预案，否则不要轻易松口退步。不要让其他任何人对此抱有期望。
加班加点
加班确实有用，而且有时候也很有必要，但这么做风险也很高。在额外加班20%的工作时间内，其实你并无法完成20%的额外工作。而且如果连续两三周都要加班，则加班的措施是失败的。因此不应该采用额外加班加点的方案，除非：1、你个人能挤出这些时间；2、短期的加班，最多两周；3、你的老板有后备预案，万一加班措施失败了。
帮助他人、接受别人的帮助
编程并非易事。越年轻的程序员对此可能越没有什么感觉。毕竞代码只不过是一堆if和whie语句而已。但是随着经验渐长，你会开始意识到把这些if和 while语句组装在一起的方式十分重要。不能期望将它们简单混在一起就能得到最好的代码。相反，必须小心谨慎地将系统分解为易于理解的小单元，同时使这些单元之间的关系越少越好，这并非易事。
编程很难，仅凭一已之力无法写出优秀的代码。既使你的技能格外高超，也肯定能从另外一名程序员的思考与想法中获益。
会议
专业的开发人员清楚会议高昂的成本，他们清楚自己的时间是宝贵的，他们同样需要时间来写代码，来处理日程表上的事务。
拒绝没有显著成效的会议
邀请你参加会议的人并不负责管理你的时间，为你的时间负责的是你自己。所以收到一些会议邀请，务必确保出席会议可以给自己目前的工作带来切实且显著的成效，否则不必参与。有些会议可能你很感兴趣，但当下没有参加的必要，这时候你自己得判断你是否花得起这个时间。有些会议，是你的领导或者主管命令你必须参加，这时候你就得问问自己，他们的职权是否比自己的工作计划重要。
离席没按计划进行的会议
会议不总按计划进行的。有时候你发现如果你对此会议知道得多一点，可能就不会来了；有时候会议临时增加了议题，或者某个讨厌的家伙霸占了讨论。作者给出处理这些问题的原则：如果会议让人厌烦，就离席。如果你发现参加的某个会议是在浪费时间，就应当想个礼貌的办法退出来。
确定议程与目标
我们之所以愿意承担开会的高昂成本，是因为有时候确实需要所有参与者坐在一起来实现某个目标。为了合理使用与会者的时间，会议应当有清晰的议程，确定每个议程所花费的时间已经明确的目标。
书中讲了许多专业的开发人员应该有的态度、原则、行动，旨在提高程序员的专业素养、情商。书中还有好多好多内容这里叙述不完，以后有机会继续分享。# 欢迎使用Markdown编辑器