※ 引述《reader (读者)》之铭言： : : 在学校的练习与成绩是不具排他性的, 换句话说不像商场开标是属赢者通吃, : : 败者做奴的独占性. 因此, 好朋友好学生就朋党营私, 互当 code owner 与 : : code inspector 但又互留一手, 自当 moderator. : : 比较灵巧的就扮演情报收集者 (code & information collector) 当起 : : 个体户. 此时一枝独秀, 在用情用间之下, 沛然莫之能敌. 但也就造就一堆 : : 无法 maintain 的 code producer. : : 这才是软体发展的实况 ! : 嗯，难得在软体工程的讨论中，出现一个比较具有现实意义的方向。 : 没有错，软体工程和其他的管理课题一样，就某个角度而言，都是权力的斗争。 : 在很多时候，软体工程研究会出现一种不自觉的资方立场， ======== 工程一词较现代的用法是 Engineering , 这是蒸汽动力机械 Engine 出来 後的用法. 工程师就是制造与运作那台很有威力的 Engine 的人. 引擎的出 力与耗资源程度都是工程师该 "估算" 或 "实测" 出来的. 若是推到更古老 一点, 此时的工程对象就是 "土木". 水利筑坝, 防御筑墙, 遇水架桥, 遇山 开路. 这些都要 "一群人" 去做, 而且很大一部份的原因是军事上的生存需 要. 在一群人的分工运作下, producer , inspector, moderator 很自然地 就出来了. 工程师的任务就会像打战的将军那样, 要在有限资源的情况下, 估算出需要的投入(物质与人力), 并在最短的时限内完成某种要求的成果( 例如道路的运输量). 限时限物下, 工程师就可能照搬 pipleline 生产线来 组织人力与运作, 毕竟他得要估算各种方案在时限下完成. 如果是人做事从 来就没有不需要 review 与 check 的, 至少也得自己做这份查验工作. 但自己做跟分工做在时效与核实上就因使用的机制(如 pipleline)会有 所不同. 假如工程是为了争战(商战)赢利, 战败之下, 工程师开了马路造了 城墙又有何用 ? 此时工程师在估算前总不免会问为何而战, 为谁而战 ? 这 种参与群众的疑问, 小至小兵与工人都会发生. 在我们现在的体制下就称为 政治与管理问题. 工程师顾名思义在分工体制(就是阶级机制)下, 大概是当 不了将军与政治领袖的权责的. 软体工程对象是 "software", 用的就是 "组装的工程办法与估算法". 通常打战的将军会懂工程办法的作用, 譬如火炮, 防御工事与人力的数量与 素质, 而且是像中国兵书说的 "多算胜, 少算不胜", 也是很会估算的. 现 代的将军在运用资源 与 "动员" 方面, 就可能不是只会 "兵多马壮炮多" 者胜, 会来个出其不意, 攻其不备, 还会鼓舞士气摸黑夜袭. 吃了这种招式 败战队伍里的工程师当然是猛怨叹, 算马路造半天还猛检验有何屁用 ? 工程制造与军队都是免不了组织与动员人群去 "做事", 但假如 "多算 胜, 少算不胜" 这原则是成立的, 算计不到(例如想不到对手夜袭)就会是败. 因此, 工程估算与预案还是很基本的教育养成. 就打战的军队言, 动员士气与资源协调的 俄式"政委", 美式"宪兵与牧 师", 德式 "黑衫军", 日式 "天皇", 都属组织机制与管理问题, 都是阶层 式架构的阶级组织. 工程师只能就大架构下的分工做时程与资源需要估算, 并不上升到 "国家存亡" 的领袖权责. 就任何组织里的所有成员言, 在政治上, 整个群体的组织分工与运作法 都是要协助所有成员的, 包含确保必胜(有待证明的宣传语)的 "督战队" , 只是 "督战队" 是否有诚信并受到信任 ? 万一在资源欠缺下, 能否"自愿性" 的督促自己 ? 当然, 这样做已从可估算可照搬照做的 "工程" 变成了 "政 治" 管理. 世界上最讲政治的军队一定是装备差, 资源缺的穷人军队. 卖命卖力的 光天化日下干, 当然是不如灵巧的埋伏夜袭. 但夜袭也是要能先估算, 先探 与事先模拟的, 还是要有方法可以让多数人照搬照演. 工程学系毕竟不在法 商学院里, 对待人的政治性管理绝对是重要, 随时都要最先考量. 但架不了 桥, 筑不了工事, 遇到障碍就解不了, 时程内无法保证到得了, 那能不吃败 战 ? 软体工程没那麽神, 但还是要讲要有的, 毕竟这世界日夜交替, 世界的 道理不会只站到某一时某一边. 当然, 软体产业起不来, 不会是只有软体工程教育有问题 ! : 将软体工作者和他们所生产出来的程式码异化， : 透过外加的管理方法来解决问题，而不是考虑如何协助软体工作者。 : 例如原 po 的这一题，行之有年的 peer review 制度到哪里去了? : 我们如何能将程式码视为一种以行数做单位、具有平坦思维深度的产品? : 不是软体开发团队的人，要怎麽有效理解一个软体的内部逻辑? : 程式码之外的文件准备，是为了开发而做的，还是为了检视而做的? : 甚至，软体检视工作是一种可以在众多巨大变因下量化的东西吗? : 这还是浅层的问题，更深一层的问题就是权力问题了， ====== 这些疑问都是该问的. 但一个社会群体是甚麽关系呢 ? 有生物群就有分工互依, 就有人所认为的阶层阶级, 但生物链的底层断了, 上层的猛兽也会随之灭种. 拔尖的教育思惟, 让大家无法互信, 就实际的世界言, 不应该是这样的. 问题根源就是来自政治领袖的恶习, "领袖因替部众制造敌人而存在". 工程思惟的优势就是排除政治背後的猜疑, 纯就时间与资源考量. : 在这个生产体系中，对於 programmer 而言， : 他要怎麽做才是最有利的? : 例如有一些软体工程方案，会造成 code 愈难阅读对 programmer 愈有利， : 那麽这个软体机构的生产成本就会几近无限制地上昇， : 因为 programmer 不是笨蛋。 这是心理动机与政治协商的问题, 当然也是不可完全被忽视的问题. : 软体工程方案如果只从资方的角度来制作，这种情况是很容易发生的。 : 像这个 code inspection project : 如果让 programmer 认为外来的 inspector 会让他损失价值， : 那麽所有的文件和准备工作都必须专为检视而做， : code 当中难解的部分也将得不到合宜的开发者支援， : 软体检视成本将很可能高过软体开发成本，於是这个检视方案就注定失败， : 任何人都算不出一个可行的软体检视成本。 : 反之，若是 code inspection 对於 programmer 有利， : 那麽 programmer 就可能会自行利用 peer review 的方式来处理， : 甚至不花费额外的成本，仅仅是开发工作的一环， : 其实我并不认为 code inspection 是一件需要外部的 inspector 来做的事情， : 一旦出现这个情形，就表示软体开发团队已经出问题或根本没有组织好， : 不然在软体开发过程中， : 每一行程式码本来就应该是经由许多方面一次次检视的。 : 我从来就不认同那种将 coding 视作是软体开发过程中最不重要的部分的 : 那种旧式软体工程观点， : 我认为愈想降低 programmer 的重要性，就愈得不到高品质的软体。 如何把人分阶级高低与级别待遇, 是政治问题. 例如只看出生地与种族, 但软 体工程不可能涉及这种认定. 一个组织的分工组成当然是涉及其团体目标与利 益, 在市场交易制度下, 成员可以用脚选择甚至动手参与改造, 可是这很难成 为软体工程的探讨对象. --

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