赛马会彩票网靠谱吗:《高效程序員的45個習慣》總結

c85e 6年前發布 | 10K 次閱讀 CentOS 7

赛马会一码三中三资料 www.iclqr.icu 一、敏捷——高效軟件開發之道 

 

  • 敏捷的精神:它要求團隊中的每一個人(包括與團隊合作的人)都具備職業精神,并積極地期望項目能夠獲得成功。它并不要求所有人都是有經驗的專業人員,但必須具有專業的工作態度——每個人都希望盡最大可能做好自己的工作。 
  • 敏捷開發就是在一個高度協作的環境中,不斷地使用反饋進行自我調整和完善。 

二、態度決定一切 

 

1、 做事

  • 符合標準不是結果。敏捷團隊重結果勝于重過程。 
  • 指責不能修復bug 。把矛頭對準問題的解決辦法,而不是人。

2、 欲速則不達

  • 不要墜入快速的簡單修復之中。要投入時間和精力保持代碼的整潔、敞亮。 
  • 不要急于修復一段沒能真正理解的代碼。這種 +1/-1  的病癥始于無形,但是很快會讓代碼一團糟。要解決真正的問題,不要治標不治本。 
  • 所有的大型系統都非常復雜,因此沒有一個人能完全明白所有的代碼。除了深入了解你正在開發的那部分代碼之外,你還需要從更高的層面來了解大部分代碼的功能,這樣就可以理解系統各個功能塊之間是如何交互的。

3、 對事不對人

  • 我們每個人都能有一些極好的創新想法,同樣也會萌生一些很愚蠢的想法。 
  • 脫離實際的反方觀點會使爭論變味。若對一個想法有成見,你很容易提出一堆不太容易發生或不太實際的情形去批駁它。這時,請先捫心自問:類似問題以前發生過嗎?是否經常發生?

4、 排除萬難,奮勇前進 

  • 做正確的事。要誠實,要有勇氣去說出實情。有時,這樣做很困難,所以我們要有足夠的勇氣。

三、學無止境 

 

5、 跟蹤變化

  • 跟蹤技術變化。你不需要精通所有技術,但需要清楚知道行業的動向,從而規劃你的項目和職業生涯。 
  • 許多新想法從未變得羽翼豐滿,成為有用的技術。即使是大型、熱門和資金充裕的項目也會有同樣的下場。你要正確把握自己投入的精力。

6、 對團隊投資

  • 你參加了一個課程或者研討班之后,所學的知識如果不用,往往就會忘記。所以,你需要和其他團隊成員分享所學的知識,把這些知識引入團隊中。 
  • 堅持有計劃有規律地舉行講座。持續、小步前進才是敏捷。稀少、間隔時間長的馬拉松式會議非敏捷也。

7、 懂得丟棄

  • 打破舊習慣很難,更難的是自己還沒有意識到這個問題。丟棄的第一步,就是要意識到你還在使用過時的方法,這也是最難的部份。

8、 打破沙鍋問到底

  • 不停地問為什么。不能只滿足于別人告訴你的表面現象。要不停地提問直到你明白問題的根源。 
  • 你可能會跑題,問了一些與主題無關的問題,這樣的問題是沒有任何幫助的。要問到點子上。

9、 把握開發節奏

  • 解決任務,在事情變得一團糟之前。保持事件之間穩定重復的間隔,更容易解決常見的重復任務。 
  • 在每天結束的時候,測試代碼,提交代碼,沒有殘留的代碼。

四、交付用戶想要的軟件

 

10、 讓客戶做決定

  • 讓你的客戶做決定??⒄?、經理或者業務分析師不應該做業務方面的決定。用業務負責人能夠理解的語言,向他們詳細解釋遇到的問題,并讓他們做決定。

