刚来公司的时候，老是被派去修改旧项目的代码。那时候，感觉就是来气。什么设计，什么编码嘛。简直糟糕透顶。
但是这些日子，当管线平台的项目也有了这些迹象后，我才明确的意识到，如果还是按照原来的模式开发项目的话，不管你的水平多好，经验再高，项目到最后，都会被沦为修鞋匠的角色。
概念术语不稳定、文档描述稀缺、客户需求模糊、团队沟通不够，这些因素搅揉到一块，就不知道造成什么样的坏结果。
在公司里，我也想过一些可能的应对之策。在目前事务脚本的开发模式下，尽量想办法降低方法之间的耦合度；如果可能注释也做到随时添加。内行的人知道，这些拙劣的对策其实只是必须的编程习惯，它们的作用相对于整个项目来说也是有限的。
当需求从模糊开始走向清晰的时候，而项目的维护工作却在不断的加大。其实如何让维护的量降低才是问题的关键。现在，公司的困惑也是在这里。如何做或者说哪种方法才能有效地适应需求的频繁变更。
困惑归困惑，问题归问题。公司里也承认它的存在，但至今没有比较实际的摸索。原因有多种，不过我想有损失但也会有收获的。如果公司只想停留在手工作坊的话，我也就不用那么期许了。
从我自己来说，其实也不是很有那个经验。好作品的代码看过不少，但从那里汲取最多的也不过是代码层面上的门道。而项目代码实现除外的其他流程就不清楚。特别是那些企业应用的项目，软件设计和需求变更怎么和谐共处一直是我很想了解的。但是很不幸，在公司实战这一块，我想我是背道而驰的。现在我虽然还没有主管过什么项目，但有些事情迟早会经历的，未雨绸缪一下。
