[讀書報告]構建之法(一)

標籤：sp   java   資料   問題   bs   代碼   時間   工作   nbsp   

今天我閱讀了鄒欣老師的《構建之法》從前言到本文的第66頁，一些思考和體會如下：

1.前言

從前言可以看出鄒欣老師對軟體工程課的定位和對這本書作為教材的評價還是很高的。從前言可以知道這本書是鄒欣老師結合了在一些高校的軟體工程授課經驗和自己的心得體驗，寫出的一本強調通過動手實踐學習軟體工程的教材。

2.給任課老師和助教的建議

這部分可以看書鄒欣老師對同學們的要求很高，預期每個學生需要每周花費8個小時在這門課上。我個人而言，在個人項目和Team 專案中每周花費的時間要超過8個小時。在Team 專案中如果算上開會討論等事務的時間，也是超過八個小時的。而在Team 專案中，寫代碼的時間則不是很穩定，有的周超過8個小時，有的周則不夠。

面對軟體學院老師的抱怨，鄒欣老師提出的問題的解決方案是先讓同學們維護已有的程式再逐步漸進式開發的方式。我覺得這種想法很好。當時黃金點遊戲我們組得到了第二順位，挑選項目的優先順序還是很高的。當時懷著對已有項目的天真的認可，包括我們的所有順位靠前的組都選擇了對已有項目的反覆式開發法。但事實證明我們真的是too young to naive，因為拿到手的程式根本不是一個完整的程式，何談反覆式開發法？這從很大程度上打消了我的熱情，是我有了很強的抵觸心理。

鄒欣老師對於師生關係的論述羅傑老師在上課也講到了。教練/學員模型確實很吸引人，但是在實際的開發過程中，我覺得是學員們在獨立戰鬥，從老師那裡能夠得到的協助極其有限。

關於鄒欣老師給出的1/N打分法和團隊貢獻分的機制，我覺得前者太殘酷而後者太理想化。可能還是社會本來就很現實而作為學生的我還太naive。

3.第一章

第一章主要將了一些概念性的東西。比較重要的可能是幾個公式。

一個是我們很早就知道的公式：

程式=演算法+資料結構

另外兩個我認為是書提醒我們要額外注意的：

軟體=程式+軟體工程

軟體企業=軟體+商業模式

對於這三個公式，我有些自己的想法:

程式對人與人關係的涉及最少，軟體和軟體企業對人和人與人關係的探尋則是越來越多。

看來人還是最根本的。比如鄒欣老師在書中提到，很多軟體功能相似，但使用者體驗將他們拉開了巨大的差距。

看來博弈歸根到底是人與人的博弈。

4.第二章

第二章講個人技術和流程，比較實踐性的內容包括單元測試和效能分析。

鄒欣老師列出的對比大四學生和工作三年的軟體工程師在個人項目耗時的對比很有意思。

最明顯的對比是SDE比學生多60%的時間在需求分析和測試上而少1/3的時間在編碼上。這現實了職業化有一個突出的特點就是正常化。

5.第三章

這一章講軟體工程師的成長，我想每一個學生都會很關心這個話題，我當然也不例外。這一章依然印證了職業化的突出特點是正常化。要成為一個優秀的軟體工程師，很多東西不能夠再用大概、差不多這種詞去描述，而應該用真實記錄下來的資料說話。而真實的項目是能力提升的必由之路。

鄒欣老師提到的魔方的例子使我印象很深刻。怎麼提高技能，鄒欣老師給出的答案一針見血：通過不斷的練習，把那些低層次的問題都解決了，變成不用經大腦的自動操作，然後才有時間和腦力來解決較高層次的問題。事實上，這種模式正式中學時代的模式：所有的知識點都已經到了滾瓜爛熟的接近本能的程度，然後才能在應付各種題目的過程中天馬行空隨意施展。

但這可能也是我和我身邊的很多同學們面臨的最大的問題。又想提起大二下的物件導向課了。物件導向課確實講了物件導向的思想，也寫了很多的代碼。但更多的時候我們是在糾結於代碼的細節而不是物件導向。能用指定的java語言寫出基本滿足功能的程式交了作業就已經很糾結了，誰有功夫去管什麼對象不對象呢。

現在的軟工課，也是這種感覺。這學期的另外一門大作業，資料庫，也是這樣。

所以雖然編譯的課程設計最難，但是做起來最舒服。因為只要想通了，就能寫出來，你不會問自己：我的這個設想需要的一些東西語言支援不支援，因為你很清楚，這種語言能做什麼，怎麼做。

我們確實學了很多語言，必修有c，選修有c++，java，c#，ruby，但用的熟練的確實有限。

可能是我們的努力還不夠吧。

 

[讀書報告]構建之法(一)