※ 引述《tinlans ( )》之铭言： : 愈是黑箱愈让人担心这件事， : 是目前接触程式设计越久的人越应该突破的心理障碍， : 我也算是非常早期接触程式设计的人， : 所以我也能体会这种心态， : 反正就是什麽都要看得非常透彻才会安心， : 最好是 assembly code 会长怎样都一清二楚， : 但现在的软体规模已经成长到当年无法想像的地步， : 所以我选择的是突破这种心理障碍， : 否则永远都会让自己停留在过去。 这应该说是程式库的 reliability 问题，这种事是一朝被蛇咬，十年 怕草绳的。 所以系统核心总是用 C 比较多，不只是自己安心，大家也安心。至於 其他部分，该用什麽就用什麽，我是很习惯多种程式语言和软体共存 合作组织成一个较大的系统的。 这样子就好了，把系统拆成不同层次，用不同方式对待，不管是那是 心理问题还是实质问题都能解决。 : OOPL 写出的的 OS 要真的能上去还有得等， : 但以市场角度来看这可能是唯一能寄予厚望的， : 不过实现的时间点应该不会在你我还没进棺材的时候。 这好像也太悲观了... ^^||| : 盲目的使用 OO design patterns， : 和大量使用 OO design patterns 其实是不同的两回事， : 大量使用必有大量使用的理由存在， : 其中之一就是需求变化量大， : 所以预留了相当大的可变空间。 : 一个小有规模的软体系统必有其历史性， : 存在少许的 OO design patterns 便能处理大部分功能的软体系统， : 就我个人经验来说这通常是一个刚完成不久， : 未经各种历练的新生儿。 这个嘛，我持保留意见。 基本上我认为会使用大量 design patterns, 往往是没有适当地使用 system pattern (称作 architectural patterns 比较正式一点) 的 关系。 不管这些 system patterns 是以什麽形式出现，它们经常都可以有效 「集束」一些散落的系统流程，而不是在软体的各个部分运用小型的 design patterns. 当然这样子会损失一些效能，不能大量运用 template 而是依靠系统 元件之间的介面或内部通讯协定来完成，但就像为何要有资料库系统 一样，与其在软体的各个部分做细致的资料处理，使用着各种各样的 复杂资料结构，往往不如整合成为一个独立的资料处理元件，不只是 管省开发时间，也可做整体性的效能最佳化，未必就损失多少效能。 例如像 component-based programming (CBP), application framework (AF), n-tier software architecture, service orient architecture (SOA) 都曾风光一时，沉寂一时的 actor model 在学术界重新兴起，都 代表着核心系统结构的魅力，它们都可视为一组有效的 system patterns 所构成的特定软体结构，能有效减低软体开发时在设计上的负担。 OO 支持者，特别是 design pattern 的支持者，往往都认为那些结构 都只能解决特定问题，而忽视了为什麽一个特定的结构就能在一定的 范围内如此有效，所谓的 pattern language 并不是只能在 'design' 阶段可以应用，在系统架构上可能更具威力。 : 另外， : 我不清楚你所谓「模拟」的意思是什麽， : 一般而言， : OO design patterns 与「模拟」二字应无关联性。 许多商用系统的设计，其实就是原本的人工商业流程或旧系统工作流程的 模拟和取代，只是采用 OO design patterns 来做较高层次的抽象化。 这样没什麽不对，但其实可以再用纯粹的软体架构或电脑科学观点做一次 重整，例如考虑 middle-ware 或 message system 的引入，用一个好的 系统结构，将系统切分成许多块小型的相同物件，再各别做细部的设计。 在许多情况下，这可以发挥相当强的 divide and conquer 功效，弹性上 也不会损失，只有少许的效能损耗。 : : 这是系统安全的品质保证工作不确实，跟 OO 的关联没有想像中高。系统安全 : : 固然可以由程式语言来协助，却主要还是 programmer 的 discipline 问题。 : 实务上是有相当大的关联性存在， : 这类工作不但负担会因为 OO 化的落实而大幅减少， : 施工时造就的 debug 时间成本也会大幅降低， : 简单一句话就是「减少因人为疏失而增加的时间成本」， : 如同前面所说的， : compiler 产生出来的 code， : 总是会比 programmer 手工做得稳定。 : 即使是落实各种软工中与 OO 和程式设计没有直接关联的理论， : 这些由各 programmer 造就的时间损失依然存在， : 否则的话， : OOPL 从最初就不会被创造。 我倒是认为，许多人都太为看重软体工具所能提供的效益，而忽视了人们自身 所能够建构的规范。 例如每一个函数所传入的资料都检查、每一个呼叫所传回的值也检查过，难道 就是那麽不可承受的负担吗? 但几乎没有人这麽做，就光是想着依靠各种办法 来偷懒，甚至把责任转嫁到测试人员身上。 只要有好好做这麽一件事，那种要花大量时间找出来的 bug 就会少之又少。 又如绝不允许自己做 copy & paste, 碰到任何相似的程式码都要再思考过， 若能有这样的自我要求，再加上电脑科学的基础，不管用什麽程式语言，都能 做出相当好的程式码。 对於现在经常要使用多种程式语言来工作的 programmer 来说，把程式设计的 品质寄托在特定程式语言上，实在不是一件好事。 : 其实我要说的是， : 因为只要拉拉元件照 example 写 code 之类的工作， : 已经渐渐有人在研发只要写写 spec 就能 generate 出 2/3 成品的工具了， : 对岸的非菁英人才甚至是教育程度没上大学的， : 将来都可能从事这方面的工作， : 所以到时候这些 coder 的水准会正式的降为作业员， : 而台湾做这方面工作的人可能将会难以生存。 这东西在二十年前就有了，所谓的 4GL, iCASE 都是这类想法的产物，而且 多数都已实作出来了，但程式设计工作并没有消失，只有愈来愈多。 所谓的 coder 难以生存的论点，也是在二十年前就有了，但结果不幸的是， coder 的薪水是愈来愈好了，反而是 programmer 的生存愈来愈艰难。 世界上就是有着只会 VB 拿五万薪水，能力中上的 C/C++ programmer 只拿 三万多薪水的事（当然这不是通例，但也有一定的普遍性） 事情很简单，因为专业软体开发已经全球化了，而台湾是全球化的受害者， 能力强的不出国就只能写 open source 软体，而不是开软体公司赚大钱，而 软体应用服务却十分在地化，大量简易的客制化，特别是企业的网站和小型 资讯管理系统的需求仍然十分强劲，偏偏这是 programmer 不想做的东西， 里头有太多非技术性的成份。 在可预见的未来，软体服务仍然会比软体产品的需求更高，能做软体产品的 高手们仍会继续制作软体开发工具和 open source 软体，加强软体服务的 技术支援。 而能力中等的 programmer 反而更要在乎中国和印度的冲击。毕竟在地化的 小型客制化服务是很难全球化的，但专业产品制作及大型客制化服务却容易 全球化，前者有无以数计在邓小平 1984 年提出的「计算机的普及要从娃娃 抓起」口号之下，经过二十年逐渐培养出来的技术人才，後者有印度从美国 找来软体工程大师们倾力打造的巨型软体代工体制在世界攻城掠地。 所以最後到底是台湾的 programmer 还是 coder 死得比较惨，还未可知呢。 --

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