项目的可维护可持续性思考

   大项目的业务逻辑和架构可能都比较复杂，那么进行熟悉时，需要时间就非常长。

进行业务逻辑文档整理，设计架构文档整理，技术代码文档整理，codeview，人才冗余储备培养，对小组成员进行通用培训，让每个人都能大概熟悉项目，就非常有必要了。

技术部门应该分成架构师和cto并进行分权，不能资源全在一个人手里面。

京东非常注重人才的冗余备份，但是领导层就不知道了。

 

--以上来源于燕飞宏事件和群友朋友的探讨。

 

-------------------------------------------------------------------------------

20190903更新

需要思考下如何把复杂项目变的易于维护，需要思考下。

1，使用新的技术框架，简化之前老旧技术的带来的复杂性？

成本比较高，风险如何控制呢？如何保证业务稳定性？

 

2，将业务需求描述注释到代码中，读代码时看下业务描述，看下实现方案思路，对项目代码就能有个大概了解。

需要持续维护注释，保证注释的正确性，否则可能误导代码维护人员出错；

降低了代码阅读流畅性，这个只是感觉，如果不知道代码是在干什么，代码没有注释看不懂，那么看似清晰的代码也没用了，针对复杂业务而言；

 

3，减少方法的代码行数，对业务进行分块处理；

分模块要不揉在一起更容易禁得起时间的考验，虽然业务简单全部放在一起，更容易调试和查看。