現代軟體工程 第三章：【軟體工程師的成長】練習與討論

標籤：ar   strong   sp   div   art   on   問題   代碼   工作   

1.選哪一種醫生？ 分析一下四個醫生，a）屬於新手類型，能力有限，經驗不足，主要能完成功能就可以。bug會比較多，代碼也不規範。b）屬於創造類型，既然能想到新技術和新方法，說明必然有一定的經驗。但是創新雖好，也可能失敗，成功可能性跟自己的能力有關。c）屬於熟練類型，對於代碼的實現相當熟悉，能夠快速的實現功能需求。d）屬於糊弄類型，相當之不靠譜，明眼人都知道，但有時瞎貓碰見了死耗子或者民間高手也有可能出現。  你要選哪類醫生？ 我會選c類型的醫生，雖然創新不能保證，但可以保證最基本的功能需求。但是更想要在架構層面厲害的程式員。他們經驗豐富，對相關架構和工具等都很熟悉，“完成功能”“穩定性”“效能”這些已經不再是他們的追求，更優美的代碼、更合理的架構才是目標。 軟體工程師需要有正式的職業認證才能上崗麼? 如果是作為一般的程式員，俗稱打工的，個人認為只要精通某一種語言，可以協助團隊完成功能就行，不一定要相應的認證。但如果是深入某一個領域，應該要有相應的認證，對於找工作時的個人和企業雙方都有好處。  2.軟體開發是一門工程（Engineering）,  是一門藝術（Art），還是一門手藝（Craftmanship）? 你如何衡量藝術家? 如何衡量創造能力? 個人認為軟體開發首先應該先是一門工程，在保證基本的工程品質情況下，某些優秀的軟體以及代碼可以上升為藝術。  軟體設計工程師們在做代碼複審的時候，是看“重複字”的多少, 還是程式的藝術性？ 在這個方面個人認為軟體設計跟文學是有極大地不同的。而且即便是文學作品，關於“重字”這件事，在不同類型的文學作品中也是不同的。比如小說中的重字絕對要比古詩詞要多得多。同樣的軟體在代碼複審時，代碼量很大的大型軟體同一個簡單的helloworld小程式中的重字也沒有可比性。況且在軟體中代碼的重用不可避免，一個函數也會被調用多次。合理的對代碼進行重用，應該也是一件藝術性的工作。  3.絞刑架和職業發展 絞刑架故事就是在職業發展道路上的困難。各種技藝、職業、事業也是如此。有了困難，才能攔阻與淘汰掉一切不如我們的競爭者。  4.程式員小飛原計劃三天完成某個任務，現在是第三天的下午，他馬上就可以做完。但是在實現功能的過程中, 他越來越意識到自己原來設計中的弱點，他應該採取另一個辦法，才能避免後面整合階段的額外工作。但是他如果現在就改弦更張，那勢必要影響自己原來估計的準確性，並且會花費額外的時間，這樣他的老闆，同事會因此看不起他。如果他按部就班，最後整個團隊還要花更多時間在後續整合上，但那就不是他個人的問題了。怎麼辦？ 主動向老闆、同事解釋清楚更改設計的原因，主動承擔責任是首要做的。一個項目做得好是所有人努力的結果，如果出現問題，黑鍋往往是一個人背，孰輕孰重，應該能看的懂。  5.軟體工程師的工作就是寫代碼，相關專業的練習也是以閱讀代碼，寫代碼為主，那麼代碼量和工程師的水平是線性關係麼? 在我等學渣眼中，代碼量跟工程師的水平就是線性關係。當然像Norris這樣的大神專門做了研究，提出了程式員瓶頸這樣的概念。的確剛開始的時候瓶頸可能在2000行，隨著成長變成20000行。在理解了結構化編程以後可能還會遇到20萬這麼大的瓶頸。所以代碼量和工程師的水平是階段性的關係，突破瓶頸意味著質的飛越。  6. 成長和公司的關係，軟體工程師在企業中是勞動密集型的工人麼，還是有獨創性的專業人士？ 他們對軟體企業的成敗負多大的責任? 軟體工程師在企業中不應該是勞動密集型的工人，而應該是有獨創性的專業人士。但是在中國的諸多企業中，包括外企，往往都是專業人士帶領著一群勞動密集型的工人在工作。但是正如adobe內部那樣，普通的程式員再聰明，也沒有能力在大方向上改變公司的決策。因此軟體企業的成敗不應該由軟體工程師來負主要責任，如果要把這個責任強加到軟體工程師身上，那麼至少也要給軟體工程師同等的發聲權利。 

現代軟體工程 第三章：【軟體工程師的成長】練習與討論