文/Sherlock
程序员是什么？
问了身边同事，不同人不同答案。
一个做运维的小伙子说：程序就是一段上千行的解决问题的代码，有时候为了维护它，痛苦地想打人。编写这段代码的程序员脑袋里装的都是些啥？
一个发际线已开始后移的做架构设计的同事回答说：程序员就是为了实现文档上指定功能，而搬运代码的高级搬砖工。
整个月不说一句话的做后台算法的同事说：程序员，就是写一堆机器语言，让机器通过认识你的输入完成你想要的输出的高级人机译者。
我们姑且不论他们的回答是否正确，因为每个人对程序员有着不同的看法与见解。
最近看了《程序员修炼之道：通项务实的最高境界》这本书，书中的许多观点可以为程序员，提供更加冷静的视角去重新审视程序员角色，并为程序员的工作提供一些思路与方法。
它告诉我们如何成为务实的程序员，更好地编写软件，探究编程的本质。这本书于年再版，与其说是第二版不如说是上一版的进化。书中覆盖了哲学、方法、工具、设计、解耦、并发、重构、需求、团队等内容。无论是初学者还是高级架构师都能从作者思想的洞见中获益。
作者AndrewHunt，是一位软件开发类作家，同时也是一位冷科幻作家。这本书是他与DavidThomas合著的具有开创性的书籍。除此以外，他还著有《程序员修炼之道》、《程序员思维修炼》、获奖作品《高效程序员的45个习惯：敏捷开发修炼之道》等书籍，还发表过许多文章。
AndrewHunt我从事软件开发工作八年有余，从一开始的helloWorld!入门，到现在的算法设计、架构设计、方案设计，虽没有大牛们服务亿万级用户的经验，但是也编写运行了5年的代码，大大小小的项目也经历过十多个，一路走来小有收获。
直到看了这本书后，才意识到自己很多时候违背了一些原则、犯了完美主义的错误。比如，还没有等到完善功能就重构代码、各个模块耦合度极高，致使出现了牵一发而动全身的情况等等。
一开始很难发现这些错误，直到经历了足够多的项目。这或许就是成长的代价吧。如果能早点遇到这本书，就可以一定程度上避免工作中一些不必要的坑，成为更务实、更高效的程序员。
正如书中所讲：如果遵循我们的方法，你将快速获得经验、提高生产力，并且更好地理解整个开发过程。最终，你会写出更好的软件。
01.务实的哲学
务实的编程源于务实的思考哲学。
务实的程序员在面临问题时有着怎样的态度、风格及理念呢？从大局着想，越过表面问题，以更宽的视角综合考虑并结合实际，做出明智的妥协和合理的决策。
比如书中提出够好即可的理念，给了我很大的启发，这也是程序员常犯的错误。
为了追求更好，我们损毁了原已够好的。—莎士比亚《李尔王》
我几年前参与一个十分重要的十三五升级改造项目，自己承担后台计算部分，与其他同事合作完成一个较为大型的项目，有的同事负责UI，有的同事负责硬件的信号处理，有的同事负责日志处理，有的同事负责数据库部分。
我在项目的开发中，遇到了这本书上讲到的几乎所有的问题。一开始我们总想把软件做的无懈可击，总想以高屋建瓴的姿态去完成该项目，于是在项目过程中一遍又一遍的修改着自己的设计方式。在整个项目开发中，自己查阅了多篇中外文文献，看到一篇别人做了很好结果的方法总想移植到该项目中。结果导致在项目节点的交付中，虽然完成了所列的功能，但并没有彻底地解决问题，更多的是以一种掩盖问题的方式交付了第一版。
作者指出，“够好即可”这个词并不意味着草率或糟糕的代码。所有系统必须达到基本的性能、隐私和安全标准。你做的东西，从用户需求角度来说是否够好？最好还是留给用户来参与评判。
正如本书所讲的，现实世界不会让我们生产出完美的产品，完全无bug的软件。
整个过程我们缺少让用户（甲方）参与的机会，很多时候细化的需求都是我们小组自己头脑风暴出来的。其实，我们应该倾听用户的需求，因为他们比我们更加理解作为用户的需求是什么。
完成软件项目的过程，更应该像是完成一副绘画作品。从一开始明确整个作品的基调，绘制作品的框架，而不是一开始就去扣作品的细节，比如用什么设计模式，什么算法去实现某些功能。一开始应该明确整个项目的架构，整个项目所用的交互方式，所用数据库等基本问题。
艺术家会告诉你，如果不知道什么时候该停止，那么所有的努力就都白费了。如果你不断地在画布上层层叠加，用细节盖细节，最终的作品就会迷失在各种颜料中。
02.务实的运筹
没有作家，故事不会被写出来；没有演员，故事无法获得生命。—Angie-MarieDelsante
作者用并发来描述可以并行处理的问题与技术，似乎是讲给小白们听的，老鸟们对并发、并行、多线程、多进程应该再熟悉不过了。对于复杂的程序软件来说，若存在大量可并行的程序模块，起先还是应该采用活动图来确定。一个朋友说，世界上最复杂的软件除了操作系统就是浏览器了，这也就是为什么至今国内还没有一个完全意义上自主的操作系统或浏览器内核。
浏览器说简单点，就是字符串形式的html的格式解析。假如你写出了这样的内核，而且通过你的界面已经渲染出来了。你还会遇到性能问题，为什么别人的浏览器如此流畅，而你的浏览器可能连一个google搜索栏显示都卡得要命。这也就是并发的重要性，它涉及到太多可并发的模块与模块间的纵向与耦合编程。
我正在使用firfox进程的情况图中，倒数第二列为线程数，一共有7个进程，几乎是一个网页一个进程。
这也是我们经常遇见的问题，当你编写一个软件后，你以为似乎完成了所有的功能。可是系统一旦有异常值或边界值的输入，你的软件就crash了。接着你查资料，换了一种方法解决了这个问题。然而在进行其他测试时，程序又crash了，你就会在不断的crash之中崩溃掉。
此时，我们应该停下来想一想，这种打补丁的方式是否存在问题，可否跳出来，用图的方式让我们更加明晰问题的关键节点所在，或者是否可以通过优化程序处理的线程方式与并发来提高工作效率……
BjarneStroustrupC++之父笔者在开发过程中也遇到了作者所讲的问题，比如共享数据队列怎么处理、共享资源怎么做、信号量、资源锁、原子性等问题。这些问题都是实实在在的。
我的想法是，遇到类似问题的开发人员，可以自己编写出适合于自己的通用模块。能自己封装出适合自己的信号量、共享队列、资源锁，那就再好不过了。
因为几乎所有并发资源共享问题，都可以使用自己编写的模块来解决。为什么使用自己编写的模块，而不是使用现有的模块呢？一是你可以提升自己对于底层实现的理解；二是一旦对共享资源队列有什么特别的需求，你就可以修改，甚至可以提升效能。一开始可能比较痛苦，但是你会发现你付出的努力是值得的。
03.务实的依靠
在L组里，斯托弗管理着六个一流的程序员，这在管理上的挑战与养猫差不多。——《华盛顿邮报》杂志年6月9日刊
在软件开发团队中，合作精神的重要性不言而喻，团队可以只有几个人，也可以有成千上万人，持续时间也可以是一年或者几十年不等，比如Linux内核团队。在大多数开发任务中，根据不同的功能点，把团队划分为若干个小的团队，人员也比较稳定，充其量也就是10-12人左右。团队之间相互信任，相互依赖。
团队交流协作团队是一个整体，团队成员之间的磨合极为重要。能保持合作的默契和沟通的顺畅再好不过了，实在不行还可以通过条约来约束。
团队是一个整体，遇到小问题要积极地修补处理。团队必须对产品的质量负责，质量的保障有赖于团队每个成员的自发的贡献而不是来源于质量管理人员的监督。
团队的交流，包括对内交流与对外交流。大多时候程序员，喜欢埋头根据需求文档在自嗨的高潮中写代码，就像自我陶醉于一个人的摇滚。
然而交流是整个开发中的重中之重，自我陶醉于技术，容易忽略客户的需求，忘记了客户至上的理念。软件开发并不是炫技。客户的需求才应该是我们所追求的，不要认为客户什么都不懂，而是要耐心的听他们讲完，与他们多多沟通，与客户协调。因为只有沟通协调才能让我们技术得以落地。
团队内部的交流与沟通，是落实需求的重要手段。我们不能认为小白就比老鸟菜差，软件开发涉及方方面面，我们也不可能对所有领域都了如指掌。应该养成不断学习的习惯，秉持谦虚谨慎的态度。
团队本就应该是一个整体，若有什么想法，要及时沟通协调。劲往一处使，早日做出满意的产品。把问题留在团队内部消化解决，以最好的状态去完成软件开发，鼓励每个成员积极监控环境变化。保持清醒，对任何有风险的东西，都要留心。积极度量新需求，不要抗拒变化。
结语
读了这本书，我感到它将会给我的职业生涯以有力的指导。
它不仅仅提示了软件开发中需注意的地方和要规避的风险点。其务实的思维方式有着更广阔的适用边界，其他职业的人也可以迁移借鉴。
尽管我已经经历过若干项目，但依然认为这本书上罗列的99个提示，需要多加注意。我期望通过对这本书的研读，好好地总结自己这些年的得失，更好地面向未来，以更加积极的心态与状态去工作。
-end-