系統工程師的角色扮演分類：職場

一直以來我們一直討論程式設計師的特性與努力的方向，其實有更重要性的工作是由系統工程師來完成的，有些人可能不知道在小公司，研發工程師擔任了很多系統工程師的角色，於是系統工程師的地位就降低了很多。

在大型企業都有電腦室或是資訊室的設立，他們負責了公司上上下下的電腦系統的維護，大家對他們的印象也不是非常的好，通常電腦出了問題，要找問題找很久，要透過採購維修或是送修才能解決問題，而且不一定能解決問題，造成一般行政人員工作上的不方便。

我想要做好系統工程師的角色並不是只是單純的設備的組裝與維護，非常重要的解決問題的能力是要靠經驗及，邏輯推演的方法來執行，而解決問題只是一個資訊室或者IT部門最最基礎的工作之一，並不是這樣子就能擔任好的系統工程師，前十年(1990-1999)的系統工程師的主要工作大部分是PC的組裝與維修、網路的架設、伺服器的維護，甚至也負責電話線路及總機的系統，但是目前的PC電腦、伺服器及網路設備都非常的便宜及精良，所以部分的系統工程師也大部分擔任資料庫或是檔案的例行處理工作，譬如說備份、傳輸等等。

我想這些工作並不是操作員(OP)，而應該加入邏輯的思考，就像家電產品，大部分人買回家只是插上插頭就開始用了，並不知道裡面的運作方式，如果系統工程師也是這種心態的話，他的工作一定會隨著系統的不斷地創新開發被別人取代，系統工程師每天在操作的伺服器、資料庫，也了解裡面的運作程序，才能正確的抓出執行的問題，幫忙行政人員解決問題，系統在升級的時候能適時的提出正確的評估，幫忙計算成本及架構未來最好的操作模式，千萬不能有自私的心態，是不是我的工作未來就會縮減消失，每一個時代都需要系統工程師，只是運作的成本會隨著科技的進步而改變。

想想目前的系統工程師最熱門的應該是在網路的架設與規劃，前幾年著重在NT的伺服器，但是我想這些東西只是您平常操作的工具，現在免費的Linux也是一種網路的產品，這些東西一直出現，系統工程師的工作除了要了解這些系統的操作設定之外，基礎的理論是最好要熟記的，如果網路通訊協定的特性不了解，如何能正確的設定一個公司的環境呢?

系統工程師的路很長也很遠，不但要負責與研發人員溝通了解系統的運作，還要與行政人員周旋，還要不斷地學習成長，但最重要的還是邏輯的思考。

程式設計的具體化與抽象化分類：系統

以我寫程式多年的歷史來看，寫程式除了靠經驗的累積以及開發工具的使用之外，最重要的就是邏輯推演的具體化與抽象化兩個方向，這兩個方向若能互相契合，這個軟體系統就能把錯誤減到最低，而且跑起來也特別的順暢。

首先先想一想我們再解一道代數數學的題目時，總是用一些抽象化的方法，先盡量把因數分解、多項式的加法變成乘式或者除式，然後把就可以找出答案來，但是這個過程除非經過大量的死背經驗，不然很難想出這些抽象的方法，這也是大多數人代數學不好的原因，無法具體化答案。

PS. X^2+2X+1=16 →　(X+1)^2=16 → X=3 or -5

記得我剛學代數的時候，每當解不出答案的時候，就是硬寫了一個小程式，把代數的數值從零開始把代數值填入，利用電腦的快速運算，找出最接近的答案，甚至到了微積分的考試的時候，特別去買了一台可以寫 BASIC程式的計算機來找答案，雖然答案對了，但是解題的過程完全無法交代，所以還是被當掉了！

要寫出一套好的系統，抽象化與具體化的能力一定都要能培養，我看了很多的程式，只是在寫流水帳的程序而已，要什麼功能，就寫一個功能，要一個對話窗，就畫一個對話窗給使用者，到最後程式愈來愈大，雖然這個是具體化的結果，但是所有的程式都沒有模組化，前因後果也沒有考慮，當然系統就不好維護，要改一個程序的時候，甚至都沒有辦法修改，而衍生出一些Bug! 這時候就要適當的加入一些抽象化的概念，想辦法分類然後模組化或黑箱化。

我也看過非常抽象化的程式，每一個模組的分的很好，利用物件導向的程式寫出來，但是看程式就像數學的解題過程一樣，非常的刺激，但是維護起來卻十分的困難，要加一項功能，就要花很多的時間!

一套系統在開發的階段，不可能完完全全的仰賴客戶或所謂的系統分析師的紙上作業，實際在寫程式碼的時候一定會發生困難，利用具體化或抽象化的概念，不要讓自己困在中間，才能寫出一套好維護的系統。

系統架構的構思過程分類：創新、系統

創意的構思過程可以分為感覺構思→邏輯構思→多面構思→靈感構思 這四個過程，而我們往往在一個系統的構思階段便想了很久，做不出來，只要善用這些構思的方法，你很快可以把一個系統的架構畫出來，以便快速的完成一個雛形。

一般的軟體工程師往往會不滿現狀，想設計出一套完美的系統，我們在之前討論用最笨的方法來思考的時候，就是避免大家想的太多非必要性的功能，造成後續維護與發展的困擾，試著想想看當我們早上起床刷牙洗臉吃早餐一直到搭車上班，我們需要用很多的腦力去構思嗎？這就是反射動作，我們在做一項思考的時候，往往就是用感覺構思就已經完成了大部分的事情，可以說是反射動作的思考。

當我們找不到一項東西，譬如說是一本書好了，便要冷靜的回想，什麼時候用過這本書，書本可能放置的位置，從主題意義來想，用各方面的判斷與分析，是不是上大號的時候放在廁所，或是放在公司放在朋友家裡忘記拿回來了，這個構思的階段就是邏輯的構思。

如果找不到我們通常就開始全面的搜索，地毯式的找尋，把全家每一個地方翻過來找，我們在創意會議的時候也常常如此，把所有現有品牌或是競爭對手，把字典的字全部翻出來，一項一項檢討比較，這個就是多面的構思。

至於靈感的構思方法，是我們比較少用的，用不同的角度，在一個突發的狀況下想出一個靈感，好像寫文章文思泉湧，創意猛然向你撲來，這個就是靈感的構思，一般寫程式的時候也就是為什麼有時候去上上廁所休息一下，就會把Bug臭蟲抓出來的原因。

而據我個人觀察發現一般工程師在邏輯構思的階段就往往無法決定是要往哪個方向，無法決定用哪個方法來實作，這個當然是要問問別人的意見，如果無法很快的做決策的時候，一般來講都是先做了再說，當然不要做完了再來測試，要做到一半的時候就要想辦法測試，來看看自己當初想的方向有沒有錯誤。

再來工程師常常犯的毛病就是想的太多，設計一些很少會用到的功能，雖然是多面的思考，但是很少會用的上的，這一點需要做一些測試，來測試我們的程式碼，這一點也是我們目前為止很少做的品質管理工作，來評定我們的程式設計師。

當然撰寫新系統需要一些經驗，看看前人的程式碼是最快的學習方式，用上述構思的方法或許可以讓您更快的了解你的思考架構。

延伸閱讀：【創新】先把自己變笨，歸零的思考