从不写程式能干麻变成怎样叫强者了 =.= 话说 程式写的短跟程式跑的快并不一定画上等号 不过 简短的程式通常比较容易看懂 恩...前面说的都是废话 其实我觉得前面几位的论点都说的有道理 端看从哪各角度看问题 从成本面来看 确实高手未必比新手好用 但是如果想求公司的长期发展 有几各高手压阵也绝对是必要 至於说高手是不是要分享知识给其他人 我个人倒是认为 不一定需要 并不是每个人都想要当高手 只想安稳过日子的人其实占多数 强要这些人去学新东西 只是让大家都累 外包是一个所有从业人员都需要严肃面对的问题 不管今天是把案子包出去 或是接别人的案子 外包 本身就意味着 需要大量的沟通协调 而且是 水平的沟通协调 原本可以靠组织阶层关系压下去的问题 在这情况都可能小事化大 比如说 采用java或是ruby, 同一家公司内, 找有力的高层出来说话就解决了 再外包的情况最常出现的是, A功能用java, B功能用ruby, 结果整各不能用 更惨的是, 等到两边分别验收之後, 才发现加起来有问题 结果就是三方互相指责, 买方付一半钱但是东西不WORK 卖方出全部力但是只收到一半钱, 全部人都有损失 前面有人说 光有商业逻辑的公司是撑不久的 这句话真是说的好 就是因为这世界上有人或公司只有商业逻辑 却没办法把商业逻辑转为现实 才会需要工程师这各职位 所以在现实中 不管什麽处在什麽等级 还是会需要理解你要写的程式所用的商业逻辑 一般把这部份叫做domain knowledge 程式的好或坏很多时候是没有办法单独断定的 通常是要把domain knowledge套进来做判断 高手并不会是指 只能用一种方法达到目的的人 通常是说 可以有很多手段达到目的, 然後根据情况选择适当的手段 我想说的是 现实中并没有一个单一的指标来说明程式写的好或坏 写的很简短是各好习惯 但是不代表程式一定跑的比写很长的快 写出来的程式跑的很快, 也不一定就能算是好程式 同样的 写出很短程式 或是coding速度很快 跟能力是有正相关 但并不是最短或最快就一定是 [最好] 或 [最强] 用单一框架来想事情是很危险的 ※ 引述《semop (semop)》之铭言： : ※ 引述《jameswiki》之铭言： : : 当我需要一个简单的PHP网页结合mail server及电子公文做总收发系统, : : 也有很多高手来应徵, : : 但是,最後决策,我不用这些人,为什麽? : : 他们开价太高是主因,要求时程1个月太长是次因, : : 我最後包给大陆工程师写,2周写完,5万元台弊搞定, : : 电子公文及总收发流程由我来教他们,案子写完我帮公司卖了100万. : : 而这些事务,若我徵聘高级工程师来写,算4个人好了 : : 一个人一个月给5万,就算1个月写完,我也得花20万 : : 写不完呢? 准备付违约金给客户了 : : 若我自己跳下去写呢? 一个人少说也要写2个月,公司其他事都不用管了.. : : 这也不行 : : 加上这些台湾的工程师,若加上个人英雄主义,故意写一些很简短别人看不懂的code : : ,那未来公司的维护成本就更多..何必呢? : 你只是没看过真正的强者。 : 那种别人做一个月，但强者出手只要几个小时，连注解都写得清清楚楚的事情，没有 : 见过的话者很难相信的，但实际上就是有这种事。 : 这种资料转换的工作，有概念的公司或个人早就会做好资料简易存取的介面，用到时 : 只要网页设计完成，工作也差不多就跟着完成，不过是助理工程师一个下午的进度。 : 那种什麽东西都要写 SQL 的，就是我所谓不知道怎麽开发系统只会靠劳力来做的， : 若是一家软体公司做一个系统，单纯从资料库拿资料或写入都要人工来写 SQL, 还是 : 早早离开比较好。 : 高水准的程式设计并不是只存在於艰深的演算法或技术开发，生产力的提昇也是重要 : 一环，不要以为商用系统就没有研发，眼中只有商业流程的公司是没有竞争力的。 -- 天有情 天亦老 春有意 春须瘦 云无心 云也生愁 http://parus.idv.tw/ --

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