几种华丽无比的开发方式

来自：四火的唠叨

链接：http://www.raychase.net/1169（点击尾部阅读原文前往）

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

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

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

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

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

1、三周以后就要拿出完备的产品准备上线；

2、两周以后就请发布beta测试版本，ST、IT之类的东西就得在那之前完成；

3、本周就必须完成编码和UT，那么周一设计，周二、周三开发，周四、周五测试和修正问题。

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

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

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

那还用问吗？当然！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

恭喜你，你成功了。

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

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

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

1、产品装逼：必须支持“云”和“大数据”，比如数据存储到服务端叫“云同步”，其实具体怎么个支持法，这不重要，关键是装逼的理念，理念！

设计装逼：核心就是，灵活！强大！设计，就是要体现出自己的知识和阅历，已经无比聪慧的头脑。设计的东西万万不可简单直接，这是和装逼理念严重违背的。软件的每一个组件不但能够对常见的异常情形容错，你就是删掉它几个类它一样跑得欢快。

1、代码装逼：漫山遍野的Factory，漫山遍野的接口，最好别让我看到“new”这样的关键字；超强的解耦，好端端一个软件，不把它分成个十几二 十层来实现都对不起J2EE的祖宗；超级无敌灵活的配置，需要啥配啥，还支持各种免重启的热插拔、热部署，产品发布的时候小于500个可配置的项都不好意 思自说产品是自己做的。

评审装逼：体现自己超强无比的全面性和洞察力，请参阅我曾经写过的一些牛叉无比的评审方式中，“到处放炮型评审”。

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

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

相关阅读：《这个项目要多久开发完成？》

这个问题是我最常碰到的一个，也是我最难回答的一个。对这种问题最好的回答方式是用全职员工来推算天数。这非常容易，你只需要找出有多少个不重叠的功能特征，然后每个人负责一个。一旦各个功能块被分成了不能再分的任务，你计算需要多少人天，这就是你的答案。你无论如何都不可能用比这更少的时间开发完这个项目。

“一个女人生一个孩子要10个月，不论你再增加多少个女人来做这事，都不会缩短这个时间”

“只有当一个任务的完成可以分配多人，并且不需要他们之间相互交流合作的情况下能完成时，人和月才能互相替换。”

“往一个已经延迟的项目里添加程序员只会使项目进一步延迟”(因为项目中现有的人需要培训新来的人)

-《人月神话》

不幸的是，大部分人只想知道一个项目需要多少时间完成。这实际是个伪命题，因为90%软件成本的产生是发生在软件发布之后。这些费用会产生于修复bug、增加欠缺的功能、性能的改进、对新平台进行支持(安卓就是一个大债主)或重写质量差的老代码来减少技术债务。即使是项目发布前，对于如何合适的处理每一种报错情况，这也是无法预先估计全的。从某种程度上，你就是被别人问了这样一个问题：“我有一个问题，我想解决它，但我无法说清问题是什么。请问解决这个问题需要多少时间？”

...

●本文编号1909，以后想阅读这篇文章直接输入1909即可。

●本文分类“项目管理”，搜索分类名可以获得相关文章。

●输入m可以获取到文章目录

更多推荐请看《15个技术类公众微信》

涵盖：程序人生、算法与数据结构、黑客技术与网络安全、大数据技术、前端开发、Java、Python、Web开发、安卓开发、iOS开发、C/C++、.NET、Linux、数据库、运维等。传播计算机学习经验、推荐计算机优秀资源：点击前往《值得关注的15个技术类微信公众号》