[譯]在軟體開發行業6年後我改變了主意

我改變主意的事情：

• 當您在具有不同經驗水準的團隊中工作時，有類型的語言會更好
• 站會實際上對于關注新手很有用。
• 隻要 Sprint 回顧是為了實際的路線修正（即“天哪，結果很糟糕！”）而不是一些可怕的“靈活”/“渣滓大師”浪費每個人的時間，Sprint 回顧就會有它們的位置。
• 軟體架構可能比什麼都重要。一個好的抽象的糟糕實作不會對代碼庫造成任何損害。糟糕的抽象或缺失的層會導緻一切腐爛。
• Java 并不是一種可怕的語言。
• 聰明的代碼通常不是好的代碼。清晰勝過所有其他問題。
• 糟糕的代碼可以用任何範式編寫
• 所謂的“最佳實踐”是有上下文的，并不廣泛适用。盲目跟風讓你白癡。
• 在不需要使您成為糟糕工程師的情況下設計可擴充的系統。
• 靜态分析很有用
• DRY 是關于避免特定問題，而不是其本身的最終目标。
• 一般來說，RDBMS > NoSql
• 函數式程式設計是另一種工具，而不是靈丹妙藥。

我一路走來的意見

• YAGNI, SOLID, DRY. In that order.
• 鉛筆和紙是最好的程式設計工具，但很少使用
• 交易純度以換取實用性通常是一個很好的選擇
• 添加更多技術很少是好的選擇
• 直接與客戶交談總是能在更短的時間内以更高的準确度揭示更多有關問題的資訊
• “可擴充”這個詞在軟體工程師的頭腦中有一種神秘而令人震驚的力量。僅僅一句話就能讓他們陷入堕落的瘋狂。使用這個詞來證明殘酷的行動是合理的
• 盡管被稱為“工程師”，但大多數決策都是純粹的貨物崇拜，沒有支援分析、資料或數字
• 90%——也許是 93%——的項目經理，明天可能會消失，要麼沒有效果，要麼效率淨增。
• 在進行了 100 多次采訪之後：采訪徹底崩潰了。我也不知道如何真正讓它變得更好。

舊觀點不變：

• 強調代碼風格、linting 規則或其他細節的人是瘋狂的怪人
• 代碼覆寫率與代碼品質完全無關
• Monoliths 在大多數情況下都非常好
• TDD 純粹主義者是最糟糕的。他們脆弱的小頭腦無法處理不同工作流程的存在。