写代码，只是完成功能，堆砌代码。如果别的程序员接手，就会感觉比较吃力。难以维护，很怕去折腾这样的代码。所以很多技术员去维护的时候，宁愿自己写，不愿意在别人的基础上修改，因为看着别人的代码，难以看明白，加上业务部催任务的压力(包括老板)，如果还等到去看懂别人代码，再修改。费时费力了。所以他们往往喜欢自己重新实现一次。
这样问题就来了，别的技术员都不是在他的基础上去修改代码了。意味着以前程序员写的代码，对技术团队的贡献很少。要推倒重来。浪费了成本(当然老板不会清楚)
所以，发现，代码确实要遵循一定的风格，规范，做好注释。我习惯在注释里面，解释清楚当时为什么这样子设计。方便接手的程序员了解当时的考虑，可能是不得已，可能是出于快速完成任务。如果对方知道了来龙去脉，那么修改代码，就会变得有底气了。大家都是写代码的，会相互理解技术员的困境。但是丢一堆垃圾代码，注释不全的代码，造成其他技术员折腾，他们就不会理解你了，内心就会想：弄得这么垃圾的代码。
从技术管理的角度而言，的确要让技术员都遵循一定的规范来编写代码，这样子风格统一了后，新接手的技术员看着一大片代码，能够找到规律，多个人的风格，就得去适应了。找个函数，找个文件，都没发现一定的命名规律。否则，每个人可能写了一堆代码，功能是实现了，满足了当时的需求。但以后要增加新功能，新的技术员难以上手。又会重新实现一套。浪费时间，浪费工资。
每种语言的框架一般能够解决这个问题，让程序员必须遵循框架的命名，控制器，action，至少这两个是容易找了。我觉得discuz、ecshop这种折腾比较费力了。找文件，不熟悉的人，确实难以发现规律。我们要的是快速上手修改。
大型的团队，写代码确实不仅仅追求实现功能。如果这样子，以后痛苦的还是技术团队，欠下的债务。