《CleanCode》第一章

《Clean Code》第一章

1.1 要有代码

要关注模型和需求,也要关注代码。

代码呈现了需求的细节。编程,就是将需求明确到机器可以执行的细节程度。

我们造不出能满足客户模糊需求的系统:需求规约原则告诉我们,规制良好的需求就像代码一样正式。

代码是我们最终用来表达需求的语言。

1.2 糟糕的代码

糟糕的代码能让项目毁灭。赶进度出产品,特性越加越多,代码越改越乱,最终导致没法管理代码。最终导致发布周期变长、崩溃率增高、加载时间过久

勒布朗定律:稍后等于永不。

就是说,Later 的 Bug 基本不会改。。。

1.3 混乱的代价

随着混乱的增加,每次改一点代码,都得影响其他两三处。每次加一点代码,必须对现有的一堆代码非常了解。也就是说,混乱的增加会降低团队的生产力。而这种降低,只通过加人可能并不能有太明显的改观。因为新人不熟悉系统,可能会带来更大的混乱。

新人可能搞不清楚,什么样的修改符合设计意图,什么样的修改违背设计意图。

(所以 Code Review 是非常重要的)

1.3.1 华丽新设计

老系统陈旧。于是一堆开发者献策,要推翻重做。但是新系统必须得实现之前老系统的所有功能,所以会导致周期非常长。

1.3.2 态度

程序员遵从不了解混乱风险的经历的意愿,也是不专业的做法。

1.3.3 谜题

制造混乱并不能让你赶上工期。

赶上工期的唯一办法,就是尽可能保持代码整洁。

1.3.5 什么是整洁的代码

尽量减少依赖关系

分层

整洁的代码只做好一个事情。

整洁的代码犹如优美的散文。

整洁的代码从不隐藏设计者的意图,充满了干净利落和直接了当的控制语句。

整洁的代码可以由作者之外的开发者阅读和增补。可读性,可改性。

做一个事情,只提供一种途径。

函数越小越好。

字面编程:Literate Programming。用人类可读的方式来写代码。

整洁的代码是作者着力着凉的代码。在意。

同一段代码如果反复出现,代表某种想法并没有在代码中得到良好的表现。

消除重复和提高表达力。

对于一个明确、通用、有多种实现方式的功能,可以面向接口。这样可以先用简单的方式实现,同时可以为未来的修改留下余地。

你可能感兴趣的:(《CleanCode》第一章)