您当前的位置:首页 > 电脑百科 > 程序开发 > 程序员

在亚马逊的新员工(程序员)都被推荐要读一读这本书

时间:2020-06-17 17:53:58  来源:  作者:

 

在亚马逊的新员工(程序员)都被推荐要读一读这本书

 

如果您想真正学习,最好的方法是阅读Robert C Martin的Clean Code。基本上,它普遍推荐给亚马逊的新员工。
中文版由人民邮电出版社异步社区出版,中文名:《代码整洁之道》,作者:Robert,C,Martin。

在亚马逊的新员工(程序员)都被推荐要读一读这本书

 

学写整洁代码很难。它可不止于要求你掌握原则和模式。你得在这上面花工夫。你须自行实践,且体验自己的失败。你须观察他人的实践与失败。你须看看别人是怎样蹒跚学步,再转头研究他们的路数。你须看看别人是如何绞尽脑汁做出决策,又是如何为错误决策付出代价。

阅读本书要多用心思。这可不是那种降落前就能读完的“感觉不错”的飞机书。本书要让你用功,而且是非常用功。如何用功?阅读代码——大量代码。而且你要去琢磨某段代码好在什么地方、坏在什么地方。在我们分解,而后组合模块时,你得亦步亦趋地跟上。这得花些工夫,不过值得一试。

本书大致可分为3个部分。前几章介绍编写整洁代码的原则、模式和实践。这部分有相当多的示例代码,读起来颇具挑战性。读完这几章,就为阅读第2部分做好了准备。如果你就此止步,只能祝你好运啦!

第2部分最需要花工夫。这部分包括几个复杂性不断增加的案例研究。每个案例都清理一些代码——把有问题的代码转化为问题少一些的代码。这部分极为详细。你的思维要在讲解和代码段之间跳来跳去。你得分析和理解那些代码,琢磨每次修改的来龙去脉。

你付出的劳动将在第3部分得到回报。这部分只有一章,列出从上述案例研究中得到的启示和灵感。在遍览和清理案例中的代码时,我们把每个操作理由记录为一种启示或灵感。我们尝试去理解自己对阅读和修改代码的反应,尽力了解为什么会有这样的感受、为什么会如此行事。结果得到了一套描述在编写、阅读、清理代码时思维方式的知识库。

如果你在阅读第2部分的案例研究时没有好好用功,那么这套知识库对你来说可能所值无几。在这些案例研究中,每次修改都仔细注明了相关启示的标号。这些标号用方括号标出,如:[H22]。由此你可以看到这些启示在何种环境下被应用和编写。启示本身不值钱,启示与案例研究中清理代码的具体决策之间的关系才有价值。

如果你跳过案例研究部分,只阅读了第1部分和第3部分,那就不过是又看了一本关于写出好软件的“感觉不错”的书。但如果你肯花时间琢磨那些案例,亦步亦趋——站在作者的角度,迫使自己以作者的思维路径考虑问题,就能更深刻地理解这些原则、模式、实践和启示。这样的话,就像一个熟练地掌握了骑车的技术后,自行车就如同其身体的延伸部分那样;对你来说,本书所介绍的整洁代码的原则、模式、实践和启示就成为了本身具有的技艺,而不再是“感觉不错”的知识。


干货分享:第12章 迭进

12.1 通过迭进设计达到整洁目的

假使有4条简单的规矩,跟着做就能帮助你创建优良的设计,会如何?假使遵循这些规矩你就能洞见代码的结构和设计,更轻易地应用SRP和DIP之类原则,又会如何?假使这4条规则有利于良好的设计“浮现”出来,又会如何?

我们中的许多人认为,Kent Beck关于简单设计[1]的四条规则,对于创建具有良好设计的软件有着莫大的帮助。

  • 据Kent所述,只要遵循以下规则,设计就能变得“简单”:
  • 运行所有测试;
  • 不可重复;
  • 表达了程序员的意图;
  • 尽可能减少类和方法的数量;
  • 以上规则按其重要程度排列。

