软件设计领域没有银弹，但代码大师MaxKanat-Alexander的建议绝对能给你带来启发...

hzbooks

于 2021-08-02 08:11:18 发布

阅读量479

点赞数

文章标签：编程语言人工智能软件开发敏捷开发 xhtml

本文链接：https://blog.csdn.net/hzbooks/article/details/119338321

版权

导读：

如何让简约设计始终贯穿在编程工作中，以及如何在编程工作中取得成功？

复杂的软件设计有哪些特征——如何构建杰出软件？

程序员为何会感到力不从心，应该如何持续改善？

成为明星程序员的秘密是什么？

程序员应该知晓的编程原则有哪些？

马克斯·卡纳特-亚历山大是谷歌的代码健康技术主管，他的工作包括担任Xbox上YouTube的技术主管，在谷歌从事Java JDK、JVM和Java其他方面的工作，以及担任YouTube的工程实践技术主管，他在YouTube上为所有的开发人员提供最佳实践和工程开发效率方面的支持。

《编程原则：来自代码大师Max Kanat-Alexander的建议》一书中，富有传奇色彩的编程大师马克斯·卡纳特-亚历山大（Max Kanat-Alexander）将会向你展示如何让简约设计的思想回归到计算机编程中。马克斯会解释程序员为何会感到力不从心，以及应该如何持续改善。世界上存在太多复杂的事物。复杂并不可取，因为它会给我们的工作带来隐患。

本书涵盖的是所有你在开发中可能会运用到的各式各样的原则。在本书的前言和第1章中，作者就开宗明义地指出，本书的目的是帮助你成为一名更好的开发者。通过书中作者在过往工作中总结下来的这些经验，希望能够让你在成长的路上少走弯路。

>>>>

多谈些主义

关于如何对待编程领域中这些和编程间接、直接相关的知识，我见过两种极端的态度：有的人只看结果，只关心“写代码”，而对“写好代码”一无所知；第二类人深谙各种架构设计、整洁代码之道，但对于当下代码中遭遇的问题却没有落地的方案。

在互联网公司的多年工作经验让我个人更习惯于从第一种人的视角看待问题，毕竟这是行业性质决定的，跑马圈地、快速扩张才重要，行业不允许你有时间思考。但是抛开行业、抛开公司，单纯地看编码这件事，我作为程序员最大的疑惑是：为什么我在每一家公司接手的代码库都如此难以维护？为什么总有人写出500行代码的函数和1000行代码的组件？为什么每一个迭代的最后总是要加班加点，研发、测试、产品经理都叫苦不迭？为什么问题年复一年地发生，却没有人想做些什么来改变现状？

DRY—Don’t Repeat Yourself。别忘了这可是我们自己说的。

我观察到程序员存在一种战略上的惰性，对学习新技术和新框架，对阅读源码有发自内心的推崇。我不否定这种行为，新技术能给我们的项目带来便利，能给我们的简历增添浓墨重彩的一笔，这无可厚非。但技术背后的编写思路演化至今的原因，同样值得了解，它们和技术的语法本身同样重要。仔细回想和思考就不难发现，工具的好坏和代码的好坏，与项目将来适应需求变化的灵活能力没有关系，从写Vanilla JavaScript的年代，到BackboneJS，再到React，你看到团队中能把代码写好的人真的是越来越多吗？

不同行业对于软件质量的要求是不同的。且不说你所在的行业有没有意愿和资源解决这些问题，如果有，你应该去哪里寻找方案？

在我看来，前人留下的经验是最值得我们借鉴的宝贵财富，无论这种经验是来自传统软件行业还是其他互联网公司。我们遇到的问题，尤其是对传统软件行业而言，他们在十年前甚至二十年前就已经遇到了，所思所想比我们更深远。然而这些经验也并不神秘，其中有一部分经典就是你已经耳濡目染的各类编程法则和开发模式，而另一类更实际的内容就散落在不同渠道的文字和口述当中，例如本书中。

