转自PTT2 8A ---------------------------------------------------------------------- 道出许多程式设计师的心声:P 原文: http://0rz.tw/0e2sm Posted by Mr. Friday Mr. Monday写了一篇你在大学里应该学会的三件事，这篇以此类推，就叫做「程式设计师 不可不注意的五件事」吧！这篇文章小小的汇集了Mr. Friday从大学以来参与程式设计开 发的心得，虽然不敢说自己程式功力多麽高深，不过抛砖引玉，希望这篇文章可以引来更 多有益的讨论，对於新接触程式设计这块领域的新鲜人来说，应该可以避掉很多前人走错 、不应再重蹈覆辙的错误路子。 1. 文件标示不明，注解不清：这大概是所有程式设计师在看其他人所写的程式时, 最痛 苦的一件事了。在一间公司里，不管你有多麽资深，有时候总免不了得先看懂别人在写什 麽程式，好接手写下去（或合作开发应用程式）。曾经听学长说过, 在大型专案里, 自己 重新写永远都比改别人程式还快──因为有的人写得实在是太乱啦！！！看不懂！这就好 比今天有个人用火星文写了一串密密麻麻的文字，又没留下小抄着明说哪一段文字是在写 什麽，之後老板要你接手继续写下去，天呀，光是搞懂他标题在写什麽就已经花去大部分 的时间了，要准时交出程式？怎麽可能！有的人还夸张到连自己以前写什麽都看不懂呢！ 解决之道：在写程式时，每个人记得要顺手留下注解，不见得要长篇大论，但至少要注明 大概的用途，能说明演算法内容者更佳。有的人可能在撰写时可能会留下一些测试用程式 码，写完以後就删得乾乾净净。如果你没有写doc的习惯，至少把这些测试码注解起来就 好了，千万别删！要知道你的随手小笔记，可能是未来接手者的救命丹呢。 2. Coding Style不统一：如果你曾参与过程式整合测试的流程，你可能会发现，同样是 写程式，不同的教育背景与习惯竟会导致这麽程式设计style上的不同，有的人习惯 javascript这种直叙式的语言，有的人则习惯Java这种以物件导向（Object Oriented Programming：简称OOP）为架构，而且你很可能会在他桌上找到一本厚厚的Design Patterns原文书。这些语言以及相对应的设计习惯，并没有谁对谁错，就像钢筋混凝土与 木材都一样可以用来盖房子，只要在对的环境用对材料，就可以撑上个几十年。但是对同 一个开发团队而言，不同的设计习惯可能会带来灾难，就好像一栋房子上面是用钢筋水泥 ，可是地基却是用木头做的，想也知道会出现问题──Mr. Friday曾经从教科书上看来一 个例子，因年代久远，Mr. Friday记忆中的可能跟事实有点出入，不过大意是这样：有间 欧洲银行花大钱委托国外软体商开发一套金融交易系统。这个国外软体商开发好几个月後 ，把成品交给义大利银行总部使用，结果总部人员一打开程式，竟然发生大当机。银行总 部与软体商花了好大一番功夫，才找到问题症结点──日期格式不一样！比如说2004年7 月1日，有的地方会写成04/07/01，有的地方是写07/01/04，当然更有的地方是写 01/07/04……而正好软体开发商与银行用的日期格式是完全不同的，造成系统日期判定错 误，最後结果竟然是得重新开发一次！不同的日期格式就能够造成如此灾难了，同一个开 发团队里面、不同的coding style造成的灾情亦可想而知。 解决之道：团队里面难免会遇到不同背景的程式设计师，除非你很确定所有的参与者都有 一致的开发习惯，否则这时最好能先由一个领导者确立程式的整体结构，并参与API介面 的制定，甚至是变数的取名与传递方式。一些常见的公用变数与程式的使用方法最好记载 在一份公开文件或wiki中，让工程师共同参考。如果只有少数几个人的程式设计习惯与其 他人不同，建议是先让他们从修改一些简单的程式码着手，先让他们逐步习惯其他人的设 计方式，过一段时间後再投入主力程式的开发。 3. 绝对不要轻易相信One Size Fits All：网页程式设计师应该特别明了这一点，因为他 们绝大多数的人都历经过「IE正常显示，可是在Firefox打开就乱掉了；好不容易Firefox 上调到正常，结果IE上的画面变成一团糟」的痛苦。各家浏览器支援的标准不同（当然很 多人会告你是IE不守规矩）已经不是新闻，不过这种事在其他的程式设计领域也是常常遇 到：不同OS、不同的通讯标准、甚至是如前述所说不同的日期表示方式。什麽？你说「 Java不就是一个跨平台的最好标准吗？用Java开发的程式可以在各种不同平台上顺利执行 啊！」噢噢，可别忘记那是指「在同一个版本的JVM上」喔！Mr. Friday就曾经遇过某个 用JDK 1.4开发的程式，到了新版1.5.0（不知道为什麽Sun要称1.5.0版为”5.0版”…） 上compile後却跳出一个错误：某个JDK所提供的函式已经depreciated（过期，不再支援 ）了！更别说有的人搞不好用的不是Sun（比如说BEA）所提供的JVM哩，谁知道会不会有 什麽Bug在里面！ 解决之道：千万不要在未经大量测试前宣称自己是跨平台还是跨所有浏览器的程式，比较 尽责的做法是像MySQL官方网页那样，列出所有程式版本与平台，并注明哪些版本在哪个 平台上历经大量测试、问题较少，哪些版本是有支援，但未经大量测试。如果你比较懒， 至少也应注明自己的开发与测试平台是哪些！ 4. 绝对不要把程式进度当作可以量化的指标，除非你不打算过着人类正常吃喝拉撒睡的 生活：写程式与其他工作不一样之处在於，它永远都是新的挑战。科技日新月异，程式设 计师面对的挑战永远是在新的平台、新的通讯协定、新的规格（甚至是新的程式语言）上 设计新的程式。即使你以前写过类似功能的程式，你也不可能确保以前的设计方式在新的 平台上会不会出问题。如果你信心满满告诉老板说明天早上程式一定会写完，换来的代价 很可能是公主彻夜未眠还写不完！ 解决之道：你可以根据你过去的纪录推知类似的程式功能你大概会花多久完成，但是绝对 要预留「如果遇到很难解决的问题…」的後路。记得在学校时代上系统设计分析方法时， 教授曾说：「据统计，只有40%的专案能够如期完成。」Mr. Friday虽然不知道教授口中 的统计数字从何而来，但是根据Mr. Friday身边所有人的经验，绝大多数的专案都难以按 时完成。对一个身负「如期完成」重任的专案经理来说，宁可在早期以加班或增加人手的 方式把程式维持在一定进度，如果还是无法负荷，也可以试着修改专案目标，免得一拖再 拖，到了开发後期根本是无止尽的拖延。 5. 缺乏远见：已经有很多书告诉你Design Patterns、UML、Class Diagram还是Normal Form这些帮助规划程式架构的工具有多重要，可是这些书却常常忘记提醒大家「有远见」 是多麽的重要。永远不要小看自己所写的程式，也许这个程式未来会变成大家都流行的基 本配备也说不定。60年代的程式设计师也没想到只取後两码数字的习惯，会在40年後造成 Y2K问题。同样地，一个简单但却不够弹性（scalability：这个字没有恰当的中文翻译， 多数人翻成扩充性，意思为能支援的标准很多、经得起各种情境的测试）的设计，也可能 会在程式完成後产生意想不到的错误。 解决之道：就算写的程式再容易，也千万不要忽略在scalability方面的考量。与其在设 计时多花个几小时思考，也胜过程式写完後才发现「糟了！得重写了！」 每个人心中都有一个衡量「好的程式设计师」的一把尺，也许标准人人不同，但如果缺了 这五项该注意的事，这个人肯定难以成为出类拔萃的程式设计师。谨以此心得，纪念过去 那些没有睡眠的夜晚、奉献在无用程式的心力上T__T --

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