转的

来京已近一月，项目进度依旧，之前在成都听说京城同事工作多年，技术超群，业务娴熟，来之前以进京朝圣之心，希望能得到点播，早日修成正果。交流几轮，仰望之感无存。公司内推广敏捷数月，但未见明显差别，作业依旧，亦有同事以'中学为体，西学为用'的想法对待。 设计理论是用来实现系统需求的，器物是用来使用的，技术是用来为业务服务，这些都是当然的。但敏捷的根本是什么，敏捷实行的前提条件是什么，能够把这些问题解释清楚的不多。有少数人在网络了解敏捷的之言片语，敏捷，领域，都像残片聚集一样，并没有整体和系统的见解，同时容易受厂商宣传影响，普元的SOA即为一鲜活案例。绝大多数人更是闻所为闻，还是持有表建模的理念来设计现在的系统，全无设计的见解，如果寻问其某处设计的原因，多数回答复用方法，或是为了性能考虑。分层是什么，为什么要分层，却没有完整的见解，系统架构常用之前的系统仿写，有疑问一问，回答的确是以前某某牛人是这么做的。这个曾让我想起网上看过的一个故事：一个小男孩，他奶奶是个做鱼高手，他也经常在旁边观看，每每看到奶奶做鱼时，奶奶总会先把鱼尾巴和头宰掉，当然，经常这么观察，小男孩也学会了做鱼，但是手法都和奶奶一样，在之前会把鱼尾巴和头宰掉，小男孩长大后，一次朋友听说他会做鱼而且味道不错，要来学习，他依然先把鱼尾巴和头宰掉，朋友不解，问他为什么，他也不知道，只说奶奶一直都是这么做的，朋友还是不绕，要问个究竟，他没办法，打电话回家问，奶奶回答也很简单"当时锅太小了，不宰掉没法做"。在系统架构中，不知道有多少类似的故事。 天道无常，银弹不在。想要用不变之设计架构变化无常的系统，可维护，可扩展当然不复存在。系统对于设计师，亦像孩子对于母亲，需求调研开始，系统像胚胎一般生长，无数需求变更，架构变更和痛苦之后，十月怀胎之后呱呱落地，新生的小生命开始新的旅程，开始其独立的命运。在与环境不断地氧化腐蚀抗争之下，数年之后是依然挺立还是举步维艰，受不了一点变化？ 敏捷并非银弹，只是习惯，和饭前洗手，饭后洗碗一样，保持良好的卫生习惯可以使你的寿命延长而并不能保证永生一样。那些视敏捷为器物之人会视洗手洗碗为有用则用，不用则不顾吗？以此做比喻也许并不是特别恰当，但更要命的是，更多的人不光欠缺保持卫生习惯的理念，而且连何为卫生都不知。这和中世纪的野人有何异？ 何为面向对象，何为接口，多数人多会回忆起学校讲到的person-student之类的例子，以为懂得了继承，回忆起FLy-Bird之类的例子以为懂得了面向接口。但实际工作中呢，还是action-service-dao的不变的结构，还是先设计model，但是所有的层都有一个类与其对应，这是面向对象吗？这和表建模有何区别，更多人号称用hibernate之类ORM工具得心应手，仔细一看还是干的表建模的勾当。妄图以此等理念去推进敏捷，无异于缘木求鱼。连对象为何都不知，以业务为中心的use case都不知，习惯用store procedure处理复杂逻辑，将独立的、上下文无关的、有生命的、会进化的业务逻辑深深地封存于离domain十万八千里的dao之下，深深地绑定到特定数据库之上。在生的一刻起就没了生机，与敏捷提倡的随时应变和及时沟通也没有了瓜葛，周身捆绑之下，哪里还有活动的余地。推广敏捷的前提毫无疑问得落到领域建模身上，明白对象，明白领域，才有敏捷。而对对象的抽象与提炼，并不是一个经过简单培养就能短时间达到的能力。这不是技术，是思想，所以要经过一些的锻炼，磨砺甚至冒险才能有所收获，最后获得的必定是一套完整的进度控制规范，编程理念，和最优价值的独立的业务领域。其中的关系让我突然想起最近读到的东洋先贤福泽谕吉的<文明论概略>，其中重点提到的"智德"的概念,作者视民智为文明进步的根本，不去盲目需找银弹，不满口"大和民族是伟大的"来找寻自尊，提出文明是一个过程，承认落后，也承认西洋文明之中的问题，以实在的态度对待外来的文明。在开发领域也是如此，没有每个开发人员抽象意识，设计理念的提高，妄图用运动方式推进敏捷结局如何?不言自明。