低维护成本的软件开发

低维护成本的软件开发的目标

  • 没有技术债务。

  • 代码可维护,开发者可以在忘记它5年后回来继续改进它。

  • 任何阅读源代码的程序员都可以很快理解整个系统的构造。

  • 软件无限接近完成状态,直到因环境变更而落后或新的需求出现为止,足够令人满意。

实现低维护成本的软件开发

  • 使用经过时间和逻辑双重检验的技术,因为这些技术有希望存在更长时间。比做错决策更糟的是一开始就做错决策。

  • 总是全局性地思考问题,总是重构,允许大量的代码行修改,以降低软件熵。

  • 通过增加使用者的学习成本来砍掉不必要的人性化设计,因为人性化设计往往是难以维护的。让我们考虑一下Markdown编辑器和所见即所得编辑器:前者需要用户付出(极少量的)学习成本,而后者几乎没有学习成本,然而,后者要比前者差得多:

    • Markdown编辑器的用户更容易编写出结构清晰,人类可读的纯文本文件;所见即所得编辑器的用户往往会制造混乱的内部格式,用于Markdown和HTML的所见即所得编辑器也无法避免这一点,除非它们总是进行格式化——这又会破坏掉用户自己的编写风格。

    • Markdown文档在2050年还可以使用,Markdown编辑器往往是极简和可替代的;所见即所得编辑器更容易过时,维持向下兼容性更困难,对开发者来说也更难维护,供应商在2050年很可能已经不复存在。

  • 不使用重型框架,尽可能减少依赖低质量的软件包和不具有可持续性的环境。

  • 不使用任何BaaS、SaaS、FaaS、Serverless等云计算平台提供的服务。

  • 不使用不能锁定版本的包管理器,不使用Git仓库作为软件包的来源。

  • 如非必要,不配合现存的标准和协议:大多数标准和协议是垃圾,其中大部分甚至没有参考价值,配合它们只会拖累软件的发展。

  • 接受不可预见和不可消除的单点故障的存在,准备Plan B。有经验的开发者可以避开很多单点故障,但不可能消除所有单点故障,往往要到故障发生时,人们才注意到它的存在。对单点故障的过度防范会降低开发效率,引入为边缘情况设计的代码,从而破坏代码的可维护性。

  • 使用好的开发工具,而不是只是看起来低摩擦的开发工具。

  • 保持简单,保持知识共享,降低软件的巴士因子

  • 自动化集成测试,以提升依赖项升级时的安全感。