※ 引述《tinlans ( )》之铭言： : 也要反观 programmer 的素质让这些人不敢如此做的原因， : 毕竟我看过绝大多数号称是软体工程师的人， : 拿 OOPL 写出来的 code 完全降级成 object-based programming (ADT) level， : 甚至是 language 提供的 standard library 有的功能， : 也丢在一边不用， : 去自己另外搞一个来， 我好像被你骂到了，所以出来解释一下... ADT 没有什麽不好的，超过十年前我就在玩 pattern 了，但现在几乎都是在写 C, 反而是急的时候才拿 C++ 当 rapid development tool, 多数时候就是拿来 做为 ADT 工具。 standard library 也未必合用。现在我已把它再包装上一层，不再直接使用， 其中也有大半都已经配合作业系统做修改了，像是 windows 的 CRT library, 有一大半已经把 xxxx 变成 _xxxx_s, standard library 名存实亡。 其实没有为什麽，因为高阶程式设计的工具太多，会用到 C/C++ 时，往往都是 在做系统核心，愈是黑箱愈让人担心，若不是 CRT library 有 source 我都还 不敢用。 当然我知道你在说什麽，以前我也是这样骂人，不过现在我可以理解，为什麽 大家都这麽用。这还不是台湾而已，全世界都这样，你看看有几个作业系统、 几个系统软体是用 OOPL 来写的，能有 1/3 的程式码用 OOPL 就很特别了。 这情况会慢慢改变，但不会很快改变。 : 要是拿到的 open source 程式码太现代化 (用上大量 OO design patterns 等技术)， : 还好意思跟人家哭里面的结构太混乱看不懂， : 所以不会扩充不会改， 大量的 design pattern 很少会是好的程式码，因为复杂度并未有效降低，而 只是运用 pattern 来有效模拟，这往往表示分析设计工作并没有做到软体结构 重整，尽量使用最少量的 design pattern 来处理最大部分的功能才是王道。 当然软体的复杂度，在没有实作之前很难想像的，所以除非是极为高明的设计， 不然被抱怨结构混乱，实在是难以避免的。 : 宁可自己胡乱硬搞一个出来， : 造成本来不该会有的 bug 通通冒出来， : 最後的 product 问题一大堆， 这是系统安全的品质保证工作不确实，跟 OO 的关联没有想像中高。系统安全 固然可以由程式语言来协助，却主要还是 programmer 的 discipline 问题。 : 你说这种结果让公司高层怎麽敢砸钱砸时间去搞大东西。 : programmers 在学生时代就不够用功， : 练习跟实务经验都超级不足， : 这又会扯到教育问题， : 总之扯不完， : 我的意思是， : 并不能只是怪商人或公司决策有问题， : 资工人和资管人的平均素质也是一大问题。 : 就如同你说的「画设计图」， : 又有多少人能用现代化的技术画出现代的设计图来呢？ 我学电脑至今将近二十年也不会画图啊。不是说没学过，我还是眼看着许多的 软体工程方法慢慢演变的，大师们出一本书我就买一本书，也是花了好多钱， 但我从来就没有碰过程式码、注解、文字或 HTML 文件都还不能解决的系统， 要不然现在 open source 怎麽玩，没看过哪一个专案有 UML diagram 的。 而没有在用自然就渐渐地不会画了，虽然我不否认设计图很有用，但画设计图 所花费的心力不比写程式少，在没有需求的状况下，画图多半变成不写程式的 企业资管人员在做的事，但他们的工作绩效没有几家企业能有效评估，往往就 变成良心问题了。 这我就不晓得该怎麽说了，产业体系就是这样，只怕不是教育的问题而已。这 应该跟台湾以中小企业为主的经济体制比较有关吧，毕竟主要是企业用软体会 需要画图，在其他软体的开发上是比较不需要的，而台湾的大企业很少。 : 这个恶化在台湾会有终结的一天， : 毕竟太多曾经是技术的东西都被弄得不太需要技术了， : 几乎等於只要人力就可以搞定， : 迟早会被对岸取代掉， : 只是不见得是在这十年内。 对岸的技术，嗯，由於人口基数不对等，他们的菁英人数就比台湾的一般从业 人员还要多，而这些人的技术在相对上应该是远超过台湾了。 虽然说拿对方的菁英对比本地的一般从业人员并不公平，但是以薪资和能力的 角度来看，台湾人的最大优势，反而是在专业伦理上的压倒性胜利，其他的都 没什麽好比的。 换句话说，台湾就是强在满地都是「好人」工程师，不然早就被取代了。这个 道德上的优势，应该还足够撑一段时间。只是资讯教育的失败，仍然是极大的 问题，总靠着学生们出国留学来补，实在不是一个好状况。 -- ※ 编辑: semop 来自: 61.222.173.26 (01/04 17:32)