《構建之法》讀書筆記(三)

2022-06-09 02:45:08 字數 750 閱讀 9210

《構建之法》,讀這本書教會了我在團隊開發時的團隊合作。

首先是**規範:1.**風格規範。 2.**設計規範。

一.**風格規範

1.縮排:一般用四個空格的距離,從可讀性來說正好。

2.行寬:行款可以限定為100字元。

3.斷行與空白的{}行:盡量

if(a)

else

4.分行:不要把多條語句放在第一行。

5.命名:在變數名中不要提到型別或其他語法方面的描述;避免過多描述;避免過多的修飾詞。

6.下劃線:可以用來標註。

7.大小寫:型別/函式/類的命名為大寫字母開頭,變數命名可以第乙個字母小寫,隨後單詞第乙個字母大寫。

8.注釋:好好寫注釋,因為程式不是你再寄乙個人看的,你的團隊其他成員也要看。

二.**設計規範

1.**有沒有依賴某一平台,是否影響移植。

2.有沒有無用的**可以清除。

下學期,我們要組成團進行開發,那麼,關於團隊模式,我更希望我們的團隊模式為社群模式,可以根據興趣去完成不同的模組,而不是明星模式,乙個人的閃光點蓋住其他人,我們應該要每個人都發揮各自的長處,更不要官僚模式,否則會造成不可磨滅的後果。同時,也希望在開發中運用上這些**格式,切記團隊合作不是乙個人在開發,有什麼問題要及時溝通,要多溝通,這樣問題才能乙個乙個地解決,希望下學期能學有所成。

這就是我今天的讀書筆記,獲益良多。

構建之法讀書筆記(三)

project manager 專案經理乙個神秘的角色,他就是夾在銷售人員與程式設計師之間的溝通媒介,銷售人員的方式程式設計師理解不了,程式設計師只想安安靜靜的敲 因此就出現乙個角色 專案經理,負責的就是將銷售人員的方式轉換為程式設計師可以理解的形式,這樣開發的效率就會大大的提高,同時專案經理不僅僅...

構建之法讀書筆記三

在做專案開發上,團隊協作尤為重要。之前也說過 需求分析 的問題,但在讀書過程中我發現了乙個問題,假如使用者方出現了需求更改,或者在原有的基礎上新增了乙個棘手的需求,導致工作變更怎麼辦?回答還是協商。坦白說看到現在我能用兩個詞概況軟體工程要幹的事情 開發與溝通。但要是跟使用者協商溝通,雖然能達到乙個妥...

構建之法 讀書筆記三

現在已經讀完這本書了,感覺自己又充實了。首先了解了敏捷開發的基本原則 1.盡早並持續地交付有價值的軟體以滿足顧客需求。2.歡迎需求的變化 3.經常發布可用的軟體,間隔時間盡可能的短 4.團隊每天共同工作 5.以有進取心的人為專案核心 6.面對面的交流 7.發布可用的軟體 8.領導 團隊和使用者應該能...