從不寫程式能幹麻變成怎樣叫強者了 =.= 話說 程式寫的短跟程式跑的快並不一定畫上等號 不過 簡短的程式通常比較容易看懂 恩...前面說的都是廢話 其實我覺得前面幾位的論點都說的有道理 端看從哪各角度看問題 從成本面來看 確實高手未必比新手好用 但是如果想求公司的長期發展 有幾各高手壓陣也絕對是必要 至於說高手是不是要分享知識給其他人 我個人倒是認為 不一定需要 並不是每個人都想要當高手 只想安穩過日子的人其實佔多數 強要這些人去學新東西 只是讓大家都累 外包是一個所有從業人員都需要嚴肅面對的問題 不管今天是把案子包出去 或是接別人的案子 外包 本身就意味著 需要大量的溝通協調 而且是 水平的溝通協調 原本可以靠組織階層關係壓下去的問題 在這情況都可能小事化大 比如說 採用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