over 3 years ago

文章大綱是有一個人問「在學校裡寫程式」跟「在企業裡寫程式」的差異,下面有四個人的回答我覺得都很值得參考,雖然我本身不是在業界工作,但也算是在 "real world" 裡剛起步,心有戚戚焉,忍不住就順手翻譯了,希望不管是對還在學校修課的人或者剛出社會的人都有一些幫助,或者引發一些思考、討論。


rdasxy 問到:

儘管很多人在學校已經是個好的程式設計師,當他們畢業且拿到第一份工作的時候,仍然有不少人覺得他們並不是真的懂如何寫程式。在學術的設定下寫程式與「真實世界」寫程式有哪些差異呢?


程式設計師並不會只靠自己一個人寫程式

Michael 回答 (54 票):

在傳統的 Computer Science 大學學程裡你只是學到 programming(寫程式),但真實世界(real world)需要的不只是一個 programmer(程式設計師),而是 Software Engineer(軟體工程師)。我知道很多工作內容的敘述似乎沒有表達出這其中的差異,因為這容易混淆。在實際的世界你需要能夠:

  • 收集並分析需求,這些東西並不是每次都會直接給你的。
  • 在幾乎無限的可能性中設計並分析程式結構。
  • 制定測試的計畫並使用它去評估、改進系統的品質。
  • 與不同背景/經驗的人們團隊合作。
  • 即使你不是很確切地知道你要做「什麼」,還是得評估並計劃時程。
  • 與利益相關者(e.g. PM/整個團隊/投資者)有效地溝通,即使他們的需求有衝突。
  • 在不讓利益相關者失望的前提下,協調時程、預算、品質,以及功能(features)。

哦對了,你當然也必須要能夠寫 code,雖然這些平均來說只佔了 40~60% 的軟體工程師時間而已。

所以並不是這些 CS 畢業的新鮮人不知道如何寫程式(事實上很多人已經是個好的程式設計師了),是他們不知道如何去做那些「除了 coding 以外」的事情。


在真空(vacuum)中寫程式

back2dos 回答 (22 票):

在大學,你的老師教你:

  • 一個定義完整(well defined)、切割過的(isolated)問題。解答是可以在短時間、預定好的時程中得到的。(而且在那之後就會被忽略了)
  • 你會被介紹一組優先用來寫作業的、定義完整的工具。
  • 對你的解法有一個定義完整的衡量標準,這個標準讓你可以簡單地決定你的解法是否夠好。

在「真實世界」:

  • 問題是很模糊、複雜,並且嵌入(embeded)在環境(context)下的。它通常是一組會隨著時間改變、彼此有衝突的需求,而你的解法必須要有彈性且夠強壯(robust),才能在可接受的時間內應付這些不斷改變的狀況。
  • 你必須自己挑選工具。可能你的 team 的老舊 codebase 裡面已經有一些可用的東西;可能有一些開源的專案;又或者有一些商業的函式庫會有;或者你需要自己寫一個。
  • 為了決定你的軟體在這一次的實作是有進步(improvement)的(因為你從來不會真的「做完」一個軟體專案),你需要迴歸測試及可用性測試,後者通常表示你的這個「模糊、複雜、互相衝突、並且嵌入在環境底下」的需求又會改變了。

結論:

在學校寫程式和真實世界有本質上的不一樣,原因在於兩者只有很小的重疊(overlap)。CS 教育是讓你準備面對你的「真實世界」軟體開發,就像為了準備一支軍隊用來戰鬥所需要的體能訓練一樣。


學校是簡單的

Mike Dunleavy 回答 (6 票):

好答案。讓我補充一下,學校的程式設計傾向於幾乎像玩具一樣的規模,對於教學來說是好的。身為一個老師,你要嘗試最有效地去傳達想法。缺點就是實際的程式設計有著質量上的不同(qualitatively different),這是很難去縮小差距(bridge the gap)的。

一個有差異的地方是效能分析(performance analysis)。我已經寫了很多篇文章嘗試要指出這點:效能分析只是演算法跟測量(measure)的皮毛。要有效地做到它,你必須以一個除錯(debugging)的過程去逼近(approach)它。

另一個有差異的地方是可維護性(maintainability)。這包含了從程式碼風格(style)到特定領域(程式)語言的(架構)設計。在你真的知道你要試著去最小化(minimize)什麼之前,你都沒辦法有效的做到。

這些都是學校不會教的東西,儘管它們在生產力上有著巨大的差異。


真實世界的程式碼

dimitris mistriotis 回答 (5 票):

更新:好像有人讀到我的想法了:「畢業期許vs.現實」

My take, 還有兩個其他的因素:

問題大小(size):在學校,我幾乎必須要「從草稿/拼湊(scratch)」開發軟體,這表示著大部分的時間我遇到最大規模的程式,就是我自己寫過的那一個最大的程式。這忽視(de-emphasize)了「處理(handle)與應付(cope with)從不同軟體彼此的互動之間產生的複雜性」的必要能力。如果我警覺到需要理解這些複雜性的功夫,我可能會選擇不進入業界。

讀vs.寫:另一個問題大小的副作用是,通常真實世界我們暴露在別人寫好的工作(work)之中,為了維護也好(我在學術界任何地方都沒做過),或者只是為了分工也好。因此閱讀程式變得比寫程式來得重要好幾倍。

一個為了增進程式教育的提議:學術界應該將我們暴露在更「實際世界」的環境下,而不只是傳統的學術專業訓練(註:without regressing to vocational training)。醫生必須在某一時刻面對屍體,以確認他們是否「被生來做這行」(made for it)。(我聽過一些人的故事是在這個經驗之後就停修了)。如果我早就預見我二十歲出頭接的一個兩萬行(20K line of codes)的專案是由一堆不同的 programming style 組成,並且我必須在一天內看懂、三天內改好一個 bug,我也許已經考慮其他的職業選擇─雖然大概不會啦。

← 選擇性掛載 proxy 的瀏覽器套件 加速 matlab 內建函式 →
 
comments powered by Disqus