12.2 简单设计规则1:运行所有测试

设计必须制造出如预期一般工作的系统,这是首要因素。系统也许有一套绝佳设计,但如果缺乏验证系统是否真按预期那样工作的简单方法,那就无异于纸上谈兵。

全面测试并持续通过所有测试的系统,就是可测试的系统。看似浅显,但却重要。不可测试的系统同样不可验证。不可验证的系统,绝不应部署。

幸运的是,只要系统可测试,就会导向保持类短小且目的单一的设计方案。遵循SRP的类,测试起来较为简单。测试编写得越多,就越能持续走向编写较易测试的代码。所以,确保系统完全可测试能帮助我们创建更好的设计。

紧耦合的代码难以编写测试。同样,编写测试越多,就越会遵循DIP之类规则,使用依赖注入、接口和抽象等工具尽可能减少耦合。如此一来,设计就有长足进步。

遵循有关编写测试并持续运行测试的简单、明确的规则,系统就会更贴近OO低耦合度、高内聚度的目标。编写测试引致更好的设计。

12.3 简单设计规则2~4:重构

有了测试,就能保持代码和类的整洁,方法就是递增式地重构代码。添加了几行代码后,就要暂停,琢磨一下变化了的设计。设计退步了吗?如果是,就要清理它,并且运行测试,保证没有破坏任何东西。测试消除了对清理代码就会破坏代码的恐惧

在重构过程中,可以应用有关优秀软件设计的一切知识。提升内聚性,降低耦合度,切分关注面,模块化系统性关注面,缩小函数和类的尺寸,选用更好的名称,如此等等。这也是应用简单设计后三条规则的地方:消除重复,保证表达力,尽可能减少类和方法的数量。

12.4 不可重复

重复是拥有良好设计系统的大敌。它代表着额外的工作、额外的风险和额外且不必要的复杂度。重复有多种表现。极其雷同的代码行当然是重复。类似的代码往往可以调整得更相似,这样就能更容易地进行重构。重复也有实现上的重复等其他一些形态。例如,在某个群集类中可能会有两个方法:

int size() {}
boolean isEmpty() {}

这两个方法可以分别实现。isEmpty方法跟踪一个布尔值,而size方法则跟踪一个计数器。或者,也可以通过在isEmpty中使用size方法来消除重复:

boolean isEmpty() {
 return 0 == size();
}

要想创建整洁的系统,需要有消除重复的意愿,即便对于短短几行也是如此。例如以下代码:

public void scaleToOneDimension(
  float desiredDimension, float imageDimension) {
 if (Math.abs(desiredDimension - imageDimension) < errorThreshold)
  return;
 float scalingFactor = desiredDimension / imageDimension;
 scalingFactor = (float)(Math.floor(scalingFactor * 100) * 0.01f);

 RenderedOp newImage = ImageUtilities.getScaledImage(
   image, scalingFactor, scalingFactor);
 image.dispose();
 System.gc();
 image = newImage;
}
public synchronized void rotate(int degrees) {
 RenderedOp newImage = ImageUtilities.getRotatedImage(
   image, degrees);
 image.dispose();
 System.gc();
 image = newImage;
}

要保持系统整洁,应该消除scaleToOneDimension和rotate方法里面的少量重复:

public void scaleToOneDimension(
  float desiredDimension, float imageDimension) {
 if (Math.abs(desiredDimension - imageDimension) < errorThreshold)
  return;
 float scalingFactor = desiredDimension / imageDimension;
 scalingFactor = (float)(Math.floor(scalingFactor * 100) * 0.01f);
 replaceImage(ImageUtilities.getScaledImage(
   image, scalingFactor, scalingFactor)); 
}

public synchronized void rotate(int degrees) {
 replaceImage(ImageUtilities.getRotatedImage(image, degrees)); 
}

private void replaceImage(RenderedOp newImage) {
 image.dispose();
 System.gc();
 image = newImage;
}