但让人望而却步的是，大部分原则听起来都过于抽象了，甚至有些是反直觉的。

我明白抽象带给人的挫败感，你肯定听说过不少，甚至它们的名字都可以信手拈来，例如可维护性、可扩展性、可读性、KISS、YANGNI等。但什么样的代码才称得上可读性好，KISS应该如何在代码中实施？

反直觉的实践也比比皆是。如果我告诉你，在每一次正式开发代码前，提前对代码做一些重构工作，那么无论是短期还是长期来看，你整体付出的开发时间是下降而不是上升的，你愿意相信吗？相信之后又敢在工作中尝试吗？

遗憾的是有一些原则背后确实存在复杂的知识体系作为支撑，哪怕我用思维导图把背后涉猎的概念一五一十地列举出来，你的内心可能依然毫无波澜。因为其中的很多原则需要你看到相似的代码后才能心领神会，轮扁斫轮的寓意也是在此。但还有一些并不是，比如在判断一个函数长度是否恰当时，我们有一些实打实的评判标准，其中一条是函数是否能在一个屏幕之内显示完毕。

Uncle Bob Martin在他的“The Principles of OOD”系列文章中谈到过糟糕设计（Bad Design）的几个特征：

僵化（Rigidity）：代码难以修改，因为改动会影响到的地方太多。
脆弱（Fragility）：当你做出修改时，系统中预期之外的地方会遭到破坏。
难以修改（Immobility）：代码很难被复用，因为它与当前系统中的功能耦合在了一起。

这一系列简单扼要的描述，就将编程中涉及的原则和代码中具体的症状联系到了一起。

学习这些知识难吗？一点也不难。想要了解它们很简单，但想要在编程中灵活运用它们则是另外一回事，毕竟提升编程技能靠的不是死记硬背，而是反复刻意的练习。但再困难，也会比将来回过头设法挽回代码造成的损失要简单。

>>>>

如果他们错了怎么办

我无法否认这种可能性。但也请允许我问另一个问题：当需要在一个团队内对某个技术方案进行决策时，决策应该是专制的还是民主的？

不如我再把这个例子具象化一些，假设在一个新建的项目中，我们需要制定webpack关于chunk打包的策略，那么很多与chunk有关的配置，比如hash、cacheGroups，应该如何配置？

解决这个问题的过程不太可能是民主的。首先人们需要对webpack涉及哪些chunk配置，以及每一个配置的可选项背后对应解决的问题场景有所了解；其次还要对项目的现状、站点内静态资源加载的需求有清晰的认识。

这些决策的前提知识，并不是每个人都具备的。

大部分时候—我说的是大部分时候，技术的决策是专制的。如果我在这个技术领域有丰富的经验，如果我解决过足够多的问题，哪怕是我在这个项目中待的足够久，那么对于当下任何一个新的问题，我就能想得更多，看得更远。当然如果团队的时间和人员充足，可以抱着培养新人的心态，放手把问题交给一个从没有接触过这方面领域的人来解决。

很多时候这些原则不一定是错的，而是让你听上去以为它是错的。就拿注释这件事来说，大部分程序员会认为注释是消除代码“恶臭”的灵丹妙药，但是：

Martin Fowler在《重构》里告诉你没事别写注释。
Uncle Bob Martin在《代码整洁之道》里告诉你没事别写注释。
Jeff Atwood在codinghorror技术博客里告诉你没事别写注释。

那你还有什么理由要继续写注释？

现在依然半信半疑的你该何去何从？

你可以去了解这些建议背后的动机。在这些建议的背后他们都给出了各自的理由，以及替代的解决方案是什么。“start with why”有助于理解，神奇地让你从对立面转向认同他们的观点。

但有一些知识可能找不到出处，或者只是团队中留下的实践，这种实践还是以代码的形式给出的。在这种情况下，你或许需要的是“信仰之跃”（Take a leap of faith）。也就是说此时你需要无条件地相信，日后再慢慢验证，慢慢理解。

