编程入门自学书籍推荐,编程的原则

编程入门自学书籍推荐,编程的原则

今天给大家介绍一本关于编程的书籍，它来自编程原则:来自代码大师Max Kanat-Alexander的建议。在还没开始翻译之前，我对于这篇译者序就已经有了规划:先聊聊我翻译这本书的原因，再大致把这本书里的内容叙述一遍，最后重点推荐一些我个人认为有价值的章节。但是在后续润色的过程中(其实也相当于重读了).我发现当初的设想是不可能实现的，因为整本书涉及面太广了一一代码调试、 策略测试、团队协作、效能提升、待人接物无所不谈。

推荐阅读：python教程

你肯定也疑惑了，那么本书究竟想介绍什么?难道没有一一个统一的主题吗?

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

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

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

我观察到程序员存在一种战略上的惰性，对学习新技术和新框:

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

不同行业对于软件质量的要求是不同的。且不说你所在的行业有没有意愿和资源解决这些问题，如果有，你应该去哪里寻找方案?
在我看来，前人留下的经验是最值得我们借鉴的宝贵财富，无论这种经验是来自传统软件行业还是其他互联网公司。我们遇到的问题，尤其是对传统软件行业而言，他们在十年前甚至二+ 年前就已经遇到了，所思所想比我们更深远。 然而这些经验也并不神秘，其中有一-部分经典就是你已经耳濡目染的各类编程法则和开发模式，而另一类更实际的内容就散落在不同渠道的文字和口述当中，例如本书中。但让人望而却步的是,大部分原则听起来都过于抽象了，甚至有些是反直觉的。我明白抽象带给人的挫败感，你肯定听说过不少，甚至它们的名字都可以信手拈来，例如可维护性、可扩展性、可读性、KISS、YANGNI等。但什么样的代码才称得上可读性好，KISS应该如何在代码中实施?

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

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

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

脆弱( Fragiliy):当你做出修改时，系统中预期之外的地方会遭到破坏。
o难以修改( Immobility):代码很难被复用，因为它与当前系统中的功能耦合在了一起。
这一系列简单扼要的描述，就将编程中涉及的原则和代码中具体的症状联系到了-起。
学习这些知识难吗?一点也不难。想要了解它们很简单，但想要在编程中灵活运用它们则是另外- -回事，毕竟提升编程技能靠的不是死记硬背，而是反复刻意的练习。但再困难，也会比将来回过头设法挽回代码造成的损失要简单。

如果他们错了怎么办？

我无法否认这种可能性。但也请允许我问另一一个问题:当需要在一个团队内对某个技术方案进行决策时，决策应该是专制的还是民主的?不如我再把这个例子具象化一些，假设在一个新建的项目中 ，我们需要制定webpack关于chunk打包的策略，那么很多与chunk有关的配置，比hashcacheGroups ，应该如何配置?

解决这个问题的过程不太可能是民主的。首先人们需要对webpack涉及哪些chunk配置，以及每一个配置的可选项背后对应解决的问题场景有所了解;其次还要对项目的现状、站点内静态资源加载的需求有清晰的认识。这些决策的前提知识,并不是每个人都具备的。大部分时候一一我说的是大部分时候 ，技术的决策是专制的。如果我在这个技术领域有丰富的经验，如果我解决过足够多的问题，哪怕是我在这个项目中待的足够久，那么对于当下任何一个新的问题，我就能想得多，看得更远。当然如果团队的时间和人员充足，可以抱着培养新人的心态，放手把问题交给一个从没有接触过这方面领域的人来解决。

很多时候这些原则不一定是错的，而是让你听上去以为它是错的。就拿注释这件事来说，大部分程序员会认为注释是消除代码”恶臭”的灵丹妙药，但是:Martin Fowler在《重构》里告诉你没事别写注释。Uncle Bob Martin在《代码整洁之道》里告诉你没事别写注释。Jeff Atwood在codinghorror技术博客里告诉你没事别写注释。

那你还有什么理由要继续写注释?现在依然半信半疑的你该何去何从?
你可以去了解这些建议背后的动机。在这些建议的背后他们都给出了各自的理由，以及替代的解决方案是什么。”start with why”有助于理解，神奇地让你从对立面转向认同他们的观点。

但有一些知识可能找不到出处，或者只是团队中留下的实践，这种实践还是以代码的形式给出的。在这种情况下，你或许需要的是“信仰之跃” ( Take a leap of faith)。也就是说此时你需要无条件地相信，日后再慢慢验证，慢慢理解。还有一种选择，那就是置若罔闻，但可能需要承担惨痛的、后患无穷的代价。
如果你依然对书中的原则将信将疑的话,不得不提我翻译这本书的另一个原因:书中很多内容与我在实际工作中总结出的经验不谋而合。我个人在从独立开发者的视角转向关注团队、关注项目、关注流程的视角的过程中，发现技术问题已不再是我眼中需要解决的首要难题。

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

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