虽然大部份都是在讲程设师和SE之间的事 但我想看在软体专案开发PM眼里 这里的每一句应该都会有回响.... 如果有不适合 我再自行删文 ※ [本文转录自 Tech_Job 看板] 作者: shiengchyi (脑空空视茫茫) 看板: Tech_Job 标题: [闲聊] 程式设计的格言 时间: Wed Dec 10 20:38:41 2008 译自 http://www2.biglobe.ne.jp/~oni_page/other/etc/pr03.html http://mixi.jp/view_community.pl?id=1772737 (版本2 2008/10/12更新) 译注 SE是日本软体公司里程式设计师的头子。自己不太写程式，主要工作是跟客户确认规格。 程式设计师多半自己不面对客户。 跟PM又不一样。（有什麽比较贴切的职称翻译吗？） ————— 1 每天有24小时。 所谓的「今天之内」，是指到明天早上为止。 2 程式不会照自己所想的跑。只会照所写的跑。 3 需求规格在程式写完後才会敲定。 基本规格要客户看到成品後才会决定。 详细规格要使用者用过後才会确定。 4 我对软体设计的方式导出的结论，有两种方式。 一是把软体设计得单纯到很明显不会有缺陷， 不然就是把软体设计得复杂到没有明显的缺陷。 - C.A.R.Hoare 5 程式码不要在开发现场写！ 去客户那写！ 除错不要在期限前做！ 上线後再做！ 6 画面蓝了。 7 先说「没办法」的人赢。 8 有意见的话你写 9 要杀一个程式设计师不需要刀，改三次规格就好 10 首先要先怀疑别人，被怀疑的人或许会把问题解决掉。 （注：通常会「先怀疑自己」） 11 开发没有终点。只有释出(release)。 12 无论规格多晚才能确定，结案期限永远不会变。 这是所谓的「期限守恒定理」。 13 客户总是觉得水跟追加需求是不用钱的。 14 付钱愈计较的客人愈罗唆。 15 在排定开发行程时，总是视而不见一些连小学生都会的算数。 业务部门总是一堆不知道1+1=2的人。 16 一个人挂了大家都挂了。 17 bug过了一晚可能就变成规格了。 18 好的规格找一个天才不如找三个凡人。 烂的规格找一百个凡人不如找一个天才。 19 客制软体中30%的价格用在确认规格上。 30%用在修改规格上。 30%用在找bug。 结果初期规格反映在价格上占的比例只有10%。 20 对客户来说SE是部下，程式设计师是家畜。 对SE来说客人是钱，对程式设计师来说顾客是看不见的病毒。 除了弄完程式以外，没有其他驱除的办法。 21 顾客想受SE喜欢，要自己了解到系统开发需要时间与金钱，早点确定规格。 SE想受顾客喜欢，则要让程式设计师讨厌自己。 22 很多SE跟程式设计师都暗自想着有钱有闲的话什麽系统都想自己动手做， 不过都没这种机会。 23 品质的劣化程度依规格改变的次数与规模而定。 24 业务是认为空想能够实现的梦想家。 SE则是深信任何障碍都能突破的冒险家。 程式设计师则是被梦想家和冒险家抛到漆黑海里的漂流者。 25 有才能的程式设计师第一次看到设计细节时，要先理解程式的目的。 接下来要设法让SE了解到以指定的方法、工时并无法完成这个工作。 26 程式是运气与直觉堆砌而成的奇蹟。 若不具备这两者，不可能以这样的工时实现这样的规格。 修改规格是对奇蹟吐槽的亵渎行为。 而追加修改则是相信奇蹟还会重现的无谋行动。 27 程式设计师听了「把自己当作顾客去着想！」而开始思考。 啊，像梦一样。 28 对於因为兴趣而写程式的人来说，所谓的技术是程式语言能力。 对於因为工作而写程式的人来说，所谓的技术是逻辑思考能力与人际沟通能力。 程式语言可以看着手册沟通，客户不行。 29 程式系统在交货之前会不断缩小。 先用元件定义取悦老板。 再拿经费概算要部长妥协现实的方案。 在运用会议中，课长会尝试减少自己责任范围。 在细节会议中，负责人会把范围缩到自己记得的部分。 30 SE需要持久力，程式设计师需要爆发力。 31 准时离开公司，工作会变多。 32 完美的程式需要完美的时间与金钱。 听说挥霍着美国的国家预算的NASA，也觉得时间跟钱不够。 33 详细设计要在程式码的注解里做完。 注解是唯一的自卫手段，至少要让自己看懂。 34 还有时间看程式码的话就执行他。 CPU跑得比脑细胞快。至少这时候可以休息。 35 程式的异常该称为「bug」还是「规格上的限制」是看期限还剩多久决定的。 36 所谓便服日，好像社会上把他叫做假日 (注) 日本有些公司会有所谓便服日（不用穿西装的日子），通常是星期五，但… 37 地狱持续一段时间後，充满杀气的怒吼会变多。 再持续一段时间，说话会变少但牢骚会变多，垄罩在凝重的气氛里。 再持续下去，反而会海阔天空，四周洋溢充满活力的声音。 这种状态称为「Programmer’s High」，也是倒下来的人开始出现的时候。 38 远处的火灾一定烧到这里。 39 祷告，然後跑吧。 40 程式不是用脑记的，要用身体记住。 41 明天能放假的话死了也罢。 42 外面有下雨耶，昨天开始下的吗？ 43 若不能心静不移，身体会挂。 若不让自己残忍，自己会被杀。 44 客户会说谎，业务会作梦，SE会做白日梦。 程式设计师则惦惦。（愈来愈自言自语） 45 （日文文字游戏） SE总是不负责的说「别逞强」， 业务总是无理取闹不准说「没办法」。 46 规格书就像航海图，客户则是洋流。洋流阴晴不定，航海图就变垃圾。 程式设计师必须在没有航海图的海上凭自己的力量找到大陆。 47 再唠唠叨叨下去也是要付钱的。 48 多想个10秒钟，你可以不说「嗯，这个做得到」。 49 人是无法从别人失败记取教训的动物。 砍成本、改规格、加需求、赶上线，从来没有人从众多失败中记取教训。 50 老手用来提振精神的魔法格言： 「不过比起以前来说算是…」 新人用来提起干劲的魔法格言： 「把这件工作做完的话…」他们还不知道工作是没有终点的。 51 所谓交案期限，是指开发现场从公司换到客户那里的日子。 52 程式、SE、经理不是职务。是逃不掉的责任。 53 业务是最难搞的客户。 54 能够迅速想到解法的程式设计师太多了。 他们能用一分钟想到方法，用一天去写程式。 不需要花一小时想到解法，再用一小时去写程式。 - Jon Bentley 55 漂亮的规格，可以从没有bug出现看出来。 明明烂的就是设计，为什麽是这样… 56 上线後的除错才叫做bug。 57 追加需求确定後交货期限就无法确定， 交货期限确定後追加需求就无法确定。 这称为「追加需求与交货期限的测不准原理」。 58 除三个错就会冒出一个错。 这称为bug的无穷回圈。 59 不祥的预感总会实现。 不过程式设计师不会去烦恼不祥的预感，那是SE的工作。 60 要解决地狱的办法，就是客户把钱交出来。 61 不懂电脑的操作者是发现bug的天才。而且无法重现。 62 每次开会就更改规格的客户， 他的操作手册要等到操作写好的程式後才能写出来。 63 搞不懂的时候，Currency（长整数）比Interger（整数）好用。 Variant（字串、数字都能存的万能变数）又比Currency（长整数）好用。 安全第一。 （VB程式设计师如是说） 64 啊，那是微软的规格。 65 程式设计师所不满的规格也一定会让客户不满。 （这是说程式设计师觉得难写的地方常常是SE沟通有落差） 66 程式设计师需要的技能， 包括交涉、时程管理、业务分析、提案、设计、程式语言、架构、维护、使用。 SE需要的技能则减掉程式语言、架构、维护与使用。 专案经理需要的能力则再减掉业务分析、提案与设计。 业务需要的能力再扣掉时程管理。 67 正因为健康，才能做不健康的事。 68 规、规格、是规格啦。不过有一点跟规格不太一样啦。 69 那是你说的规格。 70 开发室没有窗户，那是因为以前… 71 烂了也是因为规格。 72 SE: 真没办法。 PG: 也没注解。 （碰到不知道是谁写的程式，大家都束手无策的状态） 73 为什麽你不能两三下解决掉他啦。 因为之前两三下搞定的东西也被你两三下就否定了。 74 不会动的bug就只是普通的bug。（会动的bug则能视为规格） 75 今天好好清理bug，bug应该死光了吧。 咦？Windows也死了唷。 76 客户不会去想最坏的情况。要他面对最坏的情况，他会认为是漫天开价。 SE则会顾虑最坏的情况，准备应付最坏的情况。 程式设计师比谁都早预料到最坏的情况，而无视最坏的情况。 77 唯一不产生bug的方法，就是不写程式。 第二好的方法，就是在时程跟人员确定之後的每次改规格，都重新检视过整个专案。 78 共同责任是程式设计师的责任。 管理职？那是啥？好吃吗？我没吃过耶。 79 如果可以改行的话，想找个准时下班不叫「逃跑」的工作。 80 对职业程式设计师来说，漂亮的程式是单纯而自然的逻辑、简单而基本的指令、丰富的注 解， 也就是新手程式设计师也能马上动手改的程式。 而要写出这样的程式，需要单纯、简单、美丽的规格。 但可惜客人总是喜欢搞很复杂。 81 设计者应该是不该要求制作者制作出超过设计以上内容的吧… 82 无论是做的比规格书里的多，还是只照规格书里的写，SE都会找程式设计师的碴。 所以程式设计师只做规格书里的写的内容。 83 SE对程式设计师说的「常识」每三小时变一次。 84 自己看规格书。不能跑的是规格。 85 「没办法」是要看把一天当多少小时来算。 一天常常指的是3人日，一个月常常是指4.5人月喔。 86 工时要减掉一半的单体测试与一半的系统测试， 而交货期则要另外加上上线後的两个月。 87 能拿到钱的规格变更称为「受理项目」， 拿不到钱的规格变更则称为「SE的规格确认失误」。 程式设计师是这麽看的。 88 累了。我想睡了。可以回家吗。 （累了吧，我也累了。好累喔怎麽了。反正就是规格啦，管他的） 89 试图降低成本的话，为了配合预算，品质会下降，不过漫天开价做出来的品质也不见得好 到哪里去。 90 REDO到底该怎麽念一直搞不懂。是利斗吗、李度吗、R E D O吗，难道是 red 零 吗？ 拜 托加上注音吧。 （译注：我比较烦恼 Linux） 91 有人在程式码注解里写日记。像「今天是雨天…」，「想回家…」之类的。甚至还有「修 改日: 2003/10/10 不能同意你更多」这种注解出现。说到这个，好像也看过「吃大便」 这样的注解。 92 小学生时第一次看到电脑 国中时第一次学会怎麽用 高中与大学学会程式语言 出社会後才发现自己走错路 93 「不要让老板当业务比较好」 94 说来说去，要去研究根本不知道为什麽会动的东西为什麽不会动了，找拿破仑来也没搞头 。 ———————— ex 1 就算程式里没bug，编译器会有bug。 就算编译器没bug，OS会有bug。 就算一切都没bug，客户会决定什麽是bug。 ex 2 规格与规格书是不同的东西。 ex 3 比期限更重要的是灵感与睡眠。 ex 4 比知识与经验重要的是手册与时间。 ex 5 能动就好了，能动的话… ex 6 过了三天就是别人写的程式码。 ex 7 (大搜查线系列) 规格变动不是在会议室里发生的！是在现场发生的！ ex 8 (大搜查线系列) 异常不是在模拟测试时发生的！是上线後才会发生的！ ex 9 漂亮的设计三天或许就腻了 肮脏的设计三天就习惯了 ex 10 bug与规格是一体两面 ex 11 电脑里没有bug，bug常在人心。 ex 12 无论怎麽检查，不管怎麽确认，上线前一晚就是睡不着。(RFC968) ex 13 估价需要1%的经验与99%的直觉 ex 14 没有什麽事情比直接让找不到任何bug的程式直接上线还要可怕的了。 ex 15 ・『程式设计师』＝能将SE条理不通的说明翻译成程式码的高手 ・『SE』＝与客户讨论改写规格书、与程式设计师讨论後再改写规格书，程式出货後还要 继续改写规格书的人 ・『PM』＝每天修改自己定下的行程表的人 ・『业界老鸟』＝脸色苍白缺乏表情的人 ・『外包』＝帮不会写程式的正职员工写程式的人 ・『coding』＝复制贴上的工作 ・『单体测试』＝指开始写程式 ・『除错』＝把程式码注解掉的工作 ・『新同事』＝在火烧屁股的专案火上加油的人 ・『出货日』＝把只完成一半的系统上线的日子 ・『末班电车』＝业界平均的下班时间 ・『台风假』＝一年一度可以准时下班的业界假日 ex 16 当谁写的程式码跑出bug时，那个人大概都不在了（墨菲定理？） ex 17 最终手段 「重开机」 意外的常常都很有效 ex 18 最强藉口 以前「那是硬体的极限」 现在「那是Windows的规格」 ex 19 「程式码的可信度，不会比写的人还可信。」 =================================～共勉之～=================================== --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 140.112.90.113 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 60.244.11.180 ※ 编辑: liskenny 来自: 60.244.11.180 (12/10 20:51)