还有一种选择，那就是置若罔闻，但可能需要承担惨痛的、后患无穷的代价。

如果你依然对书中的原则将信将疑的话，不得不提我翻译这本书的另一个原因：书中很多内容与我在实际工作中总结出的经验不谋而合。

我个人在从独立开发者的视角转向关注团队、关注项目、关注流程的视角的过程中，发现技术问题已不再是我眼中需要解决的首要难题。

因为哪怕你找到了整治项目的灵丹妙药（某种最佳实践），也需要整个团队的力量来帮助你落地且一如既往地保持下去。项目里不需要英雄，即使团队中真的存在能写一手好代码的高手，他的辛苦结晶也很快就会被庸才们“孜孜不倦”的“劳动成果”所打败。

迫切地希望团队中有“救世主”角色出现是一个危险的信号，而且通常这个时候救世主也派不上什么用场。另外，即便有灵丹妙药，你有没有考虑过团队里的每个成员能否“咽得下”这颗灵丹妙药？基于同样的原因，仅仅只有几个人能够理解这套方案并且在项目里实施起来是不够的。所以灵丹妙药要怎么选？底线在哪？说白了，底线就是团队能力的下线。

如何提升团队效能？如何帮助团队中的成员成长为明星程序员？这些都是在本书中会谈及的问题。

>>>>

多研究些问题

还记得我在开头提及的第二种人吗？他们同样是危险的。如果抛开实现，单纯地把问题抽象到某种高度，可能会让问题陷入一种什么都解决得了或什么都解决不了的极端局面中。前者相当于“不就是”，后者等同于“又怎样”。万事万物都可以套用“不就是”与“又怎样”的句式，这样的描述看似是无敌的，但仔细想想又破绽百出。

“不就是微前端嘛”—不好意思你说的是哪一种微前端？不同框架下组件间的通信问题是如何解决的？构建时集成流水线的粒度如何？组件间互相依赖的版本管理策略如何？

“又怎样”的心态更是可恶，当代码稍有改善时，就会有悲观主义者“友善”地“提醒”你：这种杯水车薪的改善又能怎样呢？现在整个代码库依然身陷囹圄。

这种思考问题的方式一点都说不通，代码腐化是一个持续的过程，但为什么我们却想在某个时间段内一劳永逸地把问题解决？

实话实说大部分代码库都是满目疮痍的，问题在于你要如何挽救它，从哪里开始挽救它。无论我们是引入committer机制还是代码评审会议，总有一天会无法坚持下去，最坏的情况无非是我们没有让它变得更好，但也保证了在尝试的过程中它不会变得更差。

前面所说的开发人员的能力困境“不就是”温伯格的咨询第二定律：不管一开始看起来什么样，它永远是人的问题。

它够不够抽象？够。够不够深刻？够。够不够有哲理？够。但说实话对于解决我们当下的问题并没有太大的帮助。如果瓶颈真的在团队的成员上，我们想知道的是：怎样才能提升团队成员的编程能力？再实际一些，作为一家创业公司，我无法提供非常有竞争力的薪水来招到顶级的人才，或者迫于交付压力我无法花太多的时间在培训、代码审查、重构上，那么我的代码应该如何被拯救？

在我看来本书的魅力正是摆脱了高高在上的姿态，在“说白话”，作者并非只是凭空扔给你一句话（每一句话高深到每个词你都认识，但连起来就读不懂那种）之后让你慢慢参悟。对于一些概念，甚至是常见的概念，作者会进行澄清和定义。如果他提出的是一条建议，那么他还会解释这条建议的来龙去脉和它所适用的范围。对于在实施过程中可能遭遇的阻碍，他也做出了适当的预测并给出了解决办法。

我不敢苟同他在书中提出的每一个观点，最终是否适合你还需要你自行判断，毕竟在这个领域内没有银弹。但相信这些内容能够给你带来启发。

RECOMMEND