做了一点点共性抽取后,我们意识到已经违反了SRP原则。所以,可以把一个新方法分解到另外的类中,从而提升其可见性。团队中的其他成员也许会发现进一步抽象新方法的机会,并且在其他场景中复用之。“小规模复用”可大量降低系统复杂性。要想实现大规模复用,必须理解如何实现小规模复用。

模板方法模式[2]是一种移除高层级重复的通用技巧。例如:

public class VacationPolicy {
 public void accrueUSDivisionVacation() {
  // code to calculate vacation based on hours worked to date
  // ...
  // code to ensure vacation meets US minimums
  // ...
  // code to Apply vaction to payroll record
  // ...
 }
 public void accrueEUDivisionVacation() {
  // code to calculate vacation based on hours worked to date
  // ...
  // code to ensure vacation meets EU minimums
  // ...
  // code to apply vaction to payroll record
  // ...
 }
}

除了计算法定最少数量假期的部分,accrueUSDivisionVacation和accrueEuropeanDivision Vacation中有大量代码雷同。那部分的算法,依据员工类型而变。

可以通过应用模板方法模式来消除明显的重复。

abstract public class VacationPolicy {
 public void accrueVacation() {
  calculateBaseVacationHours(); 
  alterForLegalMinimums(); 
  applyToPayroll(); 
 }

 private void calculateBaseVacationHours() { /* ... */ };
 abstract protected void alterForLegalMinimums();
 private void applyToPayroll() { /* ... */ };
}

public class USVacationPolicy extends VacationPolicy {
 @Override protected void alterForLegalMinimums() {
  // US specific logic
 }
}

public class EUVacationPolicy extends VacationPolicy {
 @Override protected void alterForLegalMinimums() {
  // EU specific logic
 }
}

子类填充了accrueVacation算法中的“空洞”,提供不重复的信息。

12.5 表达力

我们中的大多数人都经历过费解代码的纠缠。我们中的许多人自己就编写过费解的代码。写出自己能理解的代码很容易,因为在写这些代码时,我们正深入于要解决的问题中。代码的其他维护者不会那么深入,也就不易理解代码。

软件项目的主要成本在于长期维护。为了在修改时尽量降低出现缺陷的可能性,很有必要理解系统是做什么的。当系统变得越来越复杂,开发者就需要越来越多的时间来理解它,而且也极有可能误解。所以,代码应当清晰地表达其作者的意图。作者把代码写得越清晰,其他人花在理解代码上的时间也就越少,从而减少缺陷,缩减维护成本。

可以通过选用好名称来表达。我们想要听到好类名和好函数名,而且在查看其权责时不会大吃一惊。

也可以通过保持函数和类尺寸短小来表达。短小的类和函数通常易于命名,易于编写,易于理解。

还可以通过采用标准命名法来表达。例如,设计模式很大程度上就关乎沟通和表达。通过在实现这些模式的类的名称中采用标准模式名,例如COMMAND或VISITOR,就能充分地向其他开发者描述你的设计。

编写良好的单元测试也具有表达性。测试的主要目的之一就是通过实例起到文档的作用。读到测试的人应该能很快理解某个类是做什么的。

不过,做到有表达力的最重要方式却是尝试。有太多时候,我们写出能工作的代码,就转移到下一个问题上,没有下足功夫调整代码,让后来者易于阅读。记住,下一位读代码的人最有可能是你自己。

所以,多少尊重一下你的手艺吧。花一点点时间在每个函数和类上。选用较好的名称,将大函数切分为小函数,时时照拂自己创建的东西。用心是最珍贵的资源。

12.6 尽可能少的类和方法

即便是消除重复、代码表达力和SRP等最基础的概念也会被过度使用。为了保持类和函数短小,我们可能会造出太多的细小类和方法。所以这条规则也主张函数和类的数量要少。

类和方法的数量太多,有时是由毫无意义的教条主义导致的。例如,某个编码标准就坚称应当为每个类创建接口。也有开发者认为,字段和行为必须切分到数据类和行为类中。应该抵制这类教条,采用更实用的手段。

