程序员做好大项目的3个方法！

  

         什么叫好？什么叫“垃圾”？

最近群里有粉丝吐槽，说入职新公司后交接上一个程序员负责的项目，发现相关的代码非常复杂和庞大！入职一个月了每天加班到凌晨，才勉强搞清楚里面的部分逻辑...

这让我不禁想起之前一个笑话：说有些公司衡量程序员的绩效，靠计算代码量。谁写的代码多，谁的绩效就高，证明他花了时间，没有划水。

真正写过代码的都知道，越厉害的程序员，会用越简洁的代码处理问题。

因为过多的代码意味着需要更多的人来理解和维护，其中的成本非常高，人一多，组织管理的问题也随之而来，陷入无限循环...

其实代码库过于庞大的问题，无论大厂小厂都会有。

有些是因为程序员能力不行，只能靠堆积代码的方式来实现；有些是因为业务逻辑确实复杂，大型系统不得不对应大量代码。

最近看到一篇文章，针对这类问题提出了一些解决方案。基于我个人这么多年的工作经验和对技术的思考，跟大家分享其中3点：

1、阅读文档

想快速熟悉大型系统，最简单快速的方法就是仔细看文档！

但有种情况是，系统迭代了很多版本，有些文档早就过时了，有些逻辑可能要关联看上好几个文档才能搞明白！

这时候就要不耻下问了！交接的人还在就一定要搞清楚细节，没有交接的人就多问问接手过这个项目的其他程序员，怎么着都比自己闷头瞎琢磨快!

undefined

要学会利用他人所了解的，来帮助自己快速搞懂一些本没必要消耗太多时间的事情。

2、简单测试

当我新接手大型系统里一些特定关键部分的问题时，我通常会简单运行测试一下。

在这过程中，通常会发现一些要修复的问题，但往往因为系统过大所以一般不会动这里的代码。

一是我无法修复所有隐藏的bug，二是系统的复杂性不允许我在短时间内全部修复，或许还会在不完全了解的情况下引发新的问题。

建议大家在这种时候，把一些关键问题记录下来，等到代码需要重构时，就能快速定位并解决这些问题。

3、查看日志

当你尝试去了解大型系统的时候，一定会有疑问：

它为什么会变得如此复杂庞大？哪些功能是重要的？哪些是非必要的？

这时候你可以去查版本日志，每次发的大版本，一般会包含一些重要功能的迭代详情记录，有助于理解每次迭代决策背后的原因。

没做过大项目，不代表不能理解复杂代码，功夫主要在平时！

程序员相对来说和做业务的人不同的是，虽然也靠经验，但遇到新的问题时，考验的是底层能力。

之前在一本书里看到一句话：“失败不是悲剧，放弃才是。”

没做过大项目不是失败，自己看低自己而放弃进步才是失败！

商务合作 / 技术交流