共计 3760 个字符，预计需要花费 10 分钟才能阅读完成。
当初许多国内互联网公司的我的项目都继续了五年左右，美国老牌公司如 IBM 的我的项目甚至继续保护了十五年，然而这些我的项目却有着截然不同的保护老本，有的公司我的项目运作几年后保护老本仍然与初创期不大，能够放弃较为高效的迭代速度，但有的我的项目甚至改几个文案都会导致线上事变，研发效率变得越来越慢。
依据笔者的教训，尝试总结一些继续保护我的项目变得难以保护的起因，以及如何设计能力保持良好的可维护性。
精读
心态
如果不真心看待本人的我的项目，其实是很难做到良好可维护性的，所以第一点就是须要一个良好的心态。
作为我的项目管理者，一个我的项目一旦交给一位同学开发，那么就要齐全信赖这位同学的能力，因为实际上你曾经不可能实质性的影响到开发细节了。有人可能感觉好的流程或者预先 CodeReview 能发现一些问题，但这永远是无济于事，比方上面这个例子：
小张接到工作研发透视表，要求这个透视表具备良好的开发体验并做好单测。
那怎么样做单测才算是无效的，如何同时保障开发体验呢？不同人会有不同的想法，也会有不同的后果。
有主人翁心态的小张
对于一个有肯定教训，又对我的项目真正上心的小张来说，开发过程可能是这样的。
首先上来先写次要性能，比方思考数据模型、绘图技术计划后，决定采纳图形语法形式定义数据结构，在做了一系列高性能前置思考后，疾速做进去了一个原型，蕴含表格的渲染、操作、翻页、解冻等等性能。
但随着需要的深刻，小张发现做到下钻、排序时，不晓得为何影响到了列解冻的性能，而代码架构其实没什么大问题，形象的也很好，次要就是一些细节的代码调用漏掉了，只有补上就立马买通了任督二脉，整套性能再度行云流水了起来。但不晓得下次做树状展现构造时会不会又把之前的性能影响了，这始终是个隐患，于是小张开始思考先把单测加上再持续开发性能。
因为出问题的场景有很小局部是大量操作后偶尔引发的，一般的函数式单测也无奈保障笼罩的全面，因而小张决定做一个单测录制性能，他首先把对表格的所有操作 Action 化，让一套 json 能够形容所有用户操作，而后又在本地开发界面做了一个单测录制性能，即在页面上对表格性能拖拖拽拽时，就会实时生成这套用户操作 json，再把过后页面构造与外部状态记录下来作为比照根据，单测就还原这套 json 并与基准状态做比照就行了。
小张很快录制了很多原子操作的单测，比方表格的各种空数据状态、单行单列渲染、列解冻行解冻；而后又把一些性能混合的场景联合起来，比方列解冻时排序，翻页后进行下钻；最初又把一些随机简单的性能组合在一起，造成一些日常容易出问题的非凡单测 case，比方表格单页后忽然清空数据，再强制解冻第二列，再灌入 3 列数据并对第 2 行做排序，再勾销列解冻并翻到第 4 页。当前每当遇到一个边界 case 时，小张都会把这个问题 case 记录到单测，验证的确运行失败，再进行修复，直到蕴含这个单测在内的所有单测都验证通过后，才算开发实现。
打工人小张
对于为了混口饭吃的小张来说，开发过程可能是这样的。
首先上来写次要性能，把各种表格性能做完后，也遇到了一样的边界 case 难题，此时小张原本想 case by case 修复，但又想到 leader 要求他写单测，感觉倒也不坏，就创立了单测目录。
怎么写单测呢？首先小张把遇到的问题修了，毕竟谁也不心愿本人手里的 bug 太多，但至于录到单测就太麻烦了，反正大家也不晓得这个 case，修掉了就再也不会进去了吧，那就只把 leader 要求的几个基本功能单测加上去，看下覆盖率也达到硬性指标就行了。
大团队代码总是容易走向凌乱
假如你是 leader，你不晓得本人团队的小张到底是主人翁小张还是打工人小张，希图通过 code review 来对立晋升团队的代码品质，实际上可行吗？
如果可怜遇上了打工人小张，他在 code review 时展现的代码构造就不是能做整体单测的形象，你只能看着单测文件硬提一些比方“多加一些单测，多思考一些状况”的倡议，实际上齐全达不到主人翁小张做的成果。
这背地的起因是影响代码品质的因素太多，比方 Action 化，比方各种极其 case 的录入，比方全流程的单测模式，这些对代码来说都是量变，但 code review 时看到的代码就是不够形象，不够 Action 化的，不可能把代码颠覆重写一遍，只能在已有代码根底上提优化倡议，而到这个时候，神仙也没法让打工人小张的代码优化为主人翁小张的，除非颠覆重写。
这就是心态的影响力，能把我的项目做好的细节很多，而且细节之间还是环环相扣的，比方不把代码 Action 化就不不便做整体单测，但如果开发者打一开始就没想好好设计，code review 时又有多少人能想到这一点呢？想到了此时再提可能也为时太晚，所有都已成定局。
这些年笔者看过不少久经历史的代码，因为大公司有大量的开发者保护同一个我的项目，每个人开发时的心态都各有不同，会发现总能看到那些模块是用打工人心态做进去的，而你想彻底优化就只能彻底重写，但碍于我的项目体量太大工夫上不容许，只能沿着打工人思路洋洋洒洒的持续写下去。
所以领有一个良好，侧面或者说踊跃的主人翁心态来写代码，一般来说都能够保护好简单我的项目。
解耦
简单我的项目的简单指的是什么呢？是指性能多吗？其实不然。
如果仅从性能多就断定这个我的项目简单，那咱们身处的社会才是最简单的零碎，但社会中的每个玩家都没有感觉吃穿住行很难，外围起因就在于理解咱们用到的场景只须要大量的常识，而做出一个口头要失去正确的后果，也不会造成太大的影响。比方出门买菜，只有做个公交车到菜市场，扫一下码就实现了交易，而不须要对背地的城市公交体系与菜市场背地的金融体系有任何深刻的理解，你不须要了解公交车是哪儿来的，菜农手里的菜是从哪儿收买的。
但代码世界就很乏味了，在代码世界买个菜可能会导致世界覆灭。这就导致每一个我的项目开发人员，哪怕是去买个菜，也要受过总统级训练，对各种国家级小事做出正确的预案，为什么会这样呢？
因为代码世界的逻辑是不同开发者码进去的，在实现世界底层逻辑时可能就埋下了耦合的种子，导致你不晓得为什么买菜会触发那么重大的事件。举个例子，改一个文案导致系统解体，起因可能是某处谬误兜底逻辑用字面量判断了这个文案，而你把文案改了，这个判断就生效了。有的程序员挺难的，在这种我的项目环境下生存，每一步批改都要小心翼翼。
这个问题的解决办法就是解耦，在这里咱们不细说具体怎么解耦，因为每个场景的解耦形式都不同。咱们只须要了解简直所有的业务逻辑都能够用解耦的形式做，就行了。只有你依照这样的大思路去设计零碎，不管门路是怎么的，最终都能设计出一个丑陋的零碎级计划。
比方做一个 BI 零碎，看上去外面有各种简单的模块可能会产生相互影响，比方数据处理、仪表盘搭建、大屏搭建、图表、GIS 地图等，在设计之初就要伪装其余模块不存在，来思考每个模块必要的输出是哪些。
比方布局，它仅仅用于对画布进行布局，为了保障布局零碎是齐全解耦的，必须让我的项目反对在无布局的环境下运行。为了做到这一点，就必须让布局真的“只做布局”，而不存储以后画布构造，这样才不会因为布局零碎被移除时，影响组件的联动，因为组件联动须要利用画布构造 API。
图层列表也能够和布局解耦，因为图层列表只关怀画布的组件树结构，而不关怀布局是如何实现的，所以画布的组件树结构就像生存中的金钱，大家都能够用它交易，而无需关怀它流向了何方，被谁应用。
数据逻辑与画布构造无关，只须要关怀表达式以及用户对维度度量的配置、聚合形式以及图表自身的个性进行查问 sql 拼接即可，惟一用到的通用资源是以后组件实例信息批改后，须要更新到画布的组件树上。
社会也是建设在这种底层认同上，能力这么解耦的，所以在简单我的项目中肯定要有一个大家都认可的底层概念，这个概念应该尽可能通用化（想想金钱什么都能买，如果只能买蔬菜就麻烦了）、贯通整个业务逻辑（金钱是古代社会任何交易都必须的媒介）。
许多我的项目被诟病难改，往往是没有遵循这条逻辑，硬生生把能够不相干的概念耦合了。比方某个筛选器条件变动时，对某个组件做非凡操作，这个场景能够管制反转为，这个组件在接管到某些筛选条件时，本人做特定的操作。因为对 BI 零碎来说，筛选器的输入要作为图表绘图的输出，在这个底层框架下，就不要再开拓一条筛选器关怀到具体图表的逻辑了。
总结
保护好一个简单我的项目很难，这次分享了两个实际中有用的计划，第一个抱有主人翁心态设计代码，要在设计之初就做好考量，不要寄希望于对没有好好设计的零碎做缝缝补补。第二是深刻了解为什么古代社会的运作奇妙之处，尽可能把代码架构组织肯定水平映射到社会的运作机制上，目前来看，社会最适宜代码借鉴的思路就是解耦，再利用宏大的分工协作网络实现单人无奈实现的工作。
探讨地址是：精读《保护好一个简单我的项目》· Issue #454 · dt-fe/weekly
如果你想参加探讨，请 点击这里，每周都有新的主题，周末或周一公布。前端精读 – 帮你筛选靠谱的内容。
关注 前端精读微信公众号
<img width=200 src=”https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg”>
版权申明：自在转载 - 非商用 - 非衍生 - 放弃署名（创意共享 3.0 许可证）