下降软件复杂度

本文原创：yangyanchun

在进行软件开发时，咱们经常会追求软件的高可维护性，高可维护性意味着当有新需求来时，系统易扩展；当出现bug时，开发人员易定位。而当咱们说一个系统的可维护性太差时，每每指的是该系统太过复杂，致使给系统增长新功能时容易出现bug，而出现bug以后又难以定位。

什么是复杂度

修改扩散

修改时有连锁反应，相互依赖，耦合度高，某部分代码不能被独立地修改和理解，一定会牵涉到其余代码。

认知负担

开发人员须要多长时间来理解功能模块，从代码中难以找到重要信息

不可知

开发人员在接到任务时，不知从哪里入手，数据流向混乱。

复杂性的危害在于，它会递增。你作错了一个决定，致使后面的代码都基于前面的错误实现，整个软件变得愈来愈复杂。"咱们先把产品作出来，后面再改进"，这根本作不到。

如何下降复杂性

重视设计和细节的改进

拒绝战术编程，采用战略编程

战术编程致力于完成任务，新增长特性或者修改Bug时，能解决问题就好。这种工做方式，会逐渐增长系统的复杂性。若是系统复杂到难以维护时，再去重构会花费大量的时间，极可能会影响新功能的迭代。

战略编程，是指重视设计并愿意投入时间，短期内可能会下降工做效率，可是长期看，会增长系统的可维护性和迭代效率。

设计两次

为何该方案可行？

架构图、接口设计、时间人力估算

在已有资源限制下，为何该方案是最优的？

在关键点或争议处提供二到三种方案，并给出建议方案

水平分层，垂直分模块

层次和抽象

复杂性下沉，尽可能让用户使用简单，接口要简单，实现能够复杂。

深模块：功能强大，接口简单，是抽象的最佳实践，经过排除模块内部不重要的信息，让用户更容易理解和使用。

浅模块：功能简单，接口复杂，无助于解决复杂性。由于他们提供的收益（功能）被学习和使用成本抵消了。

好的 class 应该是"小接口，大功能"，糟糕的 class 是"大接口，小功能"。好的设计是，大量的功能隐藏在简单接口之下，对用户不可见，用户感受不到这是一个复杂的 class。

异常处理

尽量减小须要处理异常的可能性

用户必须面对全部的 error异常"反正我告诉你出错了，怎么解决是你的事。"，正确的作法是，除了那些必须告诉用户的错误，其余错误尽可能在软件内部处理掉，不要抛出。

通用和专用

知足当前功能，快速实现，接口设计通用化

知足当前需求最简单的接口是什么？在不减小功能的前提下，减小方法的数量，意味着接口的通用性提高了。

接口的使用场景有多少？若是接口只有一个特定的场景，能够将多个这样的接口合并成通用接口。

知足当前需求状况下，接口的易用性？若是接口很难使用，意味着咱们可能过分设计了，须要拆分。

注释文档

好比“好代码是自注释的”、”没有时间“、“现有的注释都没有用，为何还要浪费时间”等等。这些观点是站不住脚的。“好代码是自注释的”只在某些场景下是合理的，好比为变量和方法选择合适的名称，能够不用单独注释。可是更多的状况，代码很难体现开发人员的设计思路。好的注释能够减小文档工做。

使用注释提高系统可维护性, 重视what、why，而不是how(而不是代码是如何实现的)