11、 讓設計指導而不是操縱開發

  • 一旦開始了編碼,一切都會改變。設計及其代碼實現會不停地發展和變化。 
  • 好的設計應該是正確的,而不是精確的。也就是說,它描述的一切必須是正確的,不應該涉及不確定或者可能會發生變化的細節。它是目標,不是具體的處方。
  • 即使初始的設計到后面不再管用,你仍需設計:設計行為是無價的。正如美國總統艾森豪威爾所說:“計劃是沒有價值的,但計劃的過程必不可少?!痹諫杓乒討醒笆怯屑壑檔?,但設計本身也許沒有太大的用處。

12、 合理地使用技術

  • 考慮引入新技術或框架之前,要先考慮幾個方面:
    • 這個技術框架真能解決這個問題嗎?
    • 你將會被它拴住嗎?一些技術是賊船,一旦你使用了它,就會被它套牢,再也不可能回頭了。
    • 維護成本是多少?
  • 每一門技術都會有優點和缺點,無論它是開源的還是商業產品、框架、工具或語言,一定要清楚它的利弊。

 

13、 保持可以發布

  • 任何時候只要你沒有準備好,那就是敵人進攻你的最佳時機。 
  • 在團隊里工作,修改一些東西的時候必須很謹慎。你要時刻警惕,每次改動都會影響系統的狀態和整個團隊的工作效率。

14、 提早集成,頻繁集成

  • 絕不要做大爆炸式的集成。 
  • 提早集成,頻繁集成。代碼集成是主要的風險來源。要想規避這個風險,只有提早集成,持續而有規律地進行集成。 
  • 如果你集成得不夠頻繁(比如一周一次,甚至更糟),也許就會發現整天在解決代碼集成帶來的問題,而不是在專心寫代碼。如果你集成的問題很大,那一定是做得不夠頻繁。

15、 提早實現自動化部署

  • 一開始就實現自動化部署應用。使用部署系統安裝你的應用,在不同的機器上用不同的文件測試依賴的問題。質量保證人員要像測試應用一樣測試部署。 
  • 部署一個緊急修復的bug 應該很簡單,特別是在生產服務器的環境中。你知道這會發生,而且你不想在壓力之下,在凌晨三點半,你還在手工部署系統。

16、 使用演示獲得頻繁反饋

  • 維護一份項目術語表。在項目的開發過程中,從術語表中為程序結構——類、方法、模型、變量等選擇合適的名字,并且要檢查和確保這些定義一直符合用戶的期望。 
  • 清晰可見的開發。在開發的時候,要保持應用可見(而且客戶心中也要了解)。每隔一兩周,邀請所有的客戶,給他們演示最新完成的功能,積極獲得他們的反饋。

17、 使用短迭代,增量發布

  • 增量開發。發布帶有最小卻可用功能塊的產品。每個增量開發中,使用1 ~ 4 周左右迭代周期。

18、 固定的價格就意味著背叛承諾

  • 軟件項目天生就是變化無常的,不可重復。如果要提前給出一個固定的價格,就幾乎肯定不能遵守開發上的承諾。 
  • 基于真實工作的評估。讓團隊和客戶一起,真正地在當前項目中工作,做具體實際的評估。由客戶控制他們要的功能和預算。 

五、敏捷反饋 

 

19、 守護天使

  • 一些開發者會對單元測試有意見:畢竟,有“測試”這個詞在里面,毫無疑問這應該是其他人的工作。從現在開始,忘掉“測試”這個詞。就把它看作是一個極好的、編寫能產生反饋的代碼的技術。 
  • 使用自動化的單元測試。好的單元測試能夠為你的代碼問題提供及時的警報。如果沒有到位的單元測試,不要進行任何代碼設計和代碼修改。 
  • 人們不編寫單元測試的很多借口都是因為代碼中的設計缺陷。通常,抗議越強烈,就說明設計越糟糕。

20、 先用它再實現它

  • 設計的一個重點是:確定什么是成功地實現特定功能的最低成本。程序員很容易走向另一個極端——一些不必要的過于復雜的事情——測試優先會幫助我們,防止我們走偏。
  • 先用它再實現它。將TDD 作為設計工具,他會為你帶來更簡單更有實效的設計。

