软件设计不仅是“技术”（Technique），更是一门“技艺”（Craftsmanship），要想控制复杂度，防止系统腐化。我们不能只满足做一个搬砖的“码农”，而是要坚持自己的技术梦想和技术信仰，怀有一颗“匠人”之心，保持专注、持续学习，每天进步一点点。唯有如此，我们才有可能“从码农走向工匠”！ 程序员必备的两本提升自我修养的两本书： 重构：改善既有代码的设计（第2版） 本书的读者是专业的程序员，也就是那些以写软件为生的人。本书的范例和讨论，涉及大量需要阅读和理解的代码。这些都是用JavaScript写成的例子，不过这些都是详细应该适用于大部分知识。为了了解一些书籍的内容，读者需要有一些编程经验，但需要的知识并不多。 本书的目的目标读者群是大量想要学习的软件开发者，同时也已经理解了的人也——本书可以作为一本教学辅助书。在本书中，我用篇幅巨幅详细解释其他因此而产生的过程和原理，有经验的开发人员可以用本书来指导同事。 虽然本书的关注是代码，但对于系统设计有重大影响。资深设计师和架构师也很有必要了解也很重要，并在自己的项目中应用技术。威望的、经验丰富的开发人员来引入引入技术，因为这样的人最能够透彻理解背后的原理，并根据情况引发调整，使之适用于特定工作领域。其他编程语言，这一点特别重要，因为你必须把我给出的范例用其他编程语言改写。 下面我要告诉你，如何才能在不通读全书的情况下充分利用好它。 给形形色的某个原型是写书的重要部分。有合适的词汇能帮助我们互相交流。当一名开发者向另一名开发者提出建议，将一段代码提取出来一个函数，计算或者将逻辑拆分成几个阶段，双方可以理解提炼函数（106）和拆分阶段（154）是什么英文。 作为程序员的你如果读一读《重构》中的经典语句，你会发现这本书太值得阅读了。小编摘选如下几句：
书中有什么这本书是一本为专业的写文章的指南。我的目的是告诉你如何以一种能够控制且高效的方式进行程序。你将学会如何有条不漏地改进结构，并且不会出现错误，这就是正确的方式。 按照惯例，应该以概念介绍开头。虽然我也同意这个，但我发现了以图书性的讨论或定义来介绍的故事，生物不是容易的事。因此，我决定一个实例作为开路先锋。。章节展示了一个小程序，其中一些经常出现的设计缺陷，我把它看得更容易理解和修改。你想知道无法想到底是怎么回事，这章不读了。 第2章讨论的一般性原则、定义，以及进行具体的原因，我也代码描述了故事的故事。第3章的介绍由肯特贝克嗅出中的“坏角色一些”，以及如何如何乔装清除这些“坏名家”。测试在中扮演非常重要的角色，第4章介绍如何在中构筑测试。 从第5章的后的核心部分——篇幅名录。不能说是一个巨细的遗物的列表，却能深入挖掘大多数人可能的关键。重名录的290年源头是我开始学习世纪笔记时的笔记，直到今天我还没有时刻记这些，因为对我不什可靠的记忆的补充。例如树叶我不点什么——分手阶段（154 年） ——的时候，这张照片会提醒我一步一步的安全前进。我希望这是你日后再次回顾的部分。 代码整洁之道 你的代码在哪道门后面？你的团队或公司在哪道门后面？为什么会在那里？只是一次普通的代码复查，还是产品面世后才发现一连串严重问题？我们是否在战战兢兢地调试自己之前错以为没问题的代码？客户是否在流失？经理们是否把我们盯得如芒刺在背？当事态变得严重起来，如何保证我们在那道正确的门后做补救工作？答案是：技艺（craftsmanship）。 习艺之要有二：知和行。你应当习得有关原则、模式和实践的知识，穷尽应知之事，并且要对其了如指掌，通过刻苦实践掌握它。 学写整洁代码很难。它可不止于要求你掌握原则和模式。你得在这上面花工夫。你须自行实践，且体验自己的失败。你须观察他人的实践与失败。你须看看别人是怎样蹒跚学步，再转头研究他们的路数。你须看看别人是如何绞尽脑汁做出决策，又是如何为错误决策付出代价。 阅读本书要多用心思。这可不是那种降落前就能读完的“感觉不错”的飞机书。本书要让你用功，而且是非常用功。如何用功？阅读代码——大量代码。而且你要去琢磨某段代码好在什么地方、坏在什么地方。在我们分解，而后组合模块时，你得亦步亦趋地跟上。这得花些工夫，不过值得一试。 本书大致可分为3个部分。前几章介绍编写整洁代码的原则、模式和实践。这部分有相当多的示例代码，读起来颇具挑战性。读完这几章，就为阅读第2部分做好了准备。如果你就此止步，只能祝你好运啦！ 第2部分最需要花工夫。这部分包括几个复杂性不断增加的案例研究。每个案例都清理一些代码——把有问题的代码转化为问题少一些的代码。这部分极为详细。你的思维要在讲解和代码段之间跳来跳去。你得分析和理解那些代码，琢磨每次修改的来龙去脉。 你付出的劳动将在第3部分得到回报。这部分只有一章，列出从上述案例研究中得到的启示和灵感。在遍览和清理案例中的代码时，我们把每个操作理由记录为一种启示或灵感。我们尝试去理解自己对阅读和修改代码的反应，尽力了解为什么会有这样的感受、为什么会如此行事。结果得到了一套描述在编写、阅读、清理代码时思维方式的知识库。 如果你在阅读第2部分的案例研究时没有好好用功，那么这套知识库对你来说可能所值无几。在这些案例研究中，每次修改都仔细注明了相关启示的标号。这些标号用方括号标出，如：[H22]。由此你可以看到这些启示在何种环境下被应用和编写。启示本身不值钱，启示与案例研究中清理代码的具体决策之间的关系才有价值。 如果你跳过案例研究部分，只阅读了第1部分和第3部分，那就不过是又看了一本关于写出好软件的“感觉不错”的书。但如果你肯花时间琢磨那些案例，亦步亦趋——站在作者的角度，迫使自己以作者的思维路径考虑问题，就能更深刻地理解这些原则、模式、实践和启示。这样的话，就像一个熟练地掌握了骑车的技术后，自行车就如同其身体的延伸部分那样；对你来说，本书所介绍的整洁代码的原则、模式、实践和启示就成为了本身具有的技艺，而不再是“感觉不错”的知识。 有人也许会以为，关于代码的书有点儿落后于时代——代码不再是问题；我们应当关注模型和需求。确实，有人说过我们正在临近代码的终结点。很快，代码就会自动产生出来，不需要再人工编写。程序员完全没用了，因为商务人士可以从规约直接生成程序。 扯淡！我们永远抛不掉代码，因为代码呈现了需求的细节。在某些层面上，这些细节无法被忽略或抽象，必须明确之。将需求明确到机器可以执行的细节程度，就是编程要做的事。而这种规约正是代码。 我期望语言的抽象程度继续提升。我也期望领域特定语言的数量继续增加。那会是好事一桩。但那终结不了代码。实际上，在较高层次上用领域特定语言撰写的规约也将是代码！它也得严谨、精确、规范和详细，好让机器理解和执行。 那帮以为代码终将消失的伙计，就像是巴望着发现一种无规范数学的数学家们一般。他们巴望着，总有一天能创造出某种机器，我们只要想想、嘴都不用张就能叫它依计行事。那机器要能透彻理解我们，只有这样，它才能把含糊不清的需求翻译为可完美执行的程序，精确满足需求。 这种事永远不会发生。即便是人类，倾其全部的直觉和创造力，也造不出满足客户模糊感觉的成功系统来。如果说需求规约原则教给了我们什么，那就是归置良好的需求就像代码一样正式，也能作为代码的可执行测试来使用。 记住，代码确然是我们最终用来表达需求的那种语言。我们可以创造各种与需求接近的语言。我们可以创造帮助把需求解析和汇整为正式结构的各种工具。然而，我们永远无法抛弃必要的精确性——所以代码永存。 只要你干过两三年编程，就有可能曾被某人的糟糕的代码绊倒过。如果你编程不止两三年，也有可能被这种代码拖过后腿。进度延缓的程度会很严重。有些团队在项目初期进展迅速，但有那么一两年的时间却慢如蜗行。对代码的每次修改都影响到其他两三处代码。修改无小事。每次添加或修改代码，都得对那堆扭纹柴了然于心，这样才能往上扔更多的扭纹柴。这团乱麻越来越大，再也无法理清，最后束手无策。 程序员面临着一种基础价值谜题。有那么几年经验的开发者都知道，之前的混乱拖了自己的后腿。但开发者们背负期限的压力，只好制造混乱。简言之，他们没花时间让自己做得更快！ 艺术书并不保证你读过之后能成为艺术家，只能告诉你其他艺术家用过的工具、技术和思维过程。本书同样也不担保让你成为好程序员。它不担保能给你“代码感”。它所能做的，只是展示好程序员的思维过程，还有他们使用的技巧、技术和工具。 和艺术书一样，本书也充满了细节。代码会很多。你会看到好代码，也会看到糟糕的代码。你会看到糟糕的代码如何转化为好代码。你会看到启发、规条和技巧的列表。你会看到一个又一个例子。但最终结果取决于你自己。 还记得那个关于小提琴家在去表演的路上迷路的老笑话吗？他在街角拦住一位长者，问他怎么才能去卡耐基音乐厅（Carnegie Hall）。长者看了看小提琴家，又看了看他手中的琴，说道：“你还得练，孩子，还得练！” |
|
|
来自： 山峰云绕 > 《程序设计软件工程开源Github》
