操電腦還是操人腦？

抱怨完每天上班時候遇到的問題，後來花了時間去看了這兩位同事的程式碼。看得是技術部分的面向，總算是看到一些進步，不過也突顯出他們在意的是自己在程式寫作技術上的進度，而忽略了態度和技術一樣重要。

「在工作中，態度往往比技術重要許多」，這句話從高中、大學一路到現在，看起來好像大多數的人只是把它當作一句口號而已。

好了，這篇不想再討論態度，講講在看程式的時候遇到的問題。不知道是不是因為不會想，還是因為自信心不夠，發覺他們在程式面的基本功不足，但是卻又往往在專案中只顧著「拼湊出功能」卻不很少花時間思考「怎麼撰寫會更好」。所以有時候讓我覺得，看他們的程式碼很痛苦，不是自身的痛苦，而是會想「這樣寫程式，到底是操電腦還是操人腦？」

這個問題的根源是習慣問題，心中滿滿都是「怎麼趕快把功能作出來，好交付出去」，卻不先想想功能要怎麼作比較好。只想著「趕快開始輸入第一行程式」，卻不先好好思考這個專案要的是什麼。也許看前一篇自顧自的態度有關係，只管作到企劃書上的內容，不管企劃為什麼想要這麼作。

自己在開發程式的經驗裡，許多時候企劃上的只是「企劃覺得程式比較好作的方式」，但是有些時候卻不是這麼一回事，但要是撰寫程式的人傻傻的不去詢問，還在心中抱怨企劃在折騰人，這樣誤會就開始了，程式人員和企劃之間的關係會越來越差，最終到敵對的地步。

但是，只要花一點點時間想想企劃要的是什麼，就可以提出程式面的看法，也許功能少了一點，但是能在更短的時間完成，或是花多一些時間，有特別的效果呈現。甚至有些時候，可以找到程式好寫(花的時間少)，效果的又好的方案。

自己的程式能力，其實就是這麼一點一點的累積上來，企劃願意找我討論，也就是看在我能夠提出想法，一起試著讓專案變得更好的態度。而我也將這個想法，用在自己的程式裡面，怎麼樣能夠將程式變得更單純，怎麼樣可以讓程式碼撰寫變得更簡單，更不容易出錯。其實講穿了，只是一個小小的技巧︰「知道要什麼」。

剛學程式的時候，看到一些說明如何寫好程式的書，會提到幾個技巧，其中一個是讓一個類別只負責一項工作，一個方法也只作一件事情。當時看不出來，只覺得奇怪，程式往往作了許多使用者看不到的事情，有些動作幾行程式就能夠完成，特別拆分成好幾個方法，感覺浪費空間又不自然，而且還要多花精力去思考函數的名稱。未來看程式的時候，也不見得比較輕鬆。

直到前陣子，我才稍微了解這個技巧的意義，實質上並不是讓類別只作一項工作，或是讓方法只作一件事就是好的程式。而是去思考這個程式運作的方式，將重覆的部分先找出，自然就會先產出一些可以通用的函數庫或類別集合，這些通用的部分，當然只代表某個工作，達到第一階段的單純化。等到確認程式的功能正常之後，就可以將功能如何完成的程式邏輯移出腦袋之外，因為接下來只要「會使用」就好。

當寫到應用部分的程式碼時，就可以使用少少的程式，將功能串接起來。腦子裡只需要思考「這麼串接是不是達到需要的結果」，而不需要思考這些功能要如何完成。所以程式碼的行數不多，未來要回頭來看程式就會變得單純許多。只需要思考出問題或要修改的程式是在哪一個流程，再去專注修改應用的部分的程式，或幾個共用函數，就能在修改幅度更小的狀況下達到同樣的結果。

那「操人腦」的狀況是什麼？就是試著將使用者按下一個按鈕，作了某一個動作之後要處理堭事情，全部寫在一個函數之中。沒有嘗試將重覆出現的功能，抽離改變的地方，讓程式碼變少且穩定，將許多地方都會使用到的資料改成類別變數，好讓修改可以在短時間達到。所以，一旦要回頭修改幾天前的程式時，就得花上許多時間先看懂之前的程式，否則很可能會在一次修改中，改動到不該改動的地方，造成新的錯誤點。

在撰寫程式的時候，不斷回想之前是怎麼寫出這些程式。還要分神去思考程式流程，又要去記憶一個又一個變數代表什麼意思。感覺就不像是利用電腦分擔工作，而是靠自己將每一個工作一個一個「刻」出來。

雖然自己是花費比其它人更多的時間下苦功練習，但是本身資質並不好，所以直到最近才慢慢開始體會，看到明明資質比我好，卻卡在「不會想」產出一行行自己寫得累，又得不到別人信任的程式，總是覺得很可惜，但昰又莫可奈何。

雖然稱教學，但是這個世界上只有「學」卻不存在「教」，能講的已經講過，如果不願意學習的話，還是一點辦法都沒有。