21、 不同環境,就有不同問題

  • 不同環境,就有不同問題。使用持續集成工具,在每一種支持的平臺和環境中運行單元測試。要積極地尋找問題,而不是等問題來找你。

22、 自動驗收測試

  • 為核心的業務邏輯創建測試。讓你的客戶單獨驗證這些測試,要讓它們像一般的測試一樣可以自動運行。

23、 度量真實的進度

  • 我們不應該去計算工作量完成的百分比,而應該測定還剩下多少工作量沒有完成。不要用不恰當的度量來欺騙自己或者團隊。要評估那些需要完成的待辦事項。 
  • 在你最后真正完成一項任務時,要清楚知道完成這個任務真正花費的時間。在為下一個任務估計工作量時,可以根據這次經驗調整評估。

24、 傾聽用戶的聲音

  • 不管它是否是產品的bug ,還是文檔的 bug ,或者是對用戶社區理解的 bug ,它都是團隊的問題,而不是用戶的問題。
  • 每一個抱怨的背后都隱藏了一個事實。找出真相,修復真正的問題。 

六、敏捷編碼 

 

25、 代碼要清晰地表達意圖

  • 開發代碼時,應該更注重可讀性,而不是只圖自己方便。代碼閱讀的次數要遠遠超過代碼編寫的次數,所以在編寫的時候值得花點功夫讓它讀起來更簡單。 
  • 要編寫清晰的而不是討巧的代碼。向代碼閱讀者明確表明你的意圖,可讀性差的代碼一點都不聰明。

26、 用代碼溝通

  • 用注釋溝通。使用細心選擇的、有意義的命名。用注釋描述代碼意圖和約束。注釋不能代替優秀的代碼。

27、 動態評估取舍

  • 動態評估權衡??悸切閱?、便利性、生產力、成本和上市時間。如果性能表現足夠了,就將注意力放在其他因素上。不要為了感覺上的性能提升或者設計的優雅,而將設計復雜化。
  • 如果現在投入額外的資源和精力,是為了將來可能得到的好處,要確認投入一定要得到回報(大部分情況下,是不會有回報的)。 
  • 過早的優化是萬惡之源。

28、 增量式編程

  • 在很短的編輯、構建、測試循環中編寫代碼。這要比花費長時間僅僅做編寫代碼的工作好得多??梢源唇ǜ憂邐?、簡單、易于維護的代碼。 
  • 要像重構你的代碼那樣,重構你的測試,而且要經常重構測試。

29、 保持簡單

  • 開發可以工作的、最簡單的解決方案。除非有不可辨駁的原因,否則不要使用模式、原則和高難度技術之類的東西。 
  • 要將目標牢記在心:簡單、可讀性高的代碼。強行讓代碼變得優雅與過早優化類似,統一會產生惡劣的影響。

30、 編寫內聚的代碼

  • 讓類的功能盡量集中,讓組件盡量小。要避免創建很大的類或組件,也不用創建無所不包的大雜燴類。

31、 告知,不要詢問

  • 面向過程的代碼取得信息,然后做出決策。面向對象的代碼讓別的對象去做事情。 
  • 作為某段代碼的調用者,開發人員絕對不應該基于被調用對象的狀態來做出任何決策,更不能去改變該對象的狀態。這樣的邏輯應該是被調用對象的責任,而不是你的。 
  • 告知,不要詢問。不要搶別的對象或是組件的工作。告訴它做什么,然后盯著你自己的職責就好了。

32、 根據契約進行替換

  • 通過替換代碼來擴展系統。通過替換遵循接口契約的類,來添加并改進功能特性。要多使用委托而不是繼承。 

七、敏捷調試

 

33、 記錄問題解決日志

  • 維護一個問題及其解決方案的日志。保留解決方案是修復問題過程的一部分,以后發生相同或類似問題時,就可以很快找到并使用了。 
  • 如果通過搜索Web ,發現沒人曾經遇到同樣的問題,那也許是搜索的方法有問題。

