軟件開發人員創建了一個“反模式”的概念，以警告其他人不該做什么。想想舊地圖上“此處危險”的標簽。無論你做什么，都不要在這里航行。
多年的來之不易的經驗歸結為如何不去構建代碼，如何不去設想架構或如何不去設計數據庫架構的簡明描述。這些反模式已經變得非常有用，以至于其在開發人員之間傳播，并且與描述應該如何操作的功能設計模式一樣受到重視。
軟件項目管理有自己的“反模式”：看似合理的做法，但來之不易的經驗表明，實際上我們不應該這樣做。當然，與編寫代碼相比，運行一個項目和管理一個團隊并不是一門科學。一些反模式是彼此的鏡像：它們命令你接受同時避開同樣的事情。但這些反模式真正要求你做的是適度。太多的想法——不管它有多好——在管理團隊方面效果都不理想。
以下內容是軟件開發管理的11個反模式。認為這些反模式是看似合理的習慣，但當你管理開發團隊時要避免。
“團隊中沒有自我”的反模式
羅伯特•弗羅斯特(Robert Frost)喜歡說，修建好的圍欄能造就好鄰居。我們需要自己的空間，開發人員也是如此。人們總是傾向于在一個團隊中增加更多的開發人員，希望更多的人手能夠使工作變得輕松。但是，最終開發人員之間經常發生矛盾，為更新相同的代碼段而爭執。突然間，代碼審查工作就不斷增加，沒有人想要逐行檢查并合并代碼。
微服務架構有許多缺陷，但它卻可以為開發人員提供一個呼吸空間。開發人員可以在代碼的各個部分獨立工作。他們可以提交代碼，創建測試并繼續推進工作，而無需與其他人員保持同步。將開發人員拆分，并讓他們在自己的空間工作，會產生重大影響。
“分而治之”的反模式
當開發人員最終需要讓各自的代碼協同工作時，讓他們分開各自工作的唯一問題開始顯現。突然，一個API提供字符串，而另一個API卻需要整數。或者，也許一個團隊希望數據是在行中，而另一個團隊卻希望數據是在列中。有很多方法可以解釋白板上的簡易草圖。當然，所有測試都通過了，因為每個小組都用自己的想法為自己的代碼編寫了測試。
解決方案是更集中的管理和更集中的測試。一些團隊指定一些開發人員不斷監控集成工作，以確保所有工作盡可能順利地組合在一起。讓零件協同工作與構建各個零件同等重要。讓開發人員朝著同一方向前進本身就是一項工作。
“追隨你愿景”的反模式
如果我設想將來要設計出一些漂亮和吸引人的代碼，并且我有足夠預算，那么，我就會聘請一個開發團隊來編寫代碼。每個開發人員都清楚創造性天才的爆發力，他們可以為整個堆棧提供整體愿景。每個開發人員都知道，這之后是一段想象的超能力時期，在這段時期，每個功能似乎都可以在幾行代碼中完成。我們多少次啟動代碼編輯器，并開始向這個光明的遠景奔跑?
這就是為什么我們需要一種方法——這種方法迫使我們拋開輝煌的夢想，然后詳細地勾勒出計劃。然后，當我們第二天或下周總結工作時，我們可以認識到這些缺陷。制定計劃可能是一項真正的苦差事，但它比調試代碼更快。不要只是坐在那低頭工作。
“照章行事”的反模式
對于每種方法，都有一些書籍、會議和顧問隨時告訴你必須做什么，以及無論如何要避免做什么。他們非常擅長以絕對權威的方式傳達這些規則。
麻煩的是，沒有什么能完全符合他們的規則。你可以寫出幾個月的規范，但是當你幾乎完成這些規范時，你總會發現一些新的角度或問題。您可以嘗試保持靈活性和敏捷性，但是在規劃階段您無法預測較容易解決的一些問題。但總會有問題解決的時候。
最好的管理者會選擇一種方法，然后找到預測該方法失效的途徑。我們所有人都不能一直這樣做，但是當我們這樣做時，我們確實感覺已經找到了一種途徑。
“信任過程”的反模式
雖然軟件開發有其神奇的時刻，即所有事情都按時匯集在一起，但是由于擔心破壞這一創造性過程而不跟蹤細節工作，這可能會產生一些后果。安裝新數據庫花了多長時間?該團隊何時承諾來重新設計單點登錄API?有多少人正在檢查代碼，以重構上一次Sprint代碼編寫周期所遺留的技術債?
負責任的人總會列出一長串的障礙、困難和延誤工作的問題。領導面臨的挑戰在于找到一種優雅的方式來觀察工作中正在發生的情況，并通過跟蹤足夠多的細節來做出明智的決策。軟件開發的衡量指標可能非常不精確，但只要您不期望過多，這些指標就會讓您掌握誰在從事什么工作。
“你無法管理那些不能進行衡量的工作”反模式
這是一句老話，但今天聽起來仍不過時，這要歸功于人們對數據重要性的日益關注。并不是說，軟件的衡量指標不好;只是這些指標沒有捕捉到所有正在進行的工作。很久以前，管理人員試圖計算開發人員所編寫的代碼行數，之后，開發人員很快就想出了如何添加額外的注釋或其他非功能性的點綴來增加他們的工作量。
如今，一些管理者將任務分配了一些抽象的“點數”，然后在一個季度或一年結束時計算這些點數。但首先，找出合適的點數幾乎和解決問題一樣困難。最核心的團隊要求開發人員以點數來競標工作，讓他們相互競爭，以尋求更準確的評估。這對團隊友情或合作毫無幫助。
最大的危險是，開發人員會避免去接最難或最難以預測的工單，因為他們知道這些工單會使他們陷入困境，在季度末或年末他們將無法得到足夠的點數。解決方案是不要過分相信這些指標。如果愿意，跟蹤這些點數，但不要將它們視為價值的絕對衡量標準。
“愚蠢的協調一致是小智慧的騙人伎倆”反模式
開發人員需要自由。如果你問他們，他們會直截了當告訴你，他們不希望有人限制其創新能力和影響其設計優秀的新代碼。
問題在于，如果讓開發人員在他們自己的設備上工作，則他們將朝不同的方向推進。這就是我們需要一些標準的原因。讓代碼具有一致性的優點很容易理解。如果代碼的模式和視覺節奏是可預測的，則代碼更具可讀性。
可以自動執行一些最佳解決方案。一些代碼編輯器(例如Atom)會使用規則來重新格式化所有代碼，以符合規定的規則。(另請參見ESLint。)這樣可以避免開發人員擔心一些標準的細節，同時確保結果足夠清晰。
“標準將拯救你”的反模式
軟件標準現在風靡一時。每個新開發人員通常都會遇到更全版本的編碼規則。例如，Airbnb平臺的JavaScript代碼規則版本就很受歡迎。
但標準往往會激起憤怒和怨恨，給開發人員另一個進行爭執的理由。他們喜歡在代碼審查過程中抨擊這些標準，為那些最小的和無關緊要的問題反復說某些行的代碼。例如，Airbnb平臺的某個人花時間思考并編寫有關在代碼中插入空格的規則。必須在大括號內插入一個空格(19.11)，但禁止在方括號內(19.10)插入空格。如果你認為開發人員不會花時間為瑣事而爭執，那么你就沒有注意到這一點。他們喜歡使用“標準”這個詞，因為非標準代碼可能會讓每個人都死于像埃博拉這樣的病毒。
許多這些所謂的標準純粹是為了美觀，對代碼執行速度或代碼是否能得到正確答案都沒有任何影響。編譯器或解釋器會忽略額外的空格。您可以做的最糟糕的事情就是大膽推行一些標準，但這些標準對運行代碼的質量幾乎沒有影響。所有關于空格位置的美學討論都只適用于人類，其目的是阻止人們過多地爭論。如果您要推行一些標準，請讓標準簡單易于遵循，并且只關注具有實際意義的細節。
“簡化堆棧”的反模式
在代碼庫中使用某些規則的最簡單方法之一就是堅持使用一種語言，且僅使用一種語言。一切東西都是一致的，每個人都可以輕松閱讀。每個所聘用的人都具有相同的語言技能，每個人都相處融洽。
這是一個很好的想法，遵循該想法是有道理的。棘手的問題是，當你想要打破這些規則時，該怎么做。總會有一些新的庫或功能豐富的開源代碼完全符合您的要求——但它卻是用另一種語言編寫的。
如果你很嚴格，你會維護代碼庫的純度，但代價是犧牲快速而高效地完成某些工作。最后，用戶不會閱讀任何代碼。他們只關心代碼的功能。有時，在代碼庫中容忍一些差異是有意義的——如果這可以讓用戶滿意的話。這種挑戰在于，知道何時進行妥協是值得的。
“讓開發人員選擇工具”的反模式
克里斯(Chris)喜歡新的函數語言，更嚴格和更多類型檢查則更好。帕特(Pat)希望編寫幾乎是機器代碼的低層代碼。鮑勃(Bob)喜歡上一個標題中的所有內容。
他們都能和睦相處嗎?不!哦，在一個流程圖中看起來很簡潔的微服務架構中，可將來自許多不同語言的代碼整合在一起。許多語言可以轉換為在JVM或JavaScript引擎上運行的東西，從而可以將每個人喜歡的語言鏈接到一個大的blob中。
在全新項目開始時，具有靈活地語言選擇能力，將使您更受歡迎。當Kotlin語言的忠愛者離開團隊，然后PHP語言的死忠接手了他們無法閱讀的代碼時，問題就出現了。即使你可以讓團隊具備合適的技能，如果JavaScript程序員需要查看用Swift編寫的代碼，則他們會發現自己在沼澤中跋涉。
要注意，不要過于開放和包容。
“積極性是成功的關鍵”反模式
為什么我旁邊的那個家伙寫了兩倍長的代碼，而不是添加一個可在一行中就實現功能的標準庫?因為老板在git存儲庫中添加了一個tripwire軟件包，強制對庫目錄所添加的任何內容進行額外審查，并且那些負責審查的人被認為是反復無常的混蛋。
幾個星期之后，我看到同一個人巧妙地提出，將工單分成多個部分，可獲得價值兩倍的“點數”，這個“點數”是一種虛擬獎勵，每個人都在努力積累，以證明他們的工資是合理的。他精通于拉取請求，支持工單和敏捷性指標。
因此，盡管激勵團隊對于軟件項目的成功至關重要，但找出真正能激勵你開發人員的東西，這可能是一個謎中之謎。我們可以嘗試將開發人員集中起來，并讓他們交付客戶最終想要的東西，但開發人員也有自己的想法。他們比我們更了解這些工具。我們最好是來培養一種伙伴關系，并努力培養他們對大局的理解。然后，我們期盼他們能盡最大努力將抽象目標轉化為數百萬行整潔、經過測試且相對無錯誤的代碼。
京公網安備 11010502049343號