敏捷的世界觀

敏捷的世界觀

有一種至關流行的軟件方法學要求對一個項目分配35種不一樣的角色，包括架構師、設計人員、編碼人員、文檔管理者等。敏捷方法卻背道而馳，只需一個角色：軟件開發者，也就是你。項目須要什麼你就作什麼，你的任務就是與客戶緊密協做，一塊兒開發軟件。敏捷依賴人，而不是依賴於項目的甘特圖和里程錶。

這大概是全棧工程師吧，哈哈哈~

爲作事而工做

惡魔：「出了問題，第一重要的是肯定元兇。找到那個白癡！一旦證明了是他的錯誤，就能夠保證這樣的問題永遠不會再發生了。」

在敏捷的團隊中，你們的重點是作事。你應該把重點放到解決問題上，而不是指責犯錯者上面糾纏。

你能夠從本身先作起。若是一個開發者帶着抱怨或問題來找你，你要了解具體的問題，詢問他你能提供什麼樣的幫助。這樣簡單的一個行爲就清晰地代表你的目的是解決問題，而不是追究責任，這樣就會消除他的顧慮。你是給他們幫忙的。這樣，他們會知道每次走近你的時候，你會真心幫助他們解決。他們能夠來找你把問題解決了，固然還能夠繼續去別處求助。

若是你找人幫忙，卻沒有人積極響應，那麼你應該主動引導對話。解釋清楚你想要什麼,並清晰地代表你的目的是解決問題，而不是指責他人或者進行爭辯。

天使：把矛頭對準解決問題的辦法，而不是人。這是真正由用處的正面效應。

切身感覺

• 敢於認可本身不知道答案，這會讓人感受放心。
• 一個重大的錯誤應當被看成是一次學習而不是指責他人的機會。
• 團隊成員們在一塊兒工做，應互相幫助，而不是互相指責。

平衡的藝術

• 「這不是個人錯」這句話不對，「這都是你的錯」這句話更不對
• 若是你沒有犯過任何錯誤，就說明你可能沒有努力去工做。
• 開發者和質量工程師爭論某個問題是系統自己的缺陷仍是系統加強功能致使的，一般沒有多大的意義。與其如此，不如趕忙去修復它。
• 若是一個團隊成員誤解了一個需求、一個API調用，或者最近一次會議作的決策，那麼也許就意味着團隊的其餘成員也有相同的誤解。要確保整個團隊儘快消除誤解。
• 若是一個團隊成員的行爲一再傷害了團隊，則他表現得很不職業。那麼，他就不是在幫助團隊向解決問題的方向前進。在這種狀況下，咱們必需要求他離開這個團隊。
• 若是大部分團隊成員（特別是開發領導者）的行爲都不職業，而且他們對團隊目標都不感興趣，你就應該主動從這個團隊中離開，尋找更適合本身發展的團隊（這是一個有遠見的想法，不必眼睜睜地看着本身陷入一個「死亡之旅」的項目中。

欲速則不達

惡魔：「你不須要真正地理解那塊代碼，它只要可以工做就能夠了。哦，它須要一個小小的調整。只要再結果中再加上幾行代碼，它就能夠工做了。開工吧！就把那幾行代碼加進去，它應該能夠工做。」

咱們常常會遇到這種狀況，出現一個Bug而且時間緊迫。快速修復確實能夠解決它——只要新加一行代碼或者忽略那個列表上的最後一個條目，它就能夠工做了。拙劣的代碼工人會不假思索地改完代碼，而後快速轉向下一個問題。優秀的程序員會挖掘更深一層，盡力去理解爲何這裏必需要加一，更重要的是，他會想明白會產生什麼其餘影響。

Beware of land mines

在工做壓力之下，不去深刻了解真正的問題以及可能的後果，就快速修改代碼，這樣只是解決表面問題，最終會引起大問題。短時間看，它彷佛是有效的。但從長遠來看，經過幾年的積累，代碼裏有着成千上萬的補丁修復，在這樣髒亂的代碼中添加新的功能或修復Bug，會讓開發者難逃脫髮的噩運。

Don't Code in isolation

孤立很是危險，不要讓開發人員徹底孤立地編寫代碼。若是團隊成員花些時間閱讀其餘同事寫的代碼，他們就能確保代碼是可讀和可理解的，而且不會隨意打補丁的代碼。實行代碼評審，不只有助於代碼更好理解，並且是發現bug最有效的方法之一。

Use unit tests

另外一種防止代碼難懂的重要技術就是單元測試。單元測試幫助你很天然地把代碼分層，分紅不少可管理的小塊，這樣就會獲得設計更好、更清晰的代碼。更深刻項目的時候，你能夠直接閱讀單元測試——它們是一種可執行的文檔。有了單元測試，你會看到更小、更易於理解的代碼模塊，運行和使用代碼，可以幫助你完全理解這些代碼。

