上個星期看到一篇短文，文章網址如下
http://buzzorange.com/techorange/2015/10/08/the-six-most-common-species-of-code/
這文章很有趣，它列出不同的人會如何寫出同一個 function．
看到學生寫的就是很標準的學生該有的答案．儘管 recursive 的寫法會有 call stack overflow 的問題，但對一個學生來說，重點是練習 recursive 的思考，所以這樣寫蠻好的．
看到由 Hackathon 寫出來的答案，哈哈，老實說，我真的是打從心裡笑了出來．這個笑可不是嘲笑的笑，而是一種打從心裡佩服的笑，尤其是看到那一句註解 // good enough for the demo
再來看看新創公司寫出來的，其實看不出來這和學生寫的有什麼大差別．也許作者在暗示些什麼?
再來看看大公司．還真的是有大公司寫法的樣子．你是否曾想過大公司的寫法為何是這樣子呢 ? 明明是個很簡單的數學式子而己．我能想到的幾個原因如下:
1. 大公司所生產的產品都具有一定的規模，所以在具有規模的產品下，一定會有許多設計是為了滿足軟體設計的一致性．所以，可想而知，這種具有規模的程式碼一定都是抽象再抽象化，把物件導向常用到的觀念一定都會套用進去，所以你才會看到也許明明是一個簡單的動作卻要搞的好像很複雜的樣子．
2. 大公司也是從小公司漸漸演變上來的，程式經過長時間的演變並且很可能經過許多不同工程師的改進與維護，所以，一般人很難能很快速地看懂程式碼，因為實在有太多故事在裡面了．
3. 在大公司工作的工程師們，平均來說也都是書念的比較好，程式寫的比較好的人．這些人心中或許有一些優越感存在．這些人也許為了顯出自己的優秀，真的會寫出很優秀的架構與運作流程，但由於實在太優秀了，所以對一般人來說就比較不容易懂．
最後，我們再回到 Fibonacci 數列．在電腦與數學的世界裡，這是一個非常有名的數列．在學校學習有關 recursive 或程式設計時的基本練習題目．也許你也可能在面試的時候會遇到這一個題目．一般來說，大家都會直覺地用 recursive 來寫這個題目，因為學校課本是這樣練習的．以時間複雜度的角度來看，recursive 的寫法並不是最好的，更何況它會有 call stack overflow 的問題．我會建議大家改成用 dynamic programming 的寫法，從小的數字算起，一直累積到大的數字，時間複雜度只有 O(n)，而要付出的代價就是較多的記憶體空間．所以，Fibonacci 若把 recursive 改成用 dynamic programming 來寫的話就是典型的用空間換時間的方法．
再回到主題，那程式到底要怎麼寫才好呢 ? 其實，我欣賞 Hackathon 的寫法，重點並不在於寫的好不好，重點是這樣的寫法非常能表達出來作者明白所需要達成的目的是什麼．所以，把問題回歸本質，我們應該要問的是，輸入參數會是什麼，需要輸出什麼，有多少的 CPU 與記憶體可以用．把目的搞懂，再把限制條件搞清楚，這樣寫出來的程式不會離好程式太遠了．我們只要在我們關心的情況下讓我們的程式能正常運作就行了．在限制條件或需求之外，程式會有問題的話，那也不是我們需要關心的．
0 意見:
張貼留言