※ 引述《ggg12345 (ggg)》之铭言： : 外包式订制型软体用上馆子套进去还是对不拢, 从现在台湾流行的需求规格到 : 验收, 怎麽说都像古代木工匠盖房子的做法, 是雇长工做工程的形式, 完全看 : 大户人家给的银子, 一段一段的接着做, 找不到好的木工师父就停摆. 鲁班木 : 工师父是要学艺很久才能出师的. 那里像台式洋学堂, PG 是靠自修自练. 学艺多久不是重点，重点是客户完全是未开化的软体蛮人，就算对方是派学有专精 的IT人员来负责初步接洽，但是他们的上级多半不是在这行很有sense的人，愈是 在主管职待久的、愈是有内部权威的、记性愈差的，愈倾向朝令夕改，今天不记得 昨天决定了什麽，明天又不记得今天决定了什麽，一个月反覆改变意见十次也不奇 怪。就不用说尊重专业了：什麽事情是Java或Windows上不能做到的，他们不会在 乎；什麽事情是某个平台上很难做到的，他们也不在乎。 高高在上久了的人，多半不会面对这种朝令夕改的窘境，反而比较像是让他人面对 朝令夕改窘境的人。就像数学家证明「x^n+y^n=z^n，当n,x,y,z为正整数，在n>2 时无解」证明了三百年，一个小小的额外要求耗费的工程可能超乎外行人的想像。 在这种环境待久的人会明白，针对这种情况，应对之道不是要求客户尽快定案所有 feature request，而是把自己的系统设计得灵活有弹性，不管怎麽改都很好改， 可以迅速改好、新增删改任何功能。 怎样以最小程式、资料变动去应付最大需求变化，agile programming, agile database management, 一堆agile相关技巧都是用来应付这种鸟事的。台湾的学校 不知道要到何年何月才会教这种东西。 Workflow的概念让资讯系统处理工作流程的变更成了更容易的事情，我们能不能把 同样概念应用到code flow, data flow？从流程图可以生成BPEL，有些BPEL4J engine 可以从BPEL生出Java code来。.NET也有CodeDOM能将表示语意的expression tree 自动双向转换成C#/VB.NET/IL code，程式功能的修改可不可以简化成只是重新画 几个图，就尽可能重复使用旧code来实作出新功能来？ 不断重复打造大同小异的轮子，你捉摸出万流归宗的道理了吗？程式中会出现的 design pattern就只有那些，business process pattern就只有那些。可是道行 粗浅的程式员还是得为了这些大同小异的东西天天在那边新增删改一堆code，时 间就是金钱，我们虽然很难管理野蛮客户的需求变更，但是我们还是可以想办法 把程式员需要的劳动与生出的bug数降到最低。 从一个系统的各部分可以切割出变动性大小不一的部分。除了面对未开化客户的 反覆变动需求，程式员也可能要面对猪头SA/SD/主管的变更要求，像是案子做到 一半才要变database table schema，要求你变动一些function/method/class/ interface name，怎样把变更时间降到最少，可能制造的bug降到最少？这种事情 ，往往不是在IDE或文字编辑器里头用个Replace in files的功能替换一下字句就 解决了的。各家IDE近来新增的refactoring功能虽然减轻了人们面对类似要求时 的负担，但是更核心的问题还是少有人触及：当你一定要面对这类变动时，你能 够有什麽样的方法，以不变应万变的，以最少代价去应付这类问题？ 第三种需要变更程式的情形，就是既有的code出了bug。当我写一个新功能，我 也有可能同时引入了一个以上的bug。我要怎样方便测试者与客户在出问题时， 更快找出问题出处，更快解决问题，不用等到我把新引入的bug修掉？人们写程 式时，如果能时时回到这些问题上反覆思索，必然能有所得，让自己把事情做得 更好、更快。在动手写code之前先把这些事情想好，日後所要花费的额外变动功 夫就会减少。 改变他人，不如改变自己。你不肯接受变更，别人肯，你的生意可能就飞了。 --

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