※ 引述《Aurim (Who cares?)》之铭言： : 学艺多久不是重点，重点是客户完全是未开化的软体蛮人，就算对方是派学有专精 : 的IT人员来负责初步接洽，但是他们的上级多半不是在这行很有sense的人，愈是 : 在主管职待久的、愈是有内部权威的、记性愈差的，愈倾向朝令夕改，今天不记得 : 昨天决定了什麽，明天又不记得今天决定了什麽，一个月反覆改变意见十次也不奇 : 怪。就不用说尊重专业了：什麽事情是Java或Windows上不能做到的，他们不会在 : 乎；什麽事情是某个平台上很难做到的，他们也不在乎。 : : 高高在上久了的人，多半不会面对这种朝令夕改的窘境，反而比较像是让他人面对 : 朝令夕改窘境的人。就像数学家证明「x^n+y^n=z^n，当n,x,y,z为正整数，在n>2 : 时无解」证明了三百年，一个小小的额外要求耗费的工程可能超乎外行人的想像。 : 政府机关的 e 化, 一直就是充满了这类人的问题. 让软体业长不大的, 其实不是需求规格改来改去, 这只是会降低卖方的利润, 但多数状况不致於致命, 很少听说软体验收不过, 软体公司破产的. 反而像 是恶性竞争的手段, 竞争者会跟买方说一些难听的话鼓动买方去更改功能. 功能常改, 需求不断, 总是造成很多的商机, 但是都做不好, 所以金额就低, 是一种需求够多又饿不死人, 但要壮大组成强有力的压倒性竞争力又不行的 状态. 举个例, 就所知的状况也持续争议了近 20 年. 大学里究竟是使用一个 单一的集中式资料(讯)库好, 还是分散式的资料库 ? 学校就是老师, 学生. 教师的开课, 学生的课程成绩归教务处. 导师活动辅导, 学生生活住宿则归 学生事务处. 但教师与职工的人事薪资资料则全在人事室, 早期电脑化, 有 业务就有人就有设备经费, 就照原来的人工系统, 各自建立各自掌管自己的 资料库. 每次一有涉及的异动就相互埋怨一方没通知另一方, 老是资讯迟迟 跟不上. 可是一谈起集中这些分散的资料库归一方管理又如何 ? 连电算中心 都不肯干, 因为业务单位会趁机把工作丢过来, 但不会把人与经费移过来, 各处也就抱着资料各拥山头, 永远上演无法及时更新的老故事, 永远抱怨汇 出更新的资料不全, 费时烦人. 但也永远拿经费发包出去一些软体的案子, 变相雇长工跑腿替单位做杂事, 不然就是雇一些约聘低薪的资讯人员干手工 活. 那麽能不能解决这种长痛问题 ? 譬如让电算中心做个收存各分散式资料 库资料的汇整备援集中系统又如何 ? 好歹解决安全备援也能提供最新的更新 资料通知. 这个建议至少说了十年, 十年前可能太先进, 但现在也不怎麽样 了, 可是上面的主管永远就会听见下面的反对声音. 毕竟 e 化一做, 很多美 好胡闹的事会消失, 大家心中都不肯, 所以就长成这样, 僵在那. 在上的大官都得靠在下的小职员做事, 小职员对 e 化是充满了恐惧, 聘 人也越来越临时化, 也越派遣化, 起薪不增反降, 後果就这些大官只能越来 越健忘, 受到压力都是朝令夕改, 就像马路挖沟挖了埋, 铺了又立即挖, 忙 得不亦乐乎, 个个都饿不死也长不大. 这种小额的公务机关软体外包就像鸦 片, 养一堆小公司带几个 PG , 活得辛苦与快乐(又有软体外包了)也都不知 道为甚麽会辛苦与快乐. 制造工业化与资讯自动化的威胁, 其实都是外来的创意打破既有的垄断 性利益平衡, 都是入侵式的破坏让既得性利益自行灭亡. 带有隐性失业的农 业, 内耗性的政府补贴式小额工程都有这种长不大无从竞争的特色. 在软体公司都长不大时, 说公务经费机关的软体外包可能才是鸦片的根源, 可能是太过残忍, 但这可能是真正的问题根源. : 在这种环境待久的人会明白，针对这种情况，应对之道不是要求客户尽快定案所有 : 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来实作出新功能来？ : 现在也是有人强调资工系的大一就要教 Agile Method , 任何管用的技术方法当然 都要引进, 不然外国的强盗小偷冲进来, 还可能不知道人家端了啥道具, 为何就是 顶不住 ? : 不断重复打造大同小异的轮子，你捉摸出万流归宗的道理了吗？程式中会出现的 : design pattern就只有那些，business process pattern就只有那些。可是道行 : 粗浅的程式员还是得为了这些大同小异的东西天天在那边新增删改一堆code，时 : 间就是金钱，我们虽然很难管理野蛮客户的需求变更，但是我们还是可以想办法 : 把程式员需要的劳动与生出的bug数降到最低。 : : 从一个系统的各部分可以切割出变动性大小不一的部分。除了面对未开化客户的 : 反覆变动需求，程式员也可能要面对猪头SA/SD/主管的变更要求，像是案子做到 : 一半才要变database table schema，要求你变动一些function/method/class/ : interface name，怎样把变更时间降到最少，可能制造的bug降到最少？这种事情 : ，往往不是在IDE或文字编辑器里头用个Replace in files的功能替换一下字句就 : 解决了的。各家IDE近来新增的refactoring功能虽然减轻了人们面对类似要求时 : 的负担，但是更核心的问题还是少有人触及：当你一定要面对这类变动时，你能 : 够有什麽样的方法，以不变应万变的，以最少代价去应付这类问题？ : 台湾以前(III SEED Project)也猛讲用 Automatic Code Generator 的技术来对付 变动性的需求, 只要泡泡图重新拉拉线, 规格叙述改写几行, 新的程式就自动产生 了. 可是当年的最大问题就是: 需求都定义不明, 规格也说不清, 如何写出叙述明 确的规格 ? 而方向上就偏往更难的 AI 钻, 就钻成个不了了之. 新的方法没有这麽高段, 也不这麽强调不用写程式就拉拉线就可以快乐的变出程 式来. 即使有这种东东也不符合生态的变化, 碰上既得利益的 PG 非打死她不可. 现在看见的方法就是融合特定领域的应用, 派熟悉现有产品的一群顾问工程师与 客户直接沟通, 列出配合客户需求的项目, 调整可设定的参数表让整套软体系统 调适成客户要的系统. 在整套系统的架构设计就能有弹性与可重组性. PG 不会消 失, 但人家的 Architect 在概念与思惟上让你比不过, PG 不爱面对客户就让受 过训的客户顾问与客户使用者一一恳谈, 列出需求所需的参数表, 在整个竞争上 不得罪客户的既得利益, 但就把跟不上的同行给挤掉了. 无敌的 Automatic Code Generator 是无敌的变形金刚坦克的思惟, 可是一旦被有资本经费的人掌控了, 可能连造他出来的 PG 都被自己的工具给逼死了, 所以後者想法根本就很难成功. 同样是面对变动的需求跟规格, 但突破式的创意方法必然是前进的力量大於阻力, 尤其是竞争者陷入迷惑状况时, 特别有奇袭的功效. : 第三种需要变更程式的情形，就是既有的code出了bug。当我写一个新功能，我 : 也有可能同时引入了一个以上的bug。我要怎样方便测试者与客户在出问题时， : 更快找出问题出处，更快解决问题，不用等到我把新引入的bug修掉？人们写程 : 式时，如果能时时回到这些问题上反覆思索，必然能有所得，让自己把事情做得 : 更好、更快。在动手写code之前先把这些事情想好，日後所要花费的额外变动功 : 夫就会减少。 : : 改变他人，不如改变自己。你不肯接受变更，别人肯，你的生意可能就飞了。 : 软体工程的某些新方法如果发生一堆人不觉得有甚麽, 而某些人又觉得是有甚麽, 又能应用出一些名堂时, 就要特别的留意, 因为一个上下差距就拉开了竞争力. Aurim 提到的在新功能增添时可能造成不匹配的 BUG , 如果一方有其方法, 使得 发生的机率低, 其竞争力之强就是可预期的. --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 140.115.1.146 ※ 编辑: ggg12345 来自: 140.115.1.146 (10/10 16:36)