1. 程式人生 > >回望來時的路:構建之法東北師大站 2016春季學期

回望來時的路:構建之法東北師大站 2016春季學期


1.  前因

微軟鄒欣老師著有《構建之法:現代軟體工程》[https://book.douban.com/subject/26577755/]。第一版首版以前,我還不知道鄒老師是哪一位,就在網上曾經看到過有人轉引他的觀點,感到說得太有道理了,一拍大腿的感覺。比如他提到教師和學生之間應該是健身教練和學員間的關係,不是教師帶領學生參觀瀏覽,也不是獄警和囚徒的關係。比如他批評沒有程式碼量的軟體工程教學。《構建之法》到手,第一遍粗讀我花了一週的時間,酣暢淋漓。很多處讓你再拍大腿,“對啊,這正是問題的癥結,他的招兒沒準好使吶。”在那以後向我的好幾位學生極力推薦閱讀。似乎亮哥看了,別的同學也沒有怎麼重視,雖然我極少推薦讀哪本書,怕推薦多就不值錢了。

 

鄒欣老師本人是微軟首席研發經理,北大、清華、北航等採用過《構建之法》作為教材。一方面權威,另一方面也令我等小校望而膽怯。有次在周筠編輯的群中得知,他有意圖促進《構建之法》和“learning by doing”的軟體工程教學理念在不那麼特別好的學校裡推廣,頓時心嚮往之。我想起不少小說裡描寫到的文革時期隨便那麼幾個主人公小青年,就能懂副歌,能關起門來討論伏爾泰和盧梭。時代之進步,讓我們有機會偏居一隅而能與世界對話,應該充分享受比那時更幸運的條件。但是那個學期我排課程失敗了。鄒欣老師後來招募遠端助教參與別的學校的教學,我也非常也申請,但是估計自己的時間和精力不足以做出工作量的承諾,只好放棄,非常可惜了很久。

本學期有機會開設課程《軟體專案管理》,趕緊求同學們選我選我選我,達到限額,終於開課。

2.  課程的一些資料

2016年3月4日13:30:00計算機樓320教室,夏一鳴同學[http://www.cnblogs.com/xiaym896/]在他最後一篇技術部落格裡清楚地回憶起時間地點。事實上,他回憶錯了,第一堂課因為排課衝突,臨時改到了二樓的微格教室,以後的課程都是在320教室,不過時間沒有錯。

3月4日起,課程教學持續12周。

選課時間註冊XX位同學。這個數量並不重要,僅為超過開課人數限制。這裡有些同學根本不打算要成績和學分,只是助我開課。感謝。

實際參加21位同學,堅持到結束17人。放棄的同學,有的是在第一次課程以後就發郵件通知我了,只要成績,不想參加專案實踐;也有同學嘗試了開設部落格這一步,然後放棄;也有同學比這還努力稍多一些,發了一兩篇部落格。雞湯名言說:所以的失敗都有一個共同點,就是堅持的不夠久。也許我們所能直接看到的利益太少,也許我們能夠做出的選擇太多,也許如劉偉碩同學說,缺乏強制措施。還有同學在學期末的感言中提到,如果能夠再有一次機會,如果可以重開此課,諸如此類。說實話,今生放手的人,我不怎麼相信來生會更珍惜。

這17位堅持到底的同學中,有三位旁聽生。他們沒有註冊,也不會有學分,但是成績優秀。其中一位是我以前的學生,她現在本人也是教師,同時作為鄒欣老師本學期某校的遠端助教,名鄭蕊;一位是現在的研究生,但是他沒有選課,名亮哥;一位是本科三年級同學,名冉華,他曾經一度參與亮哥的專案。鄭蕊和亮哥的成績屬最優秀的之列,冉華同學獨立完成了一個持續10天計累計46.05小時的小專案《H3C匯聚層交換機認證線上人數展示系統》。這告訴我們人的主觀意願和追隨內心的力量。

全體同學釋出技術部落格共254篇,人均超過每週1篇。教師釋出21篇,每週約2篇,其中一篇是這一週作業重點提示及更新點評,另一篇是這一週作業的成績。

在第3周開始,全體同學結成4個團隊,每組約4位同學。其中3個團隊站到最後,1個團隊在alpha釋出後開始解體。解體的團隊,有1位同學加入其他團隊,另2位同學保持遊離態。

以團隊為單位釋出專案,學期末釋出共5個共3種。3種專案是 搶答器、記賬本、四則運算線上,分別源於耐撕團隊、OneZero團隊、爆打團隊。在學期中真beta版釋出後由每個團隊選擇fork其他團隊的一個專案,並在兩週內增加功能,與源出的團隊競爭開發,即要求每個團隊最終釋出2個專案。學期末,搶答器、記賬本有2個團隊分別釋出branch,四則運算線上1個branch,共計5個。這樣做教學上的原因是東北師大北前沒有積累可供訓練維護 階段的程式碼,以fork其他團隊來部分貫徹鄒欣老師提到的:寫一萬行程式碼,在別人的十萬行程式碼中愉快的執行。

所有的技術部落格和程式碼可以通過教師部落格[http://www.cnblogs.com/younggift/]找到。

在第2周課程的時候鄭蕊同學建立了 東師軟體工程 微信群。不過與《構建之法》其他高校的群不同的,東北師大的群裡基本沒有人說話,教師臨時修改增加作業或點評,也不太有響應。我本人不喜歡在“群”裡被集體通知或告之,然後自己選擇是否與自己有關。這種被組織的感覺不好。我擔心同學們是這樣感受的,進而進入獄警囚徒模式,所以對群裡一片安靜聽之任之。東北師大的群最後大家選擇了實名(而且人數這麼少很容易人肉出來吧),據說有的高校的群是匿名的,有同學發表了對教師和/或助教的不滿。這也是個大家不吱聲的原因吧。還有,可能由於就業太容易,似乎無論什麼對就業都沒有什麼正面或負面影響,東北師大的同學似乎歷來高冷……我習慣了。

3.  歷程

第1周和第2周,基礎知識及雞湯。知識不是重要的部分,更不用說對於研究生階段的同學。往往是,我們知道,但是不做。更重要的,猛灌雞湯。同學們通常並無強烈的動機想進修軟體工程。他們的熱情一般止於熱烈的表達願望,或者言不由衷地對科目重要性的認識,有時還有對教師的表揚。但是,也僅止於此。第一輪工作量就會把他們貌似熊熊燃燒的小火苗燒熄,然後他們會說,“其實也那麼重要,其實也沒那麼渴望”,用那麼二字這一程度副詞否定自己的“初心”當真是好藉口。雞湯是藥,不能停。在真beta釋出前後,教師說,以後不會再有雞湯了。那個時候,同學們疲於應對從沒見過那麼多的工作量。同時,教師對同學們不能甚至消極地響應很失望,鄒欣老師和周筠編輯的雞湯也不足以補足元氣,對每週的截止時間週三晚24點守歲般度過然後你沒有提交作業很失望。我覺得,你們並不像你們所聲稱的那樣希望我們共同所做的事,而你們沒有想到我會堅守承諾,並且對你沒有堅守承諾憤慨和絕望。我就是在這個時候放棄的,當你用行動宣佈放棄的時候。好多年前我用更激烈的措辭給學生們寫過一封信,大意是,我們不是因為情感走到一起,而是因為共同的目的,你不堅持,就是背叛,我絕不挽留。我現在會微笑著對全班同學說,“我愛你們,同學們,發自內心,而且你們真的與以往每屆都如此不同”。不過,我沒有什麼不同。

從第3周開始,分團隊,團隊專案立項介紹。兩週SCRUM,要求每天站立會議及會議報告作為技術部落格,每個團隊共10篇。不過這只是要求和願望。不少同學們在這時還沒有意識到我在第一堂課的雞湯,“剛工作的同學往往以為有60分這一檔,其實那是不存在的,工作上只有0分或及格。”只要你有一點不符合要求,就觸碰了底線,0分。超過截止日期,要求的專案有沒有完成的,指標達不到要求的,要求結對沒做的,要求互評不評的,都是0分差評。在工作中,我們就是這樣一步步失去信任的,如果偶有錯誤,時機不定;也是這樣一步步贏得信任的,如果你每一次都符合要求。有同學問我,在工作中如果做得不好,是不是就會挨批啊。不會的,成熟的上級從來不批評你,只會減少你的工作量,越來越少,直到轉崗開除。而乾的好的,會不停地挨批要求改正要求更好,然後升職,去承擔更重要更可怕的工作。

兩週SCRUM後,alpha釋出發期進行。此前亮哥創造性地給了一個釋出劇透,介紹釋出時將會發布的事情,簡述功能。此後,劇透成要標準要求。alpha釋出後,每組有1位同學離開原組,加入新的團隊。alpha要求有真實使用者評論,4組團隊只有2個使用者評論,並不詳細和認真。達不到要求,和教師不敢於認真要求,都是一步步的,如同腐爛,是緩慢開始的。有一整天不呼吸,以後就不能呼吸了,有一年不聯絡老友,他就不再是老友了,有一次不遵循規則超過要求,以後就不再是完美實現了—不少人就此放棄,雖然不完美也比一次次放棄要強。

東北師大的SCRIM及alpha早於《構建之法》16周的教學計劃,是因為考慮到課時少,可能會早於16周結束,另外假設學生有更好的軟體工程課程基礎,因此理論教學減量。

alpha釋出如同《構建之法》其他高校及鄒欣老師的預料(通常總是如此),同學們高估自己可能輸出的工作量,有太大的雄心壯志,然而無能實現。所以alpha釋出後,同學們都趨向現實和保守,每週只肯實現一兩個工作量不大的功能,我甚至懷疑大家開始降低投入時間了。

4周已過的時候,頒發領跑衫兩件,獎給當時成績最突出的兩位同學。分別是鄭蕊和劉偉碩[http://www.cnblogs.com/younggift/p/5352171.html]。

 

又兩週SCRUM,每天站立會議及報告,然後beta釋出。在這兩週中也包括對alpha釋出的review。考慮到研究生同學有更自由的時間可供支配,此處比《構建之法》減少一週專門的alpha回顧。這兩週SCRUM之後原計劃是beta釋出,但是各團隊並未做到beta的應有之意“公測”,沒有真正使用者,並且功能也並不大的進展。

教師稱此次釋出偽beta釋出(因為沒有真使用者),要求再兩週SCRUM,增加功能找真使用者,然後真beta釋出。這期間教師按學校要求出差1.5周,在網上看了作業,但是由於視力原因不能點評,真beta釋出由亮哥主持。在此期間鄭蕊提到有一週的工作狀態是“失控”,其他同學雖然沒有提到,教師以為這是普遍的現象。同學們開始痛恨或者無視課程要求,工作量壓得喘不過氣,並且維護既有程式碼並增加功能帶來更大的壓力。雖然各位在學期末的回顧中很享受的樣子,我深以為有多半是軍訓般的斯德哥爾摩效應。我們不應該喜歡訓練帶來的痛苦,我們只是喜歡訓練帶來的結果。之所以如此痛苦,是因為以前的積累太差了—像網上的段子說的,期末的突擊學習的難度,取決於你是複習還是預習。在這樣一門課程中,又要積累程式設計經驗,又要學習工程理論,又要實踐。恩,既然貴族需要三代能積累出來,那麼我們還是繼續做奴僕好了。

第12週期末final釋出。要求所有需要成績的同學參加,本學期唯一不接受請假的一天。有同學電話我了,確實有非常之理由需要缺習,我表達了我的理解,也請他理解我不能接受請假的理由。

在final釋出時,又頒發4件領跑黃衫,分別獎給
特別能作戰 齊嘉亮[http://www.cnblogs.com/dendroaspis-polylepis/p/5534847.html]、
敬業福 夏一鳴[http://www.cnblogs.com/xiaym896/p/5536226.html]、
可以託付靠譜 濮成林[http://www.cnblogs.com/charliePU/p/5537734.html]、
力挽狂瀾 高鑫[http://www.cnblogs.com/gaolzzxin/p/5515451.html]。

 

成績核算,需要按學校的要求,作業和期末論文都要交紙質品。具體的我要求為技術部落格列印,期末論文列印,程式碼我折衷了一下,給出程式碼片斷及下載地址。

最後,進入鄒欣老師所說的“諸葛亮會議”時間,會團隊review,教師也review。在此期間以前的畢業生正在上海工作的李暘發來對耐撕團隊程式碼的review,使本已沉寂的耐撕團隊隊員內心又起波瀾。課程有結束之日,求索沒有停止之時;常回望來時路,才能進步。

 

4.  外援

鄒欣老師拿出自己的稿費徵募遠端助教,為各高校提供幫助。這樣一門實踐不瘸腿,程式碼量和寫作工作量很大的課程,需要助教給學生及時和充分的反饋才能得以進行,而高校機制決定難以實施。鄒欣老師自掏腰包,以及課程本身的吸引力,頗有一些實踐經驗豐富的工程師承擔了助教工作。助教無疑也付出了非常多的時間,要知道,幾乎每一行程式碼、每一行文字,助教都是稽核過的。只是,也許能力,也許精力,更重要的是時機,助教沒有指出學生每一個細節的失誤。我本學期沒有申請助教協助,因為知道成績核算方法和教學水平都不一定能保證滿足鄒欣老師的設計意圖,所以由我一個人兼作教師和助教。從我的學生僅17人計,仍然感覺工作量非常大。我最初每次回覆和點評技術部落格,需要1至2小時。後來只好拆分成幾段,挑空閒時間而且有PC機的時候處理。很多個小時,一般是一整個下午,多半個晚上。牛寶樂老師和鄭蕊老師分別做過助教,他們也都提到工作量巨大。我知道承擔助教工作的還有幻飛龍博士。雖然我沒有申請助教,但是也從助教群中收穫不少,包括不限於工具、方法、學生的現狀。謝謝各位助教。

鄒欣老師和周筠編輯提供的領跑黃衫,著實讓同學們興奮了一把。來自“官方”的看得見的肯定,仍然是同學們追求的重要目標和強大動力。

很多學生的技術部落格,鄒欣老師也給也點評或者建議。他的點評和建議從來不是泛泛的,而是切中肯綮。一方面,我感慨鄒欣老師同時點評這麼多高校和學生,作為教師我也能學到不少,心存感激。另一方面,我和鄭蕊私下交流過,我們點評一篇需要半小時以上,而鄒老師只需要八九分鐘,質量卻是比我們更高。所謂高手和菜鳥的差別,他們少犯錯,他們效率更高。能讓我們親眼看到高山仰止,也是幸運。

除了鄒欣老師以外,還有幾位專家也參與了點評。他們是[email protected]柳園 (餘晟), 李暘,無效的暱稱(來自阿里的曾同學)。幾位共同指出一個特別重要的問題,程式碼規範和文件規範。這不僅是學生的問題,也是教師的問題。如果有下一次課程,我會注意改進。謝謝。[email protected]柳園就規範問題還給出過具體的建議,文件模板。這一點我心尚存疑,對於學生的主動性培養和適當引導,我仍然在猶豫之間,此時就以鄒欣老師提供的教輔助材料為準。謝謝各位。

為了能得到來自校外的專家的點評,我在助教和構建之法微信群中,每一週都發布廣告,懇請指導和鼓勵。後來我不敢再繼續釋出訊息了,因為同學們做得實在令我汗顏。如同我在課堂上說的,所有的一切都是公開的,程式碼袒露在所有人的面前,東北師大和你個人的能力如何,是不是會被別人藐視,無論你多麼愛國和愛校,事實也就是這樣。尊重不是靠懇求和隱瞞得到的,而是靠實力。

在教學中,我還得到了牛寶樂老師的幫助,他向我推薦和提供了幻飛龍博士開發的工具,把EXCEL格式的檔案轉換成Markdown格式。我用這一工具處理每週釋出的成績,以及成績計算的依據。非常有效,節省了不少時間。謝謝二位。

兩位旁聽生,鄭蕊和齊嘉亮,成為整個班級和團隊的中堅力量,在帶動別的同學上面起到了極大的作用,讓我放心不少。謝謝。

5.  教學內容

工程。從第2次課程開始,教師持續地強調 這是工程課程,不是程式設計課程。程式設計的經驗對於專案的結果 起到了非常關鍵的作用,這一點從亮哥在耐撕團隊的作用、劉偉碩換組以後立即突破OneZero團隊的關鍵技術問題(資料庫連線和操作)、高鑫加盟暴打團隊以後團隊起死回生可以旁證。但是超越程式設計經驗的工程思想,才是本課程教學的重點。不少同學在學期中或學期末的時候表達了理解 工程控制的重要性,不過教師並不確認這種表達到底多少真誠,有多少可實施的願望。

為了強化工程的體會(以及降低技術風險),教師強制要求,不得采用需要探索的技術,只能使用現在已經熟練掌握的技術。直接要求而不討論,禁止了在統計文字的詞頻中使用 Hadoop、禁止了使用某種框架。教師也有過擔心,萬一同學們只會做console程式,連GUI和web前端都做不出,那麼產品的效果得多麼慘不忍睹。鄒欣老師教導我(大意如此)說,那就是願望和能力間的差距太大,還是能出來啥就做啥— 做出不來的,光想也是沒用,釋出才是硬道理。

還是為了強化工程的體會,教師特別若干次強調邊界,並在需求分析、功能列表、SCRUM中再次援引邊界。邊界是一個系統與外界的分隔也是連線,是允許呼叫的介面規範,支援的功能的集合,use case driven指定的整個工程的開始端,也是拒絕服務的依據。

估算和度量。對時間(PSP)、工作量(技術部落格字數累積、程式碼行數累積、進度條)的度量要求,對時間的(預計)估算要求。冉華同學的專案在時間和工作量估算上受到教師的直接指導,他的進步(至少體會上)非常明顯。工程思想要求所有的效果都是可觀測的,所有的猜測(模型)是可驗證的。計算機系的同學實驗經驗還遠遠不足,“我猜”而不驗證仍然經常出現。

以上兩點,是不限於軟體範圍的一般性工程思想,是教學中的重點。教師相信中國軟體工程學科教程[https://book.douban.com/subject/1653554/]中的觀點(大意),軟體工程與一般工程間的區別遠比我們通常認為的要小得多,應該首先注意到它是工程,其次才是軟體相關。

結對程式設計。一定程度上解決了某些同學程式設計基礎薄弱的問題,但是實施不持久。實施了一段以後,同學們以時間、地點、導師部署的工作量大 等理由開始搪塞。關於同學們對於知識的尊重和對訓練的輕視,後面會再談。由於此時團隊專案開始出現團體reciew和團體一起程式設計的情況,教師對於結對報告沒再堅持。

規範,文件排版,用詞和造句,變數命名。這些在前期有提及,並且安排了作業,但是在時間驅動團隊專案的壓力之下,教師和學生都放棄了這對規範的要求。

版本控制。要求使用github。同學們在團隊專案開始後,抱怨網路現狀和響應速度,紛紛放棄使用github,不過版本控制的習慣保留了下來。

技術部落格。要求發表在 cnblogs 上。有同學抱怨但是全都服從了。遵循雖然不見得最優但是並不明顯愚蠢的上級要求,也是成為工程師的一課。希望同學們在此能有收穫。

版權。我們提到了文字複製貼上的侵權問題,也討論到圖片引用。從同學們釋出的技術部落格文字和課堂爭論來看,並未就版權的界定(比如引用圖片是否算以“學習”為目的,不營利是不是就可以盜版)達成一致意見。在本課程中,教師視引起爭論為達到效果,不在教學中作更深入的探討。

6.  缺憾及體會

1)知識和訓練。同學們普遍而長期地忽視訓練。

同學們普遍而長期地忽視訓練,如果我們認可他們相對地更重視一些知識的話,雖然他們最重視的是感受(“這個老師真和藹,全心全意地愛學生,這樣的才是好老師”)和態度(“我反對我贊同,不轉不是中國人”)。決定成敗決定效果的,直接地不是感受和態度,而是技術。現在比較普遍地能夠接受的,即使在人民戰爭中,人民的認可如此重要,但是在最終和敵人刺刀相見的時候,意志遠不如技術重要。打架是個技術活,工程也是。頭纏紅帶如果只發生在臨期末了,改變不了戰局。

在課堂中,教師也屢次提到,知識是可以傳授的,告訴你你就知道,而技能是不能傳授,只能通過訓練習得。游泳、騎自行車、彈琴、程式設計,這些技能只能通過訓練獲得,你僅僅知道也是白扯。鄒欣老師在《構建之法》中有生動的比喻,一個在健身房裡參觀的學員,是不會自動長出一身肌肉來的,只要你不*主動*運動,親自克服阻力,無論教練對其他學員的教學方法有多麼地好,教練多麼地帥和態度友善,你的願望有多麼熱切。

例如,在本學期實際的教學中,同學們對於結對程式設計最初表現出強烈的輕視,覺得明白道理就行了。在工程實踐中,也傾向於樂於觀摩,而不希望投入時間;在課堂中,傾向於聽教師講單口相聲,“啊”地一拍大腿或者頻頻點頭,而不希望做作業。在課餘的專案中,我也注意到學生們普遍地具有這種估向,希望真專案、有實際用途的專案、有好的效果的專案,同時希望工作量要少,希望多學知識,而不是實踐知識。針對這一點,在課堂中,教師多次提到,資本家不會因為你會什麼知識而付你錢,只會因為你做了什麼而付錢。

對於訓練的否定態度,以前也經常有專案組的同學對我說,“老師,我還得學習呢。”也就是說在同學們的心目中,專案研發,不過是業餘的愛好,並不是學習的一部分,讀書考試才是真正的學習。下意識中,掌握了知識,或者把某書的電子版搞到手了,就完事大吉。其實這只是開始,甚至遠未開始。知識,從寫出程式碼第一行時,在實踐中,才真正開始掌握。知乎中有人問,“編譯原理和演算法導論是不是屠龍技有技而無龍可屠?”我在回答中說,“除非真正屠龍過,否則不能確定掌握了技術--做習題是不夠的。因此“有技(而無龍可屠)”是個偽命題。”道理是一樣的。

當然,我能夠理解,同學們經常看到世界充滿欺騙和吹噓,甚至我們已經習慣。說一套做一套,理論和實踐毫不相關,要求別人的道德準則和自己親自實踐的涇渭分明。不過,如果我們所做的和我們宣稱所相信的如此不同,我們得是多麼精神分裂啊。所以,試一試,按單一的原則生活,實踐你相信的原則。拒絕你不相信的。

知識與實踐(及訓練)應該是統一的。

2)主動地參與世界。積極性。同學們普遍高冷。

本學期有一個搶跑專案(把[http://www.cnblogs.com/xinz/p/3852177.html] 的量表做成APP或網上調查問卷,併發布在微信朋友圈中),有三個名額,但應者寥寥,最終只有兩位同學參與,並且有一位是教師單獨動員的。

這個搶跑專案初看很簡單,簡單到同學們不屑於擡起手指。這種傲慢在學習工作中也是普遍的,“顯然啊”是不少人的口頭語,頗有一種“你怎麼這麼笨就是不明白呢”,即使後來深入瞭解發現並不簡單甚至“顯然”自己錯了的時候,也氣勢不減。

簡單的專案不做,複雜的專案做不來。在課堂上也常這樣,顯而易見的問題不吱聲,稍微難的問題不敢吱聲。所以,沉默的大多數,寂靜的春天。假裝大人,掩飾自己的不足,故作淡定,不參與不表現,不評論不反對不支援。

第一次第二要求結對,很多同學不做;再三強調推動,終於做了,但是體會不樂意寫或不樂意多寫。要求互評效果更差,只有一兩位同學參與並保持。教師提供了“他山之玉”,轉引鄒欣老師整理的其他高校的技術部落格彙總,似乎沒有幾位同學看,從在課堂中對作業要求的表現可以猜測。

“主動地參與世界”是世界不放棄的前提。還是在知乎上看到的一個吐槽,某高校幾位女同學在大雨天被澆到了,而路上所有獨自撐著傘的男同學都靜靜地看著她們在雨裡走。有位回答得與我們剛剛提到的主題正相關,他說,你如果有求於人,要主動提出,否則別人會以為你享受雨中的散步;沒有人有閒工夫看你,所以我們根本不知道你在雨裡。“主動地參與世界”,不要期待世界來求你。絕大多數同學的技術遠沒有達到可以隱居的程度,不過作法上已經很有大師的樣子了。

3)主動地參與世界。人類語言和程式碼寫作。

課程要求同學們每週釋出技術部落格,課程還要求期末交課程論文。從技術部落格和現已看到的課程論文來看,篇幅都短得可憐。課程論文談體會,還沒有教師的體會一半兒長的同學,不覺得慚愧麼,或者教師該為這一學期讓你收穫如此地少而說聲抱歉?

不少同學可能會說,“沒有什麼好說的。”

拋掉我們課程中提到的,錯誤的承前省和代詞使用,是網路貼子主要的錯誤來源,認為讀者知道你所知道的資訊,是一個錯誤的假設。如果讀者已經知道你所知道的一切,那麼心有靈犀的情況下,溝通就毫無必要—也許你確實認為報告、技術部落格、論文,只是形式化的儀式而已。向別人解釋自己的動機、技術路線,在畢業論文和專案答辯中闡述你所認為的重點難點,不僅是使得別人瞭解你,也是評定專家確認你瞭解你所說的內容的重要手段。對於從北京到走向世界的途徑如果你說,“靠腳”或者“沒有必要,最好的我們都已經有了”,那麼別人至少了解你的方法論或者價值觀,而你說“那不顯然麼”,除了傲慢的態度,別人對你沒有任何新增的瞭解。

有個心理學或教育學故事告訴我們,不瞭解別人不是自私,而是幼稚。故事說,令孩子A觀察孩子B的行為,並回答問題。有個人對被觀察者孩子B展示糖果並放在抽屜裡,然後在孩子B短暫離開時把糖果從抽屜裡拿出來放到口袋裡。問孩子A,孩子B回來以後會到哪裡找糖果。有一些孩子A回答,孩子B會在口袋裡找糖果。這些孩子A並不知道,孩子B不知道糖果轉移這一資訊。

程式碼、文件、報告、技術部落格,都是告之另一些人,他們所不知道的資訊。主動地參與世界,在程式碼和人類語言寫作中充分預估別人可能不知道,展示自己的友善,而不是展示自己的聰明。

如果你不知道應該如何表達,或者表達哪些資訊,那麼多讀書,多讀別人的經驗之談,多讀程式碼,多看看別人是怎麼寫的。不要沉浸在自己的小世界裡,你不注意別人,就不知道別人需要什麼資訊,期待閱讀什麼。多想到別人期待什麼,而不是你意圖展示什麼。這樣,能避免寫作和程式碼詞不達意。你的個性和態度,沒有人樂於為此付錢。幫助別人,別人才會付錢給你;請我們欣賞你的個性和態度,你需要付錢給我們。

4)時間。快節奏,短迭代。時間驅動。對時間的估算和度量。

課程每週一次。也就是說,如果師生在此中間沒有任何溝通,那麼學生在此時所犯的錯誤,可能要7天之後才能得以糾正;學生是否理解糾正,需要再一個7天老師才能觀察到效果。如此往復,我們在一個學期16週中也不能交流多少東西。所以,提高工作節奏,以儘可能短的迭代來完成任務非常必要。這也是Agile/Xp方法論的核心之一,也是RUP接受的理念。

齊嘉亮、劉偉碩、濮成林和夏一鳴都採用過短迭代完成作業。在作業部置的第二天,就已經提交一個版本,教師(和鄒欣老師)給出的修改意見、增補的工作要求,在接下來本週過完以前再提交一次,可能根據修改意見再提交一次。這樣,別人一次作業,他們不僅多了兩三次的工作量(也即收穫),而且遠超這些,因為後面的幾次作業是在教師針對性的指導之下的。

相比之下,有些同學採取了等、靠、拖的策略。在作業截止時間最後幾分鐘提交,其中一個藉口是“我希望儘可能完美”――但是不會比教師直接指導下的修改更完美,並且展示完美不是我們學習的目的。教師給出修改意見以後,不少同學說“我會在下次/以後的作業中改正”,這基本等價於“老師,我已經給你留了面子,表達了充分的尊重,請不要逼我太甚”或者“我以後會改的,請不要再煩了我好咩”。如果那是錯誤,為什麼不在本次改正?如果這是你期待的希望的“真正的”專案,不改正的錯誤會導致你白做,甚至可能賠償損失。這種態度讓我想起郭大俠的女兒郭芙,她砍了楊過的右臂,然後哭鬧說,“我的確砍了你的胳膊,可是我被爹爹罵也罵了,對你道歉也道了,你還想怎麼樣啊。”郭芙之嬌橫可能連你也不能接受,不過那畢竟不是她本人的胳膊,而這是你本人的問題。

也有的同學會說,我改你指出的毛病已經夠費勁了,"你還想怎麼樣啊"。笑話又說,期末的突擊學習的難度,取決於你是複習還是預習。學生費勁、教師頻繁地提出修改要求,改了一個毛病又整出一個來,一方面是因為不改完第一個,第二個毛病無從改起;另一方面,實在是因為某些同學的基礎太差啊。好吧,那不全是你的責任,而是以前你的學校、學院、教師的責任,讓我們一起抱怨吧。然後靜等這個世界變得更美好…和寬容。

關於時間,鄒欣老師還提到釋出要求時間驅動。沒有截止時間的壓力,同學們不定哪天才能完成—一般是最後一天開始動手。夏一鳴同學在期末總結時感嘆,學期初的願望有兩個,其一是題目難道能循序漸進,其二是 如果太難,希望能放寬時限。一個也沒有實現,不過他大大地成熟了,已經進步到不再有這兩個願望,而是“老師是不是可以分配給我下一個任務了。”

時間要求是個硬線,在教學中,寧可縮小功能範圍、降低質量,也不能超時。就在要求的那個時間,無論如何,程式要釋出要可執行。我喜歡說的一句不太動聽的話,在規定的時間規定的任務必須交付,如果做得像屎一樣,就交付屎一樣的工作,並接受別人對我們屎一樣的評價。下次更努力一些,不要在這一次就求饒。

與時間相關的最後一個問題,同學們普遍缺乏對時間的估算和度量的意識,如果說對程式碼量的估算和度量還有那麼一點意識的話。時間是工程中最重要的資源(沒有之一,因為時間直接地就是生命,別的都不是),所以對於自己做類似專案的能力的度量應該持續進行,這也應該成為事後review諸葛亮會議的重要內容,並根據這種度量一次次在新專案開始前估算時間,在專案結束後對比事前估算與事後度量,增強下次的估算能力。自動控制中常用的PID方法、機器學習中各種基於經驗的方法、讀者故事裡鯊魚怕疼不敢撞玻璃那樣的浪漫的基本原理也大抵如此。我們怎麼能在工程中有時重視估算和度量,而對最重要的時間卻如此忽略。多麼精分啊。

5)規範

規範不止是程式碼規範,還有作業要求,用人類語言表述的作業要求的條目。

為什麼沒有一再地強調規範,因為同學們普遍地達不到更低的要求,所以教師放棄了規範這樣更高的要求。時間、工作量、工作報告質量、視訊,很多不能達到最低要求,有不少同學直接忽略部分作業條目,當沒看見。同學們根據工作量和時間調整要求,而不是根據要求調整投入的工作量和工作時間。

還是在知乎編譯原理是否屠龍技一問中,我這樣回答,“能找到的活兒太差的時候,覺察不到技術的必要。成天跟小孩打架,不用練力量敏捷抗打擊;成天蓋狗窩,不需要圖紙和水泥標號。如果理想就是這樣,龍只是傳說,屠龍技當然毫無用處。”如果你滿足於這樣的生活,不希望精益求精成為一個更優秀的工程師,我又有什麼法子。我當然知道優秀的教師能夠“有教無類”,“沒有差生,只有差教師”,可是,偏偏我不是優秀的教師,咱們可怎麼辦呢。

對於不完成作業的全部這一點,教師考慮過以更詳細和嚴厲的規則來應對:作業應該針對小項倒扣分,而不是全部作業都不完成才倒扣分。不過,教師擔心這會開啟獄警-囚徒模式,尤其學生是研究生階段的成年人,理應獲得這樣程度的尊重。

說起尊重,我想起一個故事。據說侵略者為了瓦解印弟安人,對戰士說,“你在部落裡有什麼樣的權力?”戰士回答,“我有衝鋒在前的權力。”衝鋒在前,是一種權力,這是尊重的來源。我尊重你是成年人,作法就是像對待成年人一定對待你,絕不稱你為“孩子”“那個孩子”“那些孩子”,絕不輕拍你的高貴的頭以示親暱;我尊重女性,作法就是像對待男性一樣對待女性,尊重她們衝鋒在前的權力,所有的愛護都無聲地宣佈“你是弱者,自覺承認”。

我尊重你,尊重你按約定完成任務的自覺和按規範完成的能力。你按約定和規範完成任務,是對我的尊重的尊重,也是對你自己衝鋒在前的權力的尊重。你之所以能看到的我的憤怒和失望,是因為你放棄了權利,你沒有侮辱了你自己也侮辱了我,也是因為我對自己的無能的認可和恐懼。

6)學生觀摩。現實,外界的限制。

鄒欣老師希望學生能夠觀摩final釋出和各次釋出,他希望退課的同學能回來看看,看看失去了什麼;他希望本科生也能來看看,看看可能在將來學到什麼。鄒欣老師還希望成績能夠嚴格執行平時作業的標準,並且平時作業應該佔到應該的比重。

這些期待,我很慚愧,沒能全部實現。作為主講教師,我切身體會其中的難處,有些超過了時間花費、知識結構和技能,進入了我們所隸屬的單位的組織結構(和課程體系)。課程教學只是上級(我不是在討論贊同或反對高校行政化)要求的諸多工作的一部分,還有很多別的工作,這並不是最主要的原因。更重要的原因是,如果那麼做,所付出的代價。不是克服困難所付出的努力,而是克服困難所需要承擔的後果。所以,所謂“盡我所能”“不惜一切代價”我從來也沒有臉去說,也不能以此要求我的同學們。

 

7. 總結

回望來時的路。構建之法東北師大站 2016春季學期,終於結束了。

第4周的時候,我曾經寫過雞湯如下,讚揚2位領跑同學和當時尚未放棄的18位同學。其實情形一直這樣艱難,從來也沒有改變。

他們的成績反映的是這樣的場景下的勝利:

    你是一位將軍,

    部隊彈盡糧絕,而且很餓;

    戰士戰術技能很差,裝備落後;

    行軍在敵國的沼澤裡,風聲鶴唳;

    敵人有空中支援,有坦克,有熱的飯菜和熱水;

    上級是沒腦的楊貴福,戰略垃圾,脾氣暴躁,

    他決定此刻立即開始,進攻前方的碉堡,既沒有迫擊炮也沒有照明彈,

    只有炸-藥-包。

    你的下級準備解散部隊,準備撤出戰場,準備起義反對你。

    你說,不惜一切代價,16周突襲。

    這就是4周以來的戰況,我們還活著。

    我們還有12周戰鬥。

    繼續衝鋒。

此刻,繼續衝鋒。

如果你為感想和收穫還不到教師的一半長度而慚愧,此刻,繼續衝鋒,不要等到下一次作業再改進。沒有下一次。

————————————————————

部落格會手工同步到以下地址:

[http://zhuanlan.zhihu.com/younggift]

[http://younggift.net/]

[http://blog.csdn.net/younggift]

[http://giftdotyoung.blogspot.com]


相關推薦

回望來時構建東北大站 2016春季學期

1.  前因 微軟鄒欣老師著有《構建之法:現代軟體工程》[https://book.douban.com/subject/26577755/]。第一版首版以前,我還不知道鄒老師是哪一位,就在網上曾經看到過有人轉引他的觀點,感到說得太有道理了,一拍大腿的感覺。比如他提到教

構建 第三章軟件工程師的成長

知識點 可維護 vid -s 評估 不同 fun 可靠 科研 本章理論和知識點:評價軟件工程師水平的主要方法 軟件工程把相關的技術和過程統一到一個體系中,叫“軟件開發流程”,軟件開發流程的目的是為了提高軟件開發、運營、維護的效率,以及提升用戶滿意度、軟件的可靠性和可維護性。

構建 第四章兩人合作

應用 結對編程 使用 一對一 測試 一個 比較 以及 領域 程序員寫的代碼最終是人在看,所以代碼規範很重要,原則是:簡明,易讀,無二義性。 不光是程序書寫的格式問題,還牽涉到程序設計、模塊之間的關系、設計模式等方方面面。 代碼復審的正確定義看代碼是否在代碼規範的框架內正確的

構建 第五章團隊和流程

min 這樣的 程序員 希望 成員 eat 貢獻 核心 不能 團隊有一致的集體目標,團隊要一起完成這目標。一個團隊的成員不一定要同時工作,例如接力賽跑。 團隊成員有各自的分工,互相依賴合作,共同完成任務。 軟件團隊有各種形式,適用於不同的人員和需求。基於直覺形成的團隊模式未

《20170906-構建現代軟件工程-閱讀筆記》

人員 移植 越來越大 軟件設計 用戶需求 原因 支持 貴的 需求分析 閱讀第一章使我知道了 1.軟件分為系統軟件,應用軟件和病毒軟件。            軟件=程序 + 軟件工程            2.軟件的特點:復雜性,抽象性,不可見性,易變性,服從性,非連續性,

2017090-構建現代軟件工程-閱讀筆記

軟件 可維護 unifi 軟件工程 筆記 瀑布模型 軟件維護 老板 ces 現代軟件工程 軟件 = 程序 + 軟件工程 程序 = 數據結構 + 算法 軟件工程包括了開發,運營,軟件維護的過程中的很多技術、做法、習慣和思想。軟件工程把這些相關的技術和過程統一到一個體系中,叫“

2017-09-10-構建現代軟件工程-閱讀筆記

參數 驗證 時間 第二章 軟件企業 功能 模塊 復雜 1.3 第一章 軟件= 程序+軟件工程 程序= 數據結構+算法 軟件企業 = 軟件+商業模式 軟件的特殊性:復雜性、不可見性、易變性、服從性、非連續性。 第二章 2.1單元測試: 2.1.1用VSTS寫單元測試 2.1

20170913-構建現代軟件工程-閱讀筆記

一個 管理 質量 常用 容易 高質量 目標 易用性 其它 軟件工程包括了開發、運營、維護軟件過程中的很多技術、做法、習慣和思想。軟件工程把這些相關的技術和過程統一到一個體系中,叫“軟件開發流程”,軟件開發流程的目的是為了提高軟件開發、運營、維護的效率,以及提升用戶的滿意度、

《20170914-構建現代軟件工程-閱讀筆記1》

筆記 bsp 量化 應用 pan class 包含 運營 有序 1.軟件= 程序+軟件工程 2.軟件工程定義:軟件工程是系統的、有序的·、可量化的方法應用到軟件的開發、運營和維護上的過程。   3.軟件工程包含以下領域:(1)軟件需求分析             (2)

20150914-構建現代軟件工程-閱讀筆記

玩具 過程 同時 測試的 問題 參數 修改 效率 個人 我閱讀了本書的第一章和第二章。第一章開篇引導了軟件工程的概念,又通過一則故事引導出了一個程序員編寫一個程序到需求變成一個軟件的過程。通過生動的舉例讓讀者生動的認識到了,什麽是程序,什麽是用戶,後面有了需求。把一個隨手的

20170914-構建現代軟件工程-閱讀筆記

舉例 原本 需要 最大的 軟件工程 別人 過程 想想 現在 我看了《構建之法:現代軟件工程》前四章,本來沒有接觸過軟件工程,以為這是一門很無聊也很沒有用的課程,但是通過上課和看書我發現,這裏面的內容並不是我想想的那樣,可能看著文字多,但是都很有趣,而且還給配圖,一點都不無聊

《20170914-構建現代軟件工程-閱讀筆記》

軟件工程 穩定 軟件 失敗 抽樣 屬於 閱讀 依賴 可見 第一章:   1.軟件=程序+軟件工程。   2.程序=數據結構+算法。   3.軟件企業=軟件+商業模式。   4.復雜的軟件有合理的軟件架構、軟件設計、實現,以及程序文件之間的依賴關系、編譯參數、鏈接參數,都屬於

構建現代軟件工程-閱讀筆記

角色 模式 不同 軟件設計 軟件工具 軟件企業 不同的 存在 設計 軟件=程序+軟件工程 軟件企業=軟件+商業模式 軟件工程包括以下領域:軟件需求分析、軟件設計、軟件構建、軟件測試和軟件維護 軟件工程是把系統的、有序的、可量化的方法應用到軟件的開發、運營和維護上的過程 軟件

20170915-構建現代軟件工程-閱讀筆記

企業 發的 復雜 數據 測試的 通過 結果 作者 開發 、第一章 軟件= 程序 + 軟件工程 軟件企業 = 軟件企業 + 軟件 + 商業模式 軟件開發的不同階段 1.玩具階段 2。業余愛好階段 3. 探索階段 4. 成熟的產業階段 軟件的特殊性:復雜性,不可見性,易變性,服

《20170918-構建現代軟件工程-閱讀筆記》

軟件工程 項目 意思 今天 技術 工作 工具 而是 原則 我今天閱讀了構建之法的第七章MSF: MSF的第一原則,就是所有信息都保留並公開,討論要包括所有涉及的角色,決定要公開並告訴所有人。 當然,對牽涉到的技術機密丶安全性等信息要采取必要的保護措施。 為共同的遠景而工作。

《20170920-構建現代軟件工程-閱讀筆記》)

規範 運營 風格 deb 可靠 下劃線 使用 錯誤 這一 1.軟件工程包括了開發、運營、維護軟件的過程中的很多技術、做法、習慣和思想。軟件工程把這些相關的技術和過程統一到一個體系中,叫“軟件開發流程”,軟件開發流程的目的是為了提高軟件開發、運營、維護的效率,以及提升用戶滿意

《20170924-構建現代軟件工程-閱讀筆記》

提高 定位 方向 方法測試 團隊 功能 合格 需要 遠的 項目經理 項目經理的作用 協調團隊成員的工作內容,把握產品定位和方向,解決用戶痛點,調節團隊中的矛盾,總控團隊的進度,使一個團隊加強交流。在一個團隊中,項目經理是必不可少的一個重要角色。一個合格的項目經理需要

20170927-構建現代軟件工程-閱讀筆記

div 參數 覆蓋 驗證 構建 機器 失敗 測試的 基本 單元測試的幾個特性: 單元測試應該在最基本的功能/參數上驗證程序的正確性。 單元測試必須由最熟悉代碼的人來寫。 單元測試過後,機器狀態保持不變。 單元測試要快 單元測試應該產生可重復、一致的結果。 獨立性---單

2017/9/29-構建現代軟件工程-閱讀筆記2

ack 所有 協作 目的 負責 第5章 建設 信息 rational 第5章 團隊和流程 軟件團隊的模式:主治醫師模式、明星模式、社區模式、業余劇團模式、秘密團隊、特工團隊、交響樂團模式、爵士樂模式、功能團隊模式和官僚模式。 我個人的理想團隊模式建設則是和功能團隊模式一樣

《20170930-構建現代軟件工程-閱讀筆記》

ive 產品開發 分析 del 功能性 app 需求 推廣 生命 第八章 需求分析 軟件需求: 1、獲取和引導需求 2、分析和定義需求 3、驗證需求 4、在軟件產品的生命周期中管理需求 或 1、對產品功能性的需求 2、對產品開發過程的需求 3、非功能性需求 4、綜合需求 軟