几种华丽无比开发方式

老文章了,不过看起来感触很多,放在这里警示自己。基本上我现在工作的项目输入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)等等,但这几种是最常见的。如果你知道更华丽的开发方式,请告诉我。

 

你可能感兴趣的:(开发)