爱华网因为最近有一位同事的功能要上线，我们经理就叫我们几位同事去听听这个功能，熟悉一下业务，顺便也看看有哪些问题。讨论玩后我觉得从这次讨论的过程中给了我一个警告，这位同事遇到的问题我后面也很可能会遇到。因此作为一次经验记下。
在这位同事的讲解中我们发现了很多问题，大部分问题都是这位同事在需求整理过程中没有考虑到的因素，导致目前的功能有几个BUG，因为程序的修改幅度比较大，在这个火烧眉毛的时候这位同事也感觉到了很大的压力，使之做起来很被动。同时代码质量也随之下降，开发成本也随之增大。
讨论完后我是能感觉到这次代码的修改的难度，因为涉及到数据库的重构。我在想怎样在前期就把这个问题解决，也不至于后期这么被动。考虑了一下觉得在前期解决这类问题可以这样做：
一、在功能开发设计完成后可在周会上提出自己的设计方案，可以让各位同事都帮我查看，看我在业务上有哪些考虑不全，以及这样开发对他们的模块是否有影响。确认无误后再开发。
二、在————程序设计时给程序留条后路。就算在周会上把业务都过了，但也不能保证没有遗漏或需求不变更。对于这种情况我觉得在设计时就因该考虑到某些潜在的因素存在，比如说如果客户突然还想在这个功能上再加个功能或觉得这种形式不好要换个方向等。如果我们的程序耦合性不强或粘为一团的话对于这种问题的到来是要付出惨痛的代价的。所以我觉得提高代码的耦合性才能从根本上降低代价。虽然在某些时候前期会麻烦点但从长远的角度来看是值得的。不论是从后期维护、需求变更或功能扩展都是最方便的。
虽然我一直在向“耦合”靠拢但速度不快，也还有一段距离，之前我没太重视。通过这件事我看我得加快脚步了。
