DOC《PART》

PART

1 软件工程的现状 Chapter | 01.

想看这本书的怨念有多深 根据Teddy的研究,会翻阅此书,甚至愿意从自己浅浅的口袋掏钱出来忍痛买一本回家的乡民们,对于软件开发这件事,心中应该都充满了各式各样的「怨念」.以下列举最常见的. 客户把需求说得不清不楚,所以分析师顺势也把客户的需求写得不清不楚. 客户的需求一变再变,程序只好一改再改. 估计项目开发进度的方法有两种,一种是R杯,另一种是用喊价的. 没有不延迟的项目,所以只好(楼下继续……). 工作超时(22K就有一批新鲜的肝可用). 原来 PM的全名不是 Product Manager(产品经理),也不是 Project Manager(项目经理),而是 Post Man(邮差).因为 PM只会习惯性地把客户的信件转给工程师,然后再把工程师的回复信件转给客户. 别人家的 PM(产品经理)是真正的 PM,我们家的 PM是人家丢掉不要的而我们把他捡起来. 说好的测试工程师呢?(团队人手永远不足). 我不会写单元测试耶……录像中,请傻笑……(团队技术能力不够,或是成员不愿意配合). 软件里的「小强(bug)」已经泛滥到怎么打也打不完的状况. 团队成员分工但不合作. 业务曰:这个项目金额很大喔,只要改一点点地方就可以卖了. 老板曰:项目先抢下来再说. 工程师曰:等一下,不用说了,这出戏从头到尾都没有工程师说话的份. 这个列表相信继续写个两大页也绝对没问题.随着怨念越来越深,乡民们的软件开发能力变得越来越弱.有看过动画片《花田少年史》的乡民们应该都知道,人往生的时候若是有未完成的愿望,或是「怨念太深」,都是无法成佛的.所以,台湾的软件界很需要「灵异一路」这样的人才来消除软件从业人员的怨念. 请大声跟着 Teddy说: 去去,怨念走! *** 友藏内心独白:不用找什么灵异一路,找Teddy不就行了?! Chapter | 02. 老板,软件不是这样开发的 N 年前,台北捷运蓝线(板南线)通车之后,有一天Teddy和第一份工作的老板朱先生一起搭捷运(忘了去做什么好事).上车之后,Teddy和朱先生聊到捷运的方便性: Teddy:捷运通车之后节省了很多通勤时间. 朱先生:我认为节省时间还不是最重要的,而是捷运使得通勤时间变得可预测,会因此改变人们的行为模式. 当时捷运木栅线还没有遇到强烈月光而变身为「栅湖线」,否则朱先生就不会这么说了. 重点来了,速度快当然很重要,但捷运的可预测性却是改变人们生活习惯的主要因素. Teddy第一份工作所在的公司刚好在台北捷运忠孝敦化站附近,在没有捷运之前,Teddy搭公交车至少要 40~50分钟才能到达公司(还不包括等公交车时间).有时候赶时间搭出租车也不一定更快,虽然平常觉得台北的出租车多如蚂蚁,但是上班时间经常等了很久也拦不到一辆空载的出租车.所以,为了不想上班或是约会迟到,就必须要提早出门以容忍这些不可预测性.有了捷运之后,从甲地到乙地(假设都在捷运沿线)的通勤时间就变得比较可预测.因此,无论是人们买房子、找工作、开店、约会见面,就经常会挑选捷运沿线.这就是所谓的「改变人们生活习惯」. 可预测性在相当大的程度上是基于可靠性(reliability)的.以道路交通而言,高铁速度够快了吧,时速 300公里,台北到高雄 90分钟,好方便啊(也好贵)!如果今天有人发明时速 9000公里的超级高铁,从台北到高雄缩短到只要 3分钟,但是有 0.01%的出事率(就是平均搭一万次会有一次翻车的几率).除非是想要赚保险费,不然应该没人敢搭. 所以,有一阵子「栅湖线」被骂到臭头也是相同的原因.通车之后的确变得很方便,但是它的不可靠性却总是让乘客们「心里毛毛的」.搭完「栅湖线」没出事的话,内心的感受有点像是不小心中了200块有奖发票般涌起一丝小小的安慰.大众运输能成这样子,也算是「台北奇迹」了. *** 但是,做软件就不一样喔,反正软件出问题又不会「死人」.因此,这种「先研究不伤身体,再讲求疗效」的理论就不适用.做软件有自己的一套公式: (交货速度 = 收钱速度 ) >