Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

几种华丽无比的开发方式

Posted on 01/22/201306/23/2019 by 四火

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

 

进度驱动开发(SDD,Schedule Driven Development)

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

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

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

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

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

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

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

那还用问吗?当然!

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

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

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

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

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

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

瞧,“没有发布不了的版本”,这是真的!

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

 

文档驱动开发(DDD,Document Driven Development)

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

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

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

 

指标驱动开发(IDD,Indicator Driven Development)

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

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

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

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

恭喜你,你成功了。

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

 

装逼驱动开发(ZDD,Zhuangbility Driven Development)

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

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

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

 

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

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. 对几个软件开发传统观点的质疑和反驳
  2. 一个前端项目,到底要集成多少库和工具
  3. 文档那些事儿
  4. Java 多线程程序的测试
  5. We overestimate the value of coding

13 thoughts on “几种华丽无比的开发方式”

  1. yk says:
    04/03/2013 at 9:25 AM

    好端端一个软件,不把它分成个十几二十层来实现都对不起 J2EE 的祖宗;笑喷了。

    Reply
  2. yyy says:
    03/24/2013 at 12:52 PM

    写的真好,很有范儿,主要是这个网站做的彪子

    Reply
  3. Anonymous says:
    03/21/2013 at 9:06 AM

    这就是经历
    顶~~

    Reply
  4. supergaosong says:
    03/08/2013 at 11:03 AM

    伴隨著 SDD 開發方式,常常還有一種終極解決方案作為配合:
    給你多加一倍人手吧,這樣工期就可以縮短一半了。

    Reply
  5. islet8 says:
    03/06/2013 at 11:13 AM

    MDD 太不能唬人了,得叫 TMDD,team-meeting driven development

    Reply
  6. xfly says:
    03/06/2013 at 9:54 AM

    不错!能够让我们从另一个角度来反思的文章

    Reply
  7. devan5 says:
    03/05/2013 at 9:31 PM

     
    目前仅有感受 SDD
    看来是鄙人阅历不够啊 嘿嘿
     

    Reply
  8. fuadam1982 says:
    03/05/2013 at 8:55 AM

    装逼开发驱动很容易被学习新知识的热情所掩盖

    Reply
  9. 书痕 says:
    02/05/2013 at 9:25 AM

    对于小公司,有一种完全老板驱动式的也挺愁人

    Reply
  10. Anonymous says:
    01/27/2013 at 12:24 AM

    很有意思的文章

    Reply
  11. Anonymous says:
    01/24/2013 at 4:20 PM

    动不动就装逼,指标说出来能吓死人

    Reply
  12. 甄码农 says:
    01/23/2013 at 1:31 PM

    我们在装逼。

    Reply
  13. topcat says:
    01/23/2013 at 11:39 AM

    感同身受

    Reply

Leave a Reply to 书痕 Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Spark 互联网 亚马逊 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 眼界 程序员 管理 系统设计 缓存 编程范型 美股 英语 西雅图 设计 问题 面向对象 面试

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Machine Learning and Artificial Intelligence (6)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • panshenlian.com on 初涉 ML Workflow 系统:Kubeflow Pipelines、Flyte 和 Metaflow
  • panzhixiang on 关于近期求职的近况和思考
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
  • Anonymous on 我裸辞了
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme
Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接