几种华丽无比开发方式

老文章了，不过看起来感触很多，放在这里警示自己。基本上我现在工作的项目输入SDD + DDD + IDD + MDD。。。

几种华丽无比开发方式

投递人 itwriter  发布于 2013-03-05 14:30  评论(2)  有414人阅读   原文链接   [收藏]   «  »

　　不要被我的标题骗了。我可不是来宣扬什么模型驱动开发，或者什么测试驱动开发的，那些都弱爆了。今天我要说的，是几种看起来激动人心、华丽无比，但是可以让程序员们痛苦不堪的开发方式，特别适合那些热衷于折磨虐待程序员的项目经理和产品经理们。当然，掌握以后，偷偷用就好了，请不要来感谢我。

　　进度驱动开发（SDD，Schedule Driven Development）

　　这是在国内最为流行的开发方式，大家心照不宣，口口相交，代代相传，我只是把它写下来而已。它最华丽的地方在于，可以百分之百，甚至百分之二百地压榨程序员的劳动力。

　　需要实现哪些需求？用什么技术？用什么平台？项目采用什么流程管理？这些都不重要。重要的是——什么时候交付？

　　假使说，老大们通知，下个月的这个时候要看到产品发布，那么：

• 三周以后就要拿出完备的产品准备上线；
• 两周以后就请发布 beta 测试版本，ST、IT 之类的东西就得在那之前完成；
• 本周就必须完成编码和 UT，那么周一设计，周二、周三开发，周四、周五测试和修正问题。

　　看，项目计划多么完美。项目时间本来就该是根据 deadline 倒排的。

　　项目做什么呢？先做那些相对重要的需求，可是如果时间紧的话就只好砍需求了吧……不！你怎么能那么容易就放弃呢？你看，我的完美的计划里面没有安排周六和周日嘛，大家可以来加加班嘛，年轻的时候不得奋斗一把嘛，不用砍需求，平时的时间再压一压不就可以如期上线了？

　　在热情洋溢的动员会之后，大家开始拼命赶工了，疯狂的一周过去了，测试团队始终等不到开发团队提供的发布包，难道“又”要延期了？

　　那还用问吗？当然！

　　测试团队的时间也是可以压缩的嘛。于是煎熬的两周过去了，发布日期眼看越来越不靠谱，项目经理觉得，他需要挺身而出了——

　　敏捷思想教导我们，搞不定的时候，质量不能丢、进度更不能丢，那我们只得砍需求了。这样，我们只发布“核心功能”总行吧……

　　可是什么才是“核心功能”呢？

　　对了，我们做完了哪些？要不，做完的就算“核心功能吧”？

　　太牛了！这真是一个伟大的创举！

　　别忘了，给程序员画饼也是项目经理重要的技能——大家再努努力，进度压力也是没办法的事，发布以后大家就轻松了，有好日子过了！

　　瞧，“没有发布不了的版本”，这是真的！

　　产品发布以后大家就轻松了，有好日子过了，这也是真的！

　　文档驱动开发（DDD，Document Driven Development）

　　这种开发方式也非常华丽，对于许多领导和老大们而言，文档胜过一切。架构文档要靠 ppt，因为他们的智商和知识不足以理解满是文字的东西，而胶片，则是最接近看图说话的好东西。设计文档，要靠足够详细的 word 文档，项目经理要看到你的文档细致到肯定可以轻松地指导编码，如果你明天突然拉肚子拉到抽筋，打嗝打到卡住，喝水喝到噎着，于是不幸住院的话，文档的威力就体现出来了，他可以轻松找到你的备份，替掉你的工作。

　　软件开发全套有十项文档，从工作任务书开始，只有完成了文档，你的工作才算完成。如果你要在邮件里面，或者会议上向大家传授一点什么技巧，你可得当心了，因为接下去劈头盖脸的就是这样一句“有文档记录吗？”，仿佛有了文档就有了一切，有了文档就买了保险——至于有没有人看，嗨，谁管呢？

　　别忘了，文档的核心地位需要贯彻到底。在绩效考核的时候，最能写的人，就可以成为优秀员工。代码这种无法体现智商差异的东西可以踢一边去，只有文档才是智慧和能力的综合代表啊。

　　指标驱动开发（IDD，Indicator Driven Development）

　　这种开发方式的华丽，源于它超强的数据化和量化的能力。写代码的目的是什么？完成需求？优雅设计？用户体验？你全错了。

　　再次强调，终极目的是测试覆盖率。

　　整个软件开发流程里，你可以找得到无数的指标要求，在做每一件事情之前，必须要像默念ma0`zhu`熹语录那样回顾一遍需要达成的指标，然后再动手。

　　有一天，你发现用户体验像屎一样的产品，居然自动化测试也可以达到 95% 以上的通过率，bug 居然可以收敛到 10 个/轮测试，而且 Findbugs/CheckStyle/PMD/Source Monitor/Simian 之类的无数代码检查工具的结果页上，都齐刷刷地显示着绿条……

　　恭喜你，你成功了。

　　更重要的是，项目成功了。

　　装逼驱动开发（ZDD，Zhuangbility Driven Development）

　　这大概是几种开发方式中最华丽的一种。在设计前、写代码前，在做每一项事情之前，都要谨记装逼的重要性。对于很多不懂技术的领导来说，听起来越牛逼的软件，就越值得开发。

• 产品装逼：必须支持“云”和“大数据”，比如数据存储到服务端叫“云同步”，其实具体怎么个支持法，这不重要，关键是装逼的理念，理念！
• 设计装逼：核心就是，灵活！强大！设计，就是要体现出自己的知识和阅历，已经无比聪慧的头脑。设计的东西万万不可简单直接，这是和装逼理念严重违背的。软件的每一个组件不但能够对常见的异常情形容错，你就是删掉它几个类它一样跑得欢快。
• 代码装逼：漫山遍野的 Factory，漫山遍野的接口，最好别让我看到“new”这样的关键字；超强的解耦，好端端一个软件，不把它分成个十几二十层来实现都对不起 J2EE 的祖宗；超级无敌灵活的配置，需要啥配啥，还支持各种免重启的热插拔、热部署，产品发布的时候小于 500 个可配置的项都不好意思自说产品是自己做的。
• 评审装逼：体现自己超强无比的全面性和洞察力，请参阅我曾经写过的一些牛叉无比的评审方式中，“到处放炮型评审”。

　　总而言之，软件工程的每一个环节都需要达到足够的装逼值，才能进入下一环节。装逼是指导软件开发的重要思想。

　　其实还有很多其他华丽无比的开发方式，比如会议驱动开发（MDD），Demo 驱动开发（DDD）等等，但这几种是最常见的。如果你知道更华丽的开发方式，请告诉我。