天使：「不要墜入快速的簡單修復之中。要投入時間和精力保持代碼的整潔、敞亮。」

切身感覺

• 在項目中，代碼應該是很亮堂的，不該該由黑暗死角。
• 你也許不知道每塊代碼的每一個細節，或者每一個算法的每一個步驟，可是你對總體的相關知識有很好的瞭解。
• 沒有任何一塊代碼被警惕線或者「切勿入內」的標誌隔離開。

平衡的藝術

• 你必需要理解一塊代碼是如何工做的，可是不必定須要成爲一位專家。只要你能使用它進行有效的工做就足夠了，不須要把它看成畢生事業。
• 若是有一位團隊成員宣佈，有一塊代碼其餘人都很難看懂，這就意味着任何人（包括原做者）都很難維護它。請讓它變得簡單些。
• 不要急於修復一段沒能真正理解的代碼。這種補丁的病症始於無形，可是很快就會讓代碼一團糟。要解決真正的問題，不要治標不治本。
• 全部的大型系統都很是複雜，所以沒有一我的能徹底明白全部的代碼。除了深刻了解你正在開發的那部分代碼以外，你還須要從更高的層面來了解大部分代碼的功能，這樣就能夠理解系統各個功能塊之間是如何交互的。
• 若是系統的代碼已經惡化，能夠參考排除萬難，奮勇前進一章

對事不對人

惡魔：「你在這個設計上投入了不少精力，爲它付出不少心血。你堅信它比其餘任何人的設計都棒。別聽他們的，他們只會把問題變得更糟糕。」

你極可能見過，對方案設計的討論失控變成了情緒化的指責——作決定是基於誰提出了這個觀點，而不是權衡觀點自己的利弊。咱們來看看對一個明顯的錯誤有哪些常見的反應。

• 否認我的能力。
• 指出明顯的缺點，並否認其觀點。
• 詢問你的隊友，並提出你的顧慮。

第一種方法是不可能成功的。你那樣指出問題根本不會對他的水平有任何提升，反而會致使他之後不再會提出本身的任何想法了。第二種方法至少觀點明確，但也不會給多少幫助，甚至遭來反駁致使被打臉。而第三種方法，沒有譴責，沒有評判，只是簡單地表達本身的觀點。

在一個須要緊密合做的開發團隊中，若是能稍加註意禮貌對待他人，將會有益於整個團隊關注真正有價值的問題，而不是勾心鬥角，誤入歧途。咱們每一個人都能有一些極好的創新想法，一樣也會萌生一些很愚蠢的想法。

Negativity kills innovation

負面的評論和態度扼殺了創新。咱們每一個人都會有好的想法，也會有不對的想法，團隊中的每一個人都須要自由地表達觀點。即便你的建議不被全盤接受，也能對最終解決問題有所幫助。不要懼怕受到批評。記住，任何一個專家都是從這裏開始的。

你不須要很出色才能起步，可是你必須起步才能變得很出色。

集體決策確實很是有效，但也有一些最好的創新源於頗有見地的我的的獨立思考。若是你是一個有遠見的人，就必定要特別尊重別人的意見。咱們並非建議你限制會議決策，只是你不該該成爲獨斷獨行的首席架構師的傀儡。

能欣賞本身並不接受的想法，代表你的頭腦足夠有學識。

下面是一些有效的特殊技術：

• 設定最終期限：若是你正在參加設計方案討論會，或者是尋找解決方案時遇到問題，請設定一個明確的最終期限，這樣的時間限制能夠防止人們陷入無休止的理論爭辯之中，保證團隊工做的順利進行。同時應該現實一點：沒有最好的答案，只有更合適的方案。設按期限可以幫你在爲難的時候果斷作出決策，讓工做能夠繼續進行。
• 逆向思惟：團隊中的每一個成員都應該意識到權衡的必要性。一種客觀對待問題的辦法是：先是積極地看到它的正面。而後再努力地從反面去認識它。目的是要找出優勢最多缺點最少的那個方案，而這個好辦法能夠儘量地發現其優缺點，這也有助於少帶我的感情。
• 設立仲裁員：在會議的開始，選擇一個仲裁員做爲本次會議的決策者。每一個人都要有機會針對問題暢所欲言。仲裁員的責任就是確保每一個人都有發言的機會，並維持會議的正常進行。仲裁員能夠防止明星員工操縱會議，並及時打斷假大空式發言。若是你本身沒有積極參與此次討論活動，那麼最好退一步作會議的監督者。仲裁員應該專一於調停，而不是發表本身的觀點（理想狀況下不該在整個項目中有既得利益）。固然這項任務不須要嚴格的技術技能，須要的是和他人打交道的能力。
• 支持已經作出的決定：一旦方案被肯定了，每一個團隊成員都必須通力合做，努力實現這個方案。每一個人都要時刻記住，咱們的目標是讓項目陳工知足用戶需求。客戶並不關心這是誰的主意——他們關心的是，這個軟件是否能夠工做，而且是否符合他們的指望。結果最重要。設計充滿了妥協（生活自己也是如此），成功屬於意識到這一點的團隊。工做中不感情用事是須要剋制力的。

