优效学院，名师执教，学习更优效，IT在线教育领导者。三人行必有我师，人生是需要不断学习的，在这里我们相遇就是缘分，欢迎大家加群----四六零五七零八二四----让我们共同进步！希望各位可以看完这篇文章，也欢迎大家在下面留言讨论，天冷了，也动动手指转发收藏一下，谢谢大家！
缺少必要的注释
大段的if-else缺少注释，让维护者无法快速分辨分支逻辑。特定地方存在hack或复杂逻辑的代码，缺少注释会让后来者不明所以。为了你好，也为了后来者好，请务必加上代码。说不准以后还是由你来维护这段代码。
不变和变化的部分拆分
程序员中流传着一句话，此处不要写死，将来必改。有经验的程序员会将一些业务层的逻辑抽象出来，写成配置文件，好处就是若后续需求有改变，只需改配置文件即可，肯定不会引入bug。
忽视测试部分
程序员中又流传着一句话，没有测试的代码等于没写。虽不敢全部赞同，却也有几分道理。从测试用例驱动开发，持续集成，每次编译自动跑测试用例，能够保证系统的稳定同时也减轻测试成本。自己改的的部分做好自测，理解需求，做一个有责任心的工程师。
直接操作数据
你应该通过方法去操作数据，而不是直接操作数据,这样能够保证你总能操作数据正确。例如一个类中定义的属性发生变化了，代码中所有涉及到直接操作该属性的代码都需要修改。如果通过方法操作该属性，则仅需修改操作方法，对于外部调用者，类属性变化被屏蔽了，遵循了解耦的原则，代码稳定性大大提高。
缺乏文档或文档质量低下
前期文档很重要，不论是框架的API使用手册，还是需求或设计文档，以及各种既定流程的规范，不同种类的模板及核对表，等等这些文档，对于项目来说都是非常重要的资源。而往往有些项目，这类文档就是交由非软件行业的人员来编写，或者前期根本不打算在文档上浪费时间。
无尽的需求变更，永远追不上的进度
这是最常见也是最可怕的，因为无论怎样，我们都无法完成它。客户可能认为改个程序，就像改个Excel一样简单省事，甚至会使用可动用的一切权利和资源来推行变更。好吧，我承认这样的客户我遇到过很多。当我向客户解释过变更的代价并提供备选方案后，也就只能等待客户的选择了，这多少有些运数的成分，但也是无奈之举。
仅仅靠加班应对进度落后
进度落后并不可怕，可怕的是仅靠加班来追赶进度。这是问题的关键，长时间的赶工仍然无法赶上进度，这只意味着项目有某种更深层次的问题，已经不是单开赶工可以解决的了。留意那些长时间加班的项目，他们往往在管理上存在很大问题，发现这些问题，在你成为PM时，不要犯类似错误。
最后，如果想有一群“臭味相投”的朋友来一起交流学习的话，欢迎大家搜索群460570824，让我们共同进步！
网友评论