我们的目标是在保持函数和类短小的同时,保持整个系统短小精悍。不过要记住,这在关于简单设计的四条规则里面是优先级最低的一条。所以,尽管使类和函数的数量尽量少是很重要的,但更重要的却是测试、消除重复和表达力。

12.7 小结

有没有能替代经验的一套简单实践手段呢?当然不会有。另一方面,本章中写到的实践来自于本书作者数十年经验的精练总结。遵循简单设计的实践手段,开发者不必经年学习就能掌握好的原则和模式。



Tags:程序员   点击:()  评论:()
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,如有任何标注错误或版权侵犯请与我们联系(Email:2595517585@qq.com),我们将及时更正、删除,谢谢。
▌相关推荐
据新华社消息,美国纽约市一个联邦陪审团13日裁定,中央情报局前软件工程师乔舒亚&middot;舒尔特向维基揭秘网站泄露该机构“最有价值”的黑客工具,犯有盗取及输送国防信息罪。陪...【详细内容】
2022-07-15  Tags: 程序员  点击:(1)  评论:(0)  加入收藏
有人说程序员单调乏味?看过他们的工位黑马君第一个不答应!在程序员的工位上,不仅显示屏多,玩具也特别多,特别是可爱的小黄鸭,(谁能给科普一下程序员为什么那么喜欢小黄鸭吗?△图来源...【详细内容】
2022-07-15  Tags: 程序员  点击:(3)  评论:(0)  加入收藏
在当代职场流传着这么一句话,90后:终于进大厂了!00后:我要去国企! 不知何时,对于在职的年轻人而言,国企和大厂成为了最优选择,一个高薪,一个压力小,而两者之间的对比也日益激烈,针对哪...【详细内容】
2022-07-07  Tags: 程序员  点击:(10)  评论:(0)  加入收藏
让我们面对现实吧,软件工程师的薪水相当高。根据你的薪水,你可以轻松过上非常舒适的生活。然而,一些程序员喜欢探索副收入的想法来补充他们的全职工资。也许你想提前退休?也许您...【详细内容】
2022-07-04  Tags: 程序员  点击:(6)  评论:(0)  加入收藏
一、基础概念1、Sorted(单调递增or单调递减)2、Bounded(存在上下界)3、Accessible by index(能够通过索引访问,数组适合,but链表不适合)二分查找是一种在每次比较之后将查找空间一...【详细内容】
2022-07-04  Tags: 程序员  点击:(14)  评论:(0)  加入收藏
2022年的互联网行业变化挺大,接单可以作为开发者朋友能力变现的一条备选路,今天说说应该怎么判断一个项目是否靠谱以及市面上最常用的一些接单平台。接单需知接触接单的开发...【详细内容】
2022-06-22  Tags: 程序员  点击:(37)  评论:(0)  加入收藏
一个普普通通的25+女程序员枯燥且忙(bai)碌(mang)的一天✅7:40 闹钟不响绝对不起床[偷笑R],穿衣、刷牙、洗脸(平时上班不化妆)✅8:00 出门(骑电驴+地铁+班车+5分钟步行)✅8:40...【详细内容】
2022-06-22  Tags: 程序员  点击:(18)  评论:(0)  加入收藏
自由职业者:程序员是当今最不受约束的自由职业者,可以帮助人们了解他们的网站和应用程序。 博客:程序员可以轻松地拥有一个专注于人们面临的技术问题和困难的博客。 主题和模...【详细内容】
2022-06-22  Tags: 程序员  点击:(33)  评论:(0)  加入收藏
人生在不同的阶段会有不同的生活方式和思考问题的角度,这是一件非常有趣的事~比如,我在 22 岁会想:怎么才能赚大钱,怎么才能升值加薪?在 25 岁会想:去哪买房?什么时候结婚?在 28 岁...【详细内容】
2022-06-19  Tags: 程序员  点击:(17)  评论:(0)  加入收藏
微服务架构的数据一致性微服务架构下,最好的分布式数据一致性解决方案就是尽量避免分布式事务,然而,在很多场景下,分布式事务是难以避免的。在金融、电信领域中,很多业务场景要求...【详细内容】
2022-06-16  Tags: 程序员  点击:(33)  评论:(0)  加入收藏
▌简易百科推荐
有人说程序员单调乏味?看过他们的工位黑马君第一个不答应!在程序员的工位上,不仅显示屏多,玩具也特别多,特别是可爱的小黄鸭,(谁能给科普一下程序员为什么那么喜欢小黄鸭吗?△图来源...【详细内容】
2022-07-15  黑马程序员    Tags:程序员   点击:(3)  评论:(0)  加入收藏
因试用期遭劝退,一男子为发泄情绪删光自己在职期间所写系统代码被判刑十个月,如何看待这一审判结果?通过删库来发泄情绪的程序员是最蠢的。聪明的程序员会写一堆只有自己看得...【详细内容】
2022-07-10  多才小胖墩    Tags:代码   点击:(8)  评论:(0)  加入收藏
在当代职场流传着这么一句话,90后:终于进大厂了!00后:我要去国企! 不知何时,对于在职的年轻人而言,国企和大厂成为了最优选择,一个高薪,一个压力小,而两者之间的对比也日益激烈,针对哪...【详细内容】
2022-07-07  学掌门    Tags:程序员   点击:(10)  评论:(0)  加入收藏
让我们面对现实吧,软件工程师的薪水相当高。根据你的薪水,你可以轻松过上非常舒适的生活。然而,一些程序员喜欢探索副收入的想法来补充他们的全职工资。也许你想提前退休?也许您...【详细内容】
2022-07-04  独一无二的小魏同学    Tags:程序员   点击:(6)  评论:(0)  加入收藏
转自:https://www.jdon.com/61280 本文分析了来自 5,508 个软件工程职位列表的数据,以帮助您找出哪些编程语言的薪水最高。 我们分析了RemoteOK(世界上最大的工作委员会)上 5k...【详细内容】
2022-06-30  9i分享客栈    Tags:编程语言   点击:(27)  评论:(0)  加入收藏
【CSDN 编者按】丛纹弨是智能交通和物流领域的连续创业者,二十年的产业技术和创业管理经验,让他成为行业资深专家。本文从智慧物流平台的真正价值为何、如何通过算法解决行业...【详细内容】
2022-06-29    CSDN  Tags:CEO   点击:(22)  评论:(0)  加入收藏
相信很多朋友都想开发一款属于自己的应用,不管是学习还是工作中用,但是对于如何学习并开发完成这过程还存在迷茫点,活到老学到老!我也通过学习别人总结的,再总结一条适合自己的学...【详细内容】
2022-06-23  希里安    Tags:web开发   点击:(25)  评论:(0)  加入收藏
2022年的互联网行业变化挺大,接单可以作为开发者朋友能力变现的一条备选路,今天说说应该怎么判断一个项目是否靠谱以及市面上最常用的一些接单平台。接单需知接触接单的开发...【详细内容】
2022-06-22  程序员客栈    Tags:接单平台   点击:(37)  评论:(0)  加入收藏
一个普普通通的25+女程序员枯燥且忙(bai)碌(mang)的一天✅7:40 闹钟不响绝对不起床[偷笑R],穿衣、刷牙、洗脸(平时上班不化妆)✅8:00 出门(骑电驴+地铁+班车+5分钟步行)✅8:40...【详细内容】
2022-06-22  香菜真好吃ii    Tags:女程序员   点击:(18)  评论:(0)  加入收藏
自由职业者:程序员是当今最不受约束的自由职业者,可以帮助人们了解他们的网站和应用程序。 博客:程序员可以轻松地拥有一个专注于人们面临的技术问题和困难的博客。 主题和模...【详细内容】
2022-06-22  独一无二的小魏同学    Tags:程序员   点击:(33)  评论:(0)  加入收藏
站内最新
站内热门
站内头条