代码无可替代,市面上会有生成代码的工具,但是对于客户而已,很多需求都是模糊甚至自己都不知道想要的是什么样子的,所以我们无法抛弃必要的精确性,
所以代码永存.
不同的需求会产生不同的代码,方法,模块.我见过很多程序员(包括我自己..)都是需求一到立马上手,针对需求快速的由页面,后台,数据库写出一套能运行的一个流程,
而后会发生什么呢?
当一个系统开发及维护超过三个月之后,你就会发现系统里纵横交错,错乱复杂的代码,超强耦合的方法,照着开发文档和需求文档都读不懂的逻辑关系,
例如我遇到了一个代码上,只需要把"int i=0",改为"int i=1"这样简单的需求变动(类似于,实际当然没有这么简单),你们猜我改了多久?
一整天再加半个上午!
这对于我这种以开发速度骄傲的人简直是种侮辱,(关键在于甲方是确确实实的催命鬼...)
然后我给我自己找的理由是,客户要的急(其实一般是当天需求隔天实现第三天测试返工或发布)
然后最终发现,其实是因为自己懒
我已经从事与敏捷开发五年了,前两三年锻炼出来了上述的快速写代码的能力,巅峰的时候比如,客户早上上班提出一个新页面(包括列表,新增修改,导出,删除)我大概午饭前就能测试好然后直接发布
但是这真的是我想要的快吗?或者说这是真正的快速开发吗?
像我这种名义上的"高效"的方法,其实宏观上的效率是这样的
随着时间的流逝,需求的增多,我的效率或者说速度会越来越低,到最后趋近与0
可能新需求来临,我还是会如之前一样的"高效",只是需要改动一些小变动.
但是需求不是一成不变的,只要客户提出改需求.我就好像吃了老鼠药一样...绝望及坐以待毙
是真的是需求变动的问题,还是咱们程序员自己代码写的有问题呢?
其实问题已经慢慢浮上水面了不是吗.
不是客户的需求变动有问题,(毕竟人家是掏钱的,就算真有,那人家也是给你掏了钱的)
所以怎么解决呢?
回头我会写一份详细的解决方案