34、 警告就是錯誤

  • 將警告視為錯誤。簽入帶有警告的代碼,就跟簽入有錯誤或者沒有通過測試的代碼一樣,都是極差的做法。簽入構建工具中的代碼不應該產生任何警告信息。

35、 對問題各個擊破

  • 很多應用的代碼在編寫時沒有注意到隔離問題這一點,使得分離變得特別困難。此時,最好花一些時間把關注的代碼提取出來,而且創建一個可讓其工作的測試環境。 
  • 對問題各個擊破。在解決問題時,要將問題域與其周邊隔離開,特別是在大型應用中。

36、 報告所有的異常

  • 處理或是向上傳播所有的異常。不要將它們壓制不管,就算是臨時這樣做也不行。在寫代碼時要估計到會發生的問題。

37、 提供有用的錯誤信息 

  • 展示有用的錯誤信息。提供更易于查找錯誤細節的方式。發生問題時,要展示出盡量多的支持細節,不過別讓用戶陷入其中。 

八、敏捷協作 

 

38、 定期安排會面時間

  • 使用立會。立會可以讓團隊達成共識。保證會議短小精悍不跑題。 
  • 要保證會議議題不發散,每個人都應該只回答下述三個問題:
    • 昨天有什么收獲?
    • 今天計劃要做哪些工作?
    • 面臨著哪些障礙? 
  • 雖然大多數團隊需要每天都碰頭,但對于小型團隊來說,這樣做可能有點過頭了。不妨兩天舉行一次,或者一周兩次,這對小團隊來說足夠了。

39、 架構師必須寫代碼

  • 設計會隨著時間而演進,如果忽略了應用的現狀(它的具體實現),要想設計一個新的功能,或者完成某個功能的提升,是不可能的。 
  • 優秀的設計從積極的程序員那里開始演化?;謀喑炭梢源瓷釗氳睦斫?。不要使用不愿意編程的架構師——不知道系統的真實情況,是無法展開設計的。 
  • 不要運行任何人單獨進行設計,特別是你自己。

40、 實行代碼集體所有制

  • 在團隊中實行任務輪換制,讓每個成員都可以接觸到不同部分的代碼,可以提升團隊整體的知識和專業技能。

41、 成為指導者

  • 成為指導者。分享自己的知識很有趣——付出的同時便有收貨?;箍梢約だ鶉嘶竦酶玫某曬?,而且提升了整個團隊的實力。 
  • 如果一直在就同一個主題向不同的人反復闡述,不妨記錄筆記,此后就此主題寫一篇文章,甚至是一本書。

42、 允許大家自己想辦法

  • 給別人解決問題的機會。指給他們正確的方向,而不是直接提供解決方案。每個人都能從中學到不少東西。

43、 準備好后再共享代碼

  • 準備好后再共享代碼。絕不要提交尚未完成的代碼。故意簽入編譯未通過或是沒有經過單元測試的代碼,對項目來說,應被視為玩忽職守的犯罪行為。

44、 做代碼復查

  • 復查所有的代碼。對于提升代碼質量和降低錯誤率來說,代碼復查是無價之寶。如果以正確的方式進行,復查可以產生非常實用而高效的成功。要讓不同的開發人員在每個任務完成后復查代碼。 
  • 同樣的功能,不同開發人員的代碼實現可能不同。差異并不意味著不好。除非你可以讓某段代碼變得更好,否則不要隨意批評別人的代碼。 
  • 如果不及時跟進討論中給出的建議,代碼復查是沒有實際價值的??梢園才鷗嵋?,或者使用代碼標記系統,來標識需要完成的工作,跟蹤已經處理完的部分。

45、 及時通報進展與問題

  • 及時通報進展與問題。發布進展狀況、新的想法和目前正在關注的主題。不要等著別人來問項目狀態如何。

九、尾聲:走向敏捷

 

Bug Fix 

 本文由用戶 c85e 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!