为什么要把非技术放在前面呢,因为技术架构腐化是上层没有重视(比如压缩工期,频繁换人,需求敷衍等),下游码农趋利避害的产物。这个话题其实有点宽泛,这里主要从这几个方法
假设你作为新社招员工,对目前项目改造有很多想法,其实问题很复杂
针对这些挑战
历史债务大多数是盐碱地,就是连殖民地都不如,更不用谈黑土地了。
对于这种炸弹,如果自己没有信心,还是建议拖着并及时暴露风险。当然这种方法与印钱还债一样,如果债务多了,最终还是可能崩盘滴。如果发现项目实在带不动,时薪太低,没有成就感,领导不认可这种维护工作,没有指挥或方案权,那么还是早点跑路止损吧。
虽然有很多人将格子间中的码农比作十九世纪的纺织工,但是编码工作本质仍然不是流水线的工作。因此招人就显得非常重要了,详见我以前写的文章。
特别注意的是,如果人员不合适(包括代码,认知,言行等),一定要及时在试用期把人给换掉。这个流程是长期的,带有主观偏见的,比如我以前鄙视HR的唯学历论,认为学历不能代表能力,但是现实屡屡打脸:三年经验的三本同时与一本的应届生接手新技术/新项目,学习与输出能力就是差很多。
这里也侧面说明了应届生找一家靠谱的公司多么重要,差公司可以让应届生在三年内养成了一堆坏习惯
虽然这个是代码相关,但是代码检视本质是通过行政手段干预开发,这类先进的检测工具虽然很多,但是耗费人力比较大,说的不好听就是靠强制力推动,最低要求如下
项目中虽然有各种各样的文档,但是大部分公司可能还是用SVN,邮件甚至Word来管理文档,而不是使用Wiki/markdown等工具,导致搜索时比较心累,作为开发者应该如何解决呢?
我的建议: 实现关键词秒查解决
至于如何推动所有人写文档,这个比较难,但是要勇于深入群众,服务群众。
很多项目组中通常是一人兼任需求分析与人员管理,这种场景下将导致需求长期排满,导致没有挤出时间进行基础功能的优化,进而导致人员,代码的进一步恶化。针对这种情况,说白了还是人手不够,那么就更加需要自动化工具的帮助,但是加班代价是不可避免的。
正如开一家餐厅需要掌握制作过程,接手项目第一步最重要的就是掌握代码如何流向生产环境。通过洞察生产过程,可以发现与业界的Gap,进而进行重构。相关CI/DevOps过程需要由自己相关的人接管。
有些业务模块的确写的非常烂,而且重构成本的确比较高,修改任何一块砖都会崩塌,这时我们可以通过服务化将其封装为有状态的业务组件,新开发的组件通过RPC去调用它。这种操作并没有本质上解决遗留问题,但是新组件可以用标准的质量规范去管理开发流程,总体上分母变大了,相当于进行“隔离”操作。
所谓的微服务本质是一个组织架构的问题,它由组员的开发水平决定,一般是水平低才用服务化来隔离。
对于技术架构,静态检查等问题,是可以慢慢改的,难点主要是在测试压力比较大。我个人的原子性提交流程如下
上面步骤本质上就是实现了人工的编译器优化,每一次都是原子提交,而不要合并到一起。当运行测试用例报错时,很容易通过二分法迅速定位。
虽然上面只写了短短几行,具体代码改造需要依赖自己读过多少好代码了,这里可以看后文的参考文献
在很多项目中,我看到有许多人喜欢把文件按照后缀进行划分,比如service专门一个文件夹,controller一个文件夹,js一个文件夹…这样虽然看起来整洁,但是交接后再进行阅读时定位非常累,需要反复地进行JUMP。同时很多能力水平较低的开发,一不小心用了全局变量(比如给你整几个common.js),后期交接就炸了。对此我的建议如下
在真实项目中,常见的生成器有Mybatis,SOAP等业务。很多人图方便喜欢用工具一键生成上百行的代码,但是也留下了上百行的维护代价,具体如下
针对这些质量问题,我建议如下
@Autowired
即可注入,内部请求细节由Feign解释器进行处理。上面的缺点就是很多新人不会使用,这里就要完善文档,降低学习与沟通成本
纵观很多烂代码,偌大的for循环中无非就是为了实现一个GroupBy,或者为了去重而写了一堆HashSet,或者一堆continue,这类问题本质上是“做什么”与“如何迭代”强耦合导致。通过培训Stream技术可以降低代码中的for/continue等冗余代码,而且通过Clousure可以强制降低代码副作用,建议
针对超级复杂的逻辑业务,我个人一般使用GroupBy与模式匹配(Pattern Match) 提高代码可读性。
下面是可能需要进行培训的知识点一览
研发过程规范
编码培训
技术培训
《遗留系统重构实战》
《大型网站技术架构: 核心原理与案例分析》
《函数相应式领域建模》