N宗罪

N宗罪

这里数数做项目的几宗罪：

1.极度压缩编程时间。
      可能是觉得编程时间比较“长”，所以喜欢压缩编程时间。所谓的“长”，只是感觉而已，为何？因为按照经验估算出来的时间，首先给人以不准确的感觉。其次，先对于其他所消耗的时间，这个是可见时间（估算出来，列表出来）中最长的。再有，忽略了一些没有考虑的时间，如：文字重新修订，重新排版等等。
      这就使得你不得不加班了……

2.忽略很多其他占用时间因素
      很简单的例子，一些不得不做的临时事情。一些会议。项目时间被无情挤占了。

3.人为因素
       有人说过，“现在很多人更注重与谁共事。”。这很大程度上决定了你的个人作为。往大了讲就是公司氛围，往小了讲，就是自己加入的团队。不是一堆人在一起做事，就能称之为真正意义上的团队。团队是个复杂的概念，这里不樊述。加入了不大懂合作的“团队”，人为因素就会多起来，到一定时候，处理“人为因素”问题，反而比项目更着急了。

4.新旧混杂
       新的，可代替的出来了，还认为要保留老的部分，以便让系统更稳定，这看是好的，实际，暂时老的掩盖了新的瑕疵，感觉完美。一旦问题爆发，那就如滔滔江水连绵不绝，更如……

5.产品需求变更
       这是最令人头疼和最让人烦躁的。产品早期只来点大骨头，在产品完成的过程中，由程序员主导慢慢完善了产品，此过程中，产品大爷们始终处于“休眠”状态，在产品进入最后测试即将上线时，忽然“大爷”们苏醒了，指出不少“肉没有长对的地方”，无语……

需求不断变化，开发周期越来越长、开发成本越来越高。不幸的故事重复上演，有没有解决之
道？
作为开发人员，痛恨的事情之一就需求不明确，而更痛恨的事情就是需求不断变化。
需求不明确，意味着项目在初期没有明确方向，完全凭借开发人员的经验来判断应用应该如何
创建。但这样一来，在下一个阶段进行返工的可能性几乎是100%。而且更糟糕的是需求不明确通常
也意味着开发中需求会不断发生变化
需求发生变化时，应用程序的方方面面都要跟着改变。虽然这是不可避免的情况，但是频繁的
需求变化如果缺乏对应用程序良好的重构，除了让开发人员感觉疲惫外，还会让应用程序逐渐腐朽，
最终变成无法维护的一个怪物