天使：「對事不對人。讓咱們驕傲的應該是解決了問題，而不是比較誰的主意更好。」

切身感覺

• 一個團隊可以很公正地討論一些方案的優勢和缺點
• 你不會由於拒絕了有太多卻顯得方案而傷害別人
• 也不會由於採納了某個不甚完美（可是更好的）解決的方案而被人忌恨

平衡的藝術

• 盡力貢獻本身的好想法，若是你的想法沒有被採納也無需生氣。不要由於只是想體現本身的想法而對擬定的好思路多此一舉。
• 脫離實際的反方觀點會使爭論變味。若對一個想法有成見，你很容易提出一堆不太可能發生或不太實際的情形去批駁它。這時，請先捫心自問：相似問題之前發生過嗎？是否常常發生？
• 也就是說，你必須評判那些場景發生的可能性有多大。想要支持或者反駁一個觀點，有時候你必須先作一個原型或者調查出它有多少的贊成者或反對者。
• 在開始尋找最好的解決方案以前，你們對「最好」的含義要先達成共識。在開發者眼中的最好，不必定就是用戶認爲最好的，反之亦然。
• 只有更好，沒有最好。儘管「最佳實踐」這個術語處處在用，但實際上不存在「最佳」，只有在某個特定條件下更好的實踐。
• 不帶我的情緒並非要盲目地接受全部的觀點。用合適的詞和理由去解釋爲何你不贊同這個觀點或方案，並提出明確的問題。

排除萬難，奮勇前進

惡魔：「若是你發現其餘人的代碼有問題，只要你本身內心知道就能夠了。畢竟，你不想傷害它們，或者惹來麻煩。若是他說你的老闆，更要格外謹慎，只要按照他的命令執行就能夠了。」

假如要你修復其餘人編寫的代碼，而代碼很難理解也很差使用。你說應該繼續修復工做，保留這些髒亂的代碼呢，仍是應該告訴你的老闆，這些代碼太爛了，應該通通扔掉呢？

也許你會跳起來告訴周圍的人，那些代碼說多麼糟糕，但那只是抱怨和發泄，並不能解決問題。相反，你應該重寫這些代碼，並比較重寫先後的優缺點。動手證實（不要只是嚷嚷）最有效的方式，是把糟糕的代碼放到一邊，馬上重寫。列出重寫的理解，會有助於你的老闆（以及同事）認清當前形勢，幫助他們獲得正確的解決方案。

當發現問題時，不要試圖掩蓋這些問題。而要有勇氣站起來，說：「我如今知道了，我過去使用的方法不對。我想到了一些方法，能夠解決這個問題——若是你有更好的想法，我也很樂意聽一聽——但可能會花多些時間。」你已經把全部對問題的負面情緒哦愛豬腦後，你的意圖很清楚，就是尋找解決方案。既然你提出你們努力來解決問題，那就不會有任何爭辯的餘地。這樣會促進你們去解決問題。也許，他們就會主動走近，提供幫助。更重要的是，這顯示出了你的真誠和勇氣，同事你也贏得了他們的信任。

天使：「作正確的事。要誠實，要有勇氣去說出實情。有時，這樣作很困難，因此咱們要求足夠的勇氣。」

切身感覺

• 勇氣會讓人以爲有點不自在，提早鼓足勇氣更須要魄力
• 但有些時候，它是掃除障礙的惟一途徑，不然問題就會進一步惡化下去。

• 鼓起勇氣，能讓你從恐懼中解脫出來

  平衡的藝術

• 若是你說天快要塌下來了，但其餘團隊成員都不贊同。反思一下，也許你說正確的，但你沒有解釋清楚本身的理由。
• 若是你說天快要塌下來了，但其餘團隊成員都不贊同。考慮一下，他們也許是對的。
• 若是設計或代碼中出現了奇怪的問題，花時間去理解爲何代碼會是這樣的。若是你找到了解決方法，但代碼仍然使人費解，惟一的解決辦法是重構代碼，讓它可讀性更強。若是你沒有立刻理解那段代碼，不要輕易地否認和重寫它們。那不是勇氣，而是魯莽。
• 當你勇敢的站出來時，若是受到了缺少背景知識的抉擇者的地址，你須要用他們可以聽懂的話語表達。「更清晰的代碼」是沒法打動生意人的。節約資金、得到更好的投資回報，避免訴訟以及增長用戶利益，會讓論點更有說服力。

• 若是你在壓力下要對代碼質量做出妥協，你能夠指出，做爲一名開發者，你沒有職權毀壞公司的資產（全部代碼）。