那些会阻碍程序员成长的细节

罗马非一日建成，软件系统也不是一天可以写出来的，在经年累月的编码生活中，总会那么些个不经意的瞬间暴露出来，而这些不经意的外在表现日积月累，犹如水滴石穿，会产生巨大的力量副作用于程序员的成长。我简单列了几条，看一看，兴许就在你我身边实实在在发生过。

拿到开发任务后，直接上手写代码。缺乏必要的沟通与设计，返工的机率极大。先后端数据的交互格式，功能潜在的关联点不清晰，接口调用方功能是否完备，存储结构的设计，复杂业务的流程设计等等，都须要事先沟通肯定好，再动手写代码才能游刃有余，否则会走一步卡一步，进展缓慢，甚至倒退。

在逻辑混乱的地方加入新东西，而不是去重构。因为功能的新增或变动，须要在旧有的代码逻辑中添加新功能，本是一个很好的重构机会，但不少的作法时在原有的基础上填填补补，结果一片混乱。特别是在本已混乱的地方还要加入新代码逻辑，运行起来确实没有问题，但对自身代码质量的保证零意义。

不肯意与别人分享技术成长。教是学习最快的一条路，将本身所学传播分享给他人，并使他人能消化吸取，是对本身知识掌握一个最好的检验。同时在分享的过程当中温故而知新，更加深对知识技能的掌握。若是你有教会徒弟饿死师傅的想法，会显得很落伍。互联网时代下，还有什么知识技能，是你独有而别人历来没有的？不如拿出来分享，你们共同成长。一个走的快，但一群人才走的远。

遇到BUG首先否认是本身的问题。这是一个普适性的问题，也是程序员遇到BUG时的第一反应。究竟是不是别人的问题呢，每每是问题转了一圈又回到本身手里。耽误了你们的时间，同时下降的解决问题的效率。正解的姿式应该是当即检查自身，肯定是否是本身的问题，是就当即改正，若不是，能找到问题所在最好，交由他人去处理，这是一种良好的习惯。

缺少验证条件时，开发的功能不经测试直接交付给测试人员。一种是过于自信的表现，还有一种是懒惰的表现。有自信是好的，但若是能通过实际的场景来检验，双重保险，对本身对团队都是保证。懒惰就是不负责任的表现，有些功能确实测试起来很复杂，但为了保证功能的可用性，没有条件去创造条件也要完成，这也是一种态度。

修复某BUG时，夹带其它问题。一个未被测试人员发现的BUG，自我发现后私自修复，并提交源码。这在测试阶段比较常见，但后期若是还出现这种问题，对产品/项目的稳定性是个极大的隐患，特别是生产环境。这是一个流程规范问题，也是一个职业素养问题。

先简单写到这里，以上这些都不是大问题，但若是不注意，长此以往会演变成大问题。程序员是个特殊的物种，物种的进化依赖咱们自身的知识结构、思惟层次，更依赖于平常工做生活的三省其身，常常复盘总结回顾，才能发现问题，近而解决问题。