`
iamlotus
  • 浏览: 106855 次
  • 性别: Icon_minigender_1
  • 来自: 上海
文章分类
社区版块
存档分类
最新评论

中医和西医的对话——兼论敏捷

阅读更多
   最近在看的一本书叫《中医和西医的对话》。话说我原本是个科普爱好者和不坚定的中医怀疑论者,而每个科普网站但凡有人拿中医出来说事那个帖子必然会离题万里,转化为“中医就是好”派和“中医就是好个屁”派之争。比如松鼠会的这个看片会http://songshuhui.net/archives/22944.html,双方的说法都不能让人信服,偏偏我是个不怎么生病更不怎么愿意看病的人,中医没看过也没什么切身体会;偏偏又想深入了解一下这个问题,便去图书馆找了这本书来看,希望看看从中医(作者是中医)的角度是怎么分析此问题的,兼听则明嘛。
   这书第一个话题是说中医和西医不同的方法论:中医辩“征”施治, 认为不同的病理表现可能是相同原因(“征”)所致,而相同的表象也可能是由于不同的“征”。用关系术语来说,这就是个多对多的关系。中医施治也不是针对表象,而是针对“征”的,治病首先要找对“征”,然后把什么阴虚阳虚的症给搞掂,表象也就随之消失了。也就是说,把源函数理顺了,目标函数自然就连续光滑了。 西医则是对“症”下药,认为问题和原因是个一对一的关系,哪儿有问题就治哪儿。头疼?就开止疼片,吃了止疼片头疼是好了,如果胃又不舒服了咋办呢?那就是内科大夫的事了~~,所谓“头疼医头,脚疼衣脚”是也。究其原因,中医把人当成一个整体来治,下方子时要考虑到人体各个器官的相互协调,甚至其所处的自然环境。而西医把人当作机器治,把你拆成一个个零件,自然也就是一个个零件的治法。
   且不说这样的描述是否偏颇,我倒是读着读着又想到软件的本行了。如果把整个软件开发作为一个人考虑的话,我们现在的开发流程倒有点像文中所述的西医治病:先是BA作需求,还有几个BA各作各的模块,彼此之间或许还有些冲突。由于缺少专门的设计人员,BA还要兼顾一部分设计工作,这带来了两个问题:一是BA眼中没有对象只有数据表,并且表和表之间冗余严重。按照这种设计去作,整个系统必然是一层平面的薄纸,维护代价大且容易出错;二是没有人愿意去更改甚至推翻以前的不合理设计,以免可能会有的用户抱怨,对于新的CR只是不停的往原先的设计上加补丁,以至于整个设计越来越ugly。
  再然后是Developer实现,这实现又分Domain / Service/Client。由于design review 只是走形式(并且很多时候design已经被BA自作聪明了),所以越到底层的developer想的越是自己这块不要出错,而不会站在整个business的角度考虑实现/效率/用户体验。
   客观的说,就算这种方法把软件拆成了一块块需求一块块实现,然后一块块单独去做,整个系统还是走过了5年时间,虽然中途也遇到过性能问题,时不时出点脏数据什么的,但还是如同神州大地上大部分系统一样走过了这么多天并且活的还行。而且相信这也是软件开发的主流,正如西医是目前的主流一样。
   那么敏捷呢?敏捷在我看来颇有中医的风范。你要和客户交流,帮助客户抽象出领域模型,给出需求在不过度设计下的估计工作量,用test case 清晰的描述你的设计并检验之。每有变化,考虑的不是在哪儿哪儿加几行就搞定了,而是要考虑到这几行会带来什么bad smell,重构之。甚至进而要考虑是不是原有design的某个assumption失效了,改进之。作这所有事的都是一个人,也只能是一个人。
   如果你能够很好的实施敏捷,那么你的项目一定很好,因为你一定很牛。
   所以说,敏捷不是银弹,只是一些对软件开发有足够经验和技能的人觉得机械化的分工方法阻碍了他们生产率的提高,才提出的更适合他们技能水平的一种开发方式。看看倡导TDD的这些人和团队吧,有哪个是所谓的软件蓝领流水线呢?没有相应的人员素质,最多只能搞搞Scrum这种伪敏捷,至于TDD,不能搞,也不应该搞。
  再回到中医和西医的问题上。中医给人的感觉一定要老中医才牛,因为从整体上把握人体不是光读读黄帝内经就够的,需要大量的试错和体验。而老中医的产生要时间更要天赋,更接近于艺术而非技术,所以“老中医”是无法量产的。如果试图用西医学院那种细细分科,单独培养的方式,产生的只能如作者所说,大部分是以西医方式行中医,误人而已。相反,西医的哲学注定了其产出(医生)区分度没有那么大,能产生大量“也许不那么好,但也没那么差”的可用产出。在医疗作为一门产业的今天,医疗工人能够量产是一个很大的优势,我觉得这也是西医如此繁荣的一个原因。正如软件变成产业的今天,前一种虽有诸多不足之处,但却能够利用诸多软件工人的流程能如此流行的原因。
  所以我有时会感到绝望。尽管敏捷的很多提法会让你觉得简单和美,但考虑到人员素质之后还是不可能推行下去。也许人员的培养会是一个好的提法,毕竟一张白纸如果有好的带领的话估计两年时间应该能达到敏捷的要求。但考虑到业界平均流动率和相对固定的新人素质后,这又成了一道无解的难题了。
  最后说点极端的例子:chrome的开发团队只有20个人,bigtable的团队只有9个人。如果你没有这么优秀的员工,随便你用什么软件开发方法估计都搞不出这些软件来。而如果你能找到一种方法,能使北大青鸟的毕业生有50%达到这种水平,恭喜你,不要说什么图灵奖,就是诺贝尔和平奖您都能抱回家了(Obama长舒一口气中)
0
0
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics