[討論] 簡單說說

看板CodeJob (BBS架站)作者reader (讀者)時間19年前 (2005/09/01 17:17)推噓8(9推 1噓 9→)

留言19則, 10人參與討論串1/1

其實應該要說說前兩個月發案的狀況和心得，不過我實在太忙，就一直拖到現在。那一陣子發了許多案子，最後實際有用到的程式，可以說幾乎是沒有，不過有做完的，我也都照樣發錢了。當然其中狀況頗多，並不是說大家都做得不好，只是有一些現象應該要說一說，希望提供給大家一些經驗之談。我想，核心問題還是源自於台灣資訊教育所造成的錯誤概念。軟體的主要功能，在軟體使用上或許很重要，但是在軟體製作上其實是非常次要的部分，任何的資工系學生都會規劃演算法，卻只有大軟體公司才能完成精美的軟體，就是因為那些「其他」的東西，才是軟體製作的關鍵成份。而這些被台灣資訊教育界視為「其他」的部分，首要的就是錯誤處理，沒有好的錯誤處理，軟體一旦有任何問題，在沒辦法有效檢查的狀況下，往往只能捨棄重寫。所以，程式的錯誤處理一定要加強，特別是任何系統資源的取得開啟處理等等，還有指標的使用，都得要十分小心並作好檢查，這是十分基本而且重要的工夫，千萬不要以為將主流程、主功能完成就好，那樣是不會合格合用的。並且，請重視軟體細節的份量，不要認為軟體功能就這麼一點，於是以自己的能力一定可以在多少時間內完成。一個軟體的細節，往往佔了全部軟體工作的八成以上，對於細節能有多少掌握程度，正是軟體工程師的真正能力所在。千萬不要看輕細節的份量，否則再簡單的案子都會做不好，並且不要輕易採用自己不熟悉的技術，以求簡化細節，那樣只會愈弄愈糟，有一組就是這樣失敗的，很單純的案子搞到後來變成誰都無法掌握。最後，請重視細節的組織，請儘量提高其可重用性，不管是做成模組、類別、程式庫或什麼的都好，就是不要因為它是細節，就全都寫在主程式當中，這樣子程式碼的長度很容易失控的。所謂的軟體工程，其實就是對於軟體複雜性的管理，軟體的製作不是寫作業，把問題解答出來就好，軟體真正的解答是在細節上是在介面上，能夠多大程度減少他人對於軟體細節的要求，也就代表自己在軟體製作上有多大的價值。台灣的軟體業，一般對於外包合作有兩種概念，一種是從資策會或政府單位訓練出來的，透過大量的分析設計文件，規制軟體的各個製作細節，於是程式設計只是最底層的單調工作，就可以找一些低薪的程式設計師甚或外包的學生來做。另一種是從國外回來或是黑客出身的，要求的是專業合作，於是即使最資淺的程式設計助理，所負責的部分也是軟體當中的重要螺絲釘，自己要處理好自己這部分的一切事務，大家依照能力和興趣分配不等份量的軟體工作，相互協助，而沒有層層規制。這兩種思維的差異，決定程式設計工作是軟體產業的底層工作，還是軟體產業的核心工作。我和大家的合作，不是那種我把作業交給你去做，然後你把作業交回來給我打分數，及格就發錢的狀況，而是我把你願意、喜歡做的部分交給你做，有問題我可以幫忙，大家一起把事情做好。有幾組的狀況，我認為就是在這方面的認識有所偏差導致的，但這應該不是我沒有把概念傳達出去，而是太習慣被權威管束了，對於交作業打分數的模式太熟悉，於是總希望把問題遮掩過去，而不是一起面對問題、解決問題。愛玩、偷懶、有別的事在忙、心情不好、不會、寫不好什麼的，其實都沒有關係，我也都能理解，都可以想辦法，看要怎麼解決或重新分配工作都可以，就是一直拖時間不把問題攤開來講最為糟糕。這一次有兩組的狀況頗不好，讓整個案子幾乎搞砸，也影響其他部分，讓我到現在還在收拾，其間損失的信用和其他東西，遠比案子的費用都還要高出許多，但這明明是可以避免的，我發案時就做好必要時自己重寫的打算，卻拖到我連重寫的時間都沒有，那樣才糟。短期內我大概不會再做公開發包，可能要等我比較有餘裕了，再考慮發包一些我自己要用的小工具程式，就算再出問題，也比較不會影響到自己的信用。 -- ※ 編輯: reader 來自: 61.222.173.29 (09/01 18:58)

推

nosrep

59.104.98.250 09/01, , 1^F

59.104.98.250 09/01, 1^F

→

idleidle

218.168.23.186 09/01, , 2^F

218.168.23.186 09/01, 2^F

推

razor

220.139.94.162 09/01, , 3^F

220.139.94.162 09/01, 3^F