※ 引述《Aurim (Who cares?)》之銘言： : ※ 引述《jameswiki》之銘言： : : 當你自認為寫出一個超級無敵的Soultion ,別人都看不懂你在寫什麼時， : : 用了你，公司就受限於你，日後你走人，後面維護系統的人就很辛苦 : : 站在軟體公司的角度，我要的人，也不是會寫程式的人 : : 我要的是會按照公司規定，使用公司開發的元件或pattern來工作的人 : : 不會寫程式沒關係，但是SQL語法要夠強， : 那我覺得你可以把OOP跟code reusability從你徵人的要求拿掉了， : 因為街上有滿坑滿谷對這兩樣東西毫無體會的人， : 依據這兩個概念寫東西的programmer有很大機會不是你要的人。 : 什麼樣等級的公司，就徵什麼樣的人，徵來的人程度出入太大就是會碰到以下問題。 他的公司工作性質看起來的確不需要哪些人..:p reuse? 直接拉Opensource componenet可能比較快, 他做的客製化網頁reuse的部分大部分外面的framework都包好了, 剩下的都是號稱/可能/看起來可以reuse的東西, 不過那是幻覺.. : : 那種認為自己程式很強，卻又寫不出元件，可一體適用公司專案的人 : : 我反而不想用，事實證明，這些人是軟體公司的最大危機， : : 一來這種人很容易對公司不滿（我那麼強，薪水怎麼只有一點點？） : : 二來這種人覺得我強就好，不屑於把自己的經驗教授其他同事， : 看是什麼公司吧。 : 我開始寫asm/pascal/c/c++/java/c#的第一個星期內就掌握的東西， : 也是很多人不會、不知道。 : 那來分享經驗給其他同事吧？一樣用一個星期來講，不懂的人還是不懂。 : 花一個月推廣，不懂的人還是不懂。 : 我得到的經驗是什麼呢？上智下愚出入甚大。 : 有人可以三天學會C怎麼寫，用得虎虎生風，學一星期就可以用C/C++ : 從無到有兜出個直接讀寫video framebuffer的GUI framework， : 也有人學一年寫不出學校裡的C/C++小作業。 公司不要太離譜的話同事程度應該是差不多, 問題大部分是出在 很多人都覺得用不到的東西不必學, 等要用在學就是了.. OS: 經驗分享? 是要我接你業務嗎? 我還是上線看一下美女圖好了 不是每個人都對工作有熱誠的啊, 這心理層面的算計可能比能力多的多. : 所以，每次聽到有管理者說技術人員之間要多多經驗分享啊，我總認為那是神話。 : 你能把自己過去幾年裡得到的技術經驗的細節，在很短暫的時間內分享給別人嗎？ : 幾件case作作study還有可能。一些進階概念，會懂的人很快就懂，而不懂者恆不懂。 : 人跟人之間，吸收資訊的吸納量與速度是有天差地別的，還有人學了後面忘了前面。 : 就算一樣東西早就寫在wiki上分享給別人了，讓別人可以時時回去複習， : 不會的人看再多遍還是不會。 : 如果我看一眼就知道你沒辦法pick up起來，又何必浪費彼此時間做沒用的經驗分享？ 細節沒辦法, 但是整個大架構是一定可以的。 真的做一件東西做到透一定是有辦法用簡短的技術分享讓大部分的人抓個概觀。 只要抓住 1. 聽眾是誰? 預期得到的東西是什麼? 2. 訓練的目的是什麼? 預期傳達的東西是什麼? 想在一個session裡山包海那是不可能的, 適當的取材和切割可收事半功倍之效. 老話，這只能降低但沒辦法解決上面提到的心理狀態問題。 : : 結果當人一離職，他們之前寫的系統 : : 因為沒有按照公司的元件或pattern撰寫，無形中增加更多公司的維護成本 : : 程式是一種團隊工作協調的temple,不是個人表現，不強調英雄主義 : 看過邏輯很差的人寫出來的程式亂七八糟，繞很多路去做一件小事， : 又沒考慮到延伸性與可重用性，但是沒有看過很強的人寫出來的簡短程式是不可讀的， : 只有不會讀的人。這當然只是一種個人看法，就像我覺得MFC/VCL很好讀， : 甚至機械碼的反組譯結果都還可以接受，可是有人會覺得那是天書一樣。 就工作的pattern不同，這沒什麼。 電機系的寫出來的程式長的就和資工系的不大一樣，他們這樣寫不對嗎? 不一定，應該說他們的想法不同，在他們的領域可能是恰當的解決問題。 習慣是要花時間磨合的，至於有沒有必要磨合那是另一件事。 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 211.76.240.242 ※ 編輯: iincho 來自: 211.76.240.242 (02/03 14:07)