1. 程式人生 > >現代軟件工程—構建之法---第四章:練習與討論

現代軟件工程—構建之法---第四章:練習與討論

人在 做出 鍵盤 工具 等級分 閱讀 nbsp 現實 是個

1 、結對項目的案例與論文

  論文已閱讀。

2、性格對合作的影響

  我的MBTI為:ESTJ 管家型——掌控當下,讓各種事務有條不紊地進行

  ESTJ型的人高效率地工作,自我負責,監督他人工作,合理分配和處置資源,主次分明,井井有條;能制定和遵守規則,多喜歡在制度健全、等級分明、比較穩定的企業工作;傾向於選擇較為務實的業務,以有形產品為主 ;喜歡工作中帶有和人接觸、交流的成分,但不以態度取勝;不特別強調工作的行業或興趣,多以職業角度看待每一份工作。ESTJ型的人很善於完成任務;他們喜歡操縱局勢和促使事情發生;他們具有責任感,信守他們的 承諾。他們喜歡條理性並且能記住和組織安排許多細節。他們及時和盡可能高效率地、系統地開始達到目標。ESTJ型的人被迫做決定。他們常常以自己過去的經歷為基礎得出結論。他們很客觀,有條理性和分析能力,以及 很強的推理能力。事實上,除了符合邏輯外,其他沒有什麽可以使他們信服。同時,ESTJ型的人又很現實、有頭腦、講求實際。他們更感興趣的是“真實的事物”,而不是諸如抽象的想法和理論等無形的東西。他們往往對 那些認為沒有實用價值的東西不感興趣。他們知道自己周圍將要發生的事情,而首要關心的則是目前。因為ESTJ型的人依照一套固定的規則生活,所以他們堅持不懈和值得依賴。他們往往很傳統,有興趣維護現存的制度。 雖然對於他們來說,感情生活和社會活動並不像生活的其他方面那樣重要,但是對於親情關系,他們卻固守不變。他們不但能很輕松地判斷別人,而且還是條理分明的紀律執行者。 ESTJ型的人直爽坦率,友善合群。通常他 們會很容易地了解事物,這是因為他們相信“你看到的便是你得到的”。

3.是否需要有代碼規範

1. 這些規範都是官僚制度下產生的浪費大家的編程時間、影響人們開發效率, 浪費時間的東西。(反駁)

也許規範對個人的開發效率會有負面影響。但是放到整個團隊層面上,它恰恰是能夠節約大家的編程時間的東西。那個版本管理員花費的三、四個小時,本來可以用來測試、用來修正bug,卻因為我的代碼不規範而被浪費掉了。

  2.我是個藝術家,手藝人,我有自己的規範和原則。(反駁)

一個人的那也叫規範?最多叫個人習慣。足球裏有一句話,沒有哪個球員比球隊更重要。項目組也一樣,沒有哪個人的個人習慣大過團隊規範。
就我那個錯誤來說,我也有我的規範和原則。事實上,我犯錯誤的那次所使用的格式化規範,也是我原來所在 項目組的通用規範。但是,在新的項目組裏,它變成了我的個人習慣,並且,我的個人習慣導致團隊工作受到了嚴重的影響。如果你是那個新項目組的成員,你能忍我?

  3.規範不能強求一律,應該允許很多例外。(反駁)

規範應該盡量一致;即使有例外,也只能是少數情況,而不能是很多例外。
說到這個例外,我想起另一個例子來。古人取“字”的時候,常常按兄弟次序取“伯仲叔季幼”,例如“季常”、“幼常”。但有一次有個哥們就問我:為什麽這個哥哥字“叔x”,而弟弟字“伯y”?是不是史書寫錯了?
這就是規範中“例外”情況導致的混淆甚至是混亂。
  4.我擅長制定編碼規範,你們聽我的就好了。(反駁)

如果對規範有意見,可以通過一定方法修訂並發布新的規範。但是在新的規範發布之前,請遵守舊的規範。

4.代碼復審的討論

5 .閱讀別人的代碼有多難

關於自己編寫代碼時,如何讓代碼更易於閱讀與維護

代碼維護一定要多註意接口設計。註意你的接口,接口設計完美,整個系統就是完美的。因為即便你出錯,做的復雜,他們也封裝在完美的接口後面而不會對整個系統造成太大影響。接口設計就是一切。

6.結對編程中不好的習慣——你經歷過麽,如何提醒同伴改進

*不拘小節的人:兩人在一起近距離的工作,但是卻不註意個人衛生和互相尊重。開始合作前,吃了很多的大蒜就來了。

*喜歡發號施令的人:總是對敲鍵盤的人說:“到末行,加個反括號,然後......”。他不去關註解決方法和下一步該怎麽做,而過度關註一些編程細節。

*拼寫糾錯者:坐在你的旁邊,糾正你輸入的每個錯誤字符。當然,他沒有時間來真正進行導航。

*深藏不露者:僅僅自己敲著代碼而不告訴別人他在做什麽。領航員不得不靠自己去弄懂代碼。關於該用什麽方法,該選擇哪種設計,領航員和實施者之間完全沒有交流。

*跳躍很大的人:他們喜歡在代碼中進行大範圍的跳躍,這樣領航員便不知道進行到哪裏了。

1.首先要肯定對方的提醒,其次也向他提出,我們應該首先解決問題,等一下再一起糾正這些編程規範。
2.好像是開車的時候被人不斷提醒一樣,有的時候這點確實讓人心焦,尤其是很多的拼寫錯誤都是一時手誤而且編程工具會自動提醒,當遇到這樣的夥伴時,我覺得應該引導他像別的方向註意,在編程前就提出一定的問題希望幫忙留意。讓其把重點放在代碼上。
3.以前在另一個課程設計時做過項目經理,這點倒是經歷過,當時還是大二,編程水平高的同學沒有現在這麽多,一個組裏往往會有一個超過別人很多的人,他的思路和使用的新的技術往往讓人一頭霧水。結構和代碼也不太理解。這個時候應該做出改變的不只是實施者,還有看代碼的人,要直接提出疑問,讓實施者回答,並且多進行討論交流意見,並且希望在編程中註釋。
4.在看別人編程時,修改代碼時,因為不熟悉別人的代碼,修改時大幅度的跳躍和轉換,讓人不知道整個工程的現狀。這個時候可以適當讓實施者停下,和他討論修改或者跳躍的原因,理清思路。

現代軟件工程—構建之法---第四章:練習與討論