Image

今天朋友拋了一篇文章過來，覺得不錯所以整理一下轉貼上來：
Development slowness in big and legacy applications [and how to hurry it up]

這篇文章整理了一些作者觀察到大規模老舊專案（或是大公司）之所以變「慢」的原因，一口氣列了八項，這邊也稍微貼過來給各位朋朋：

  • 複雜度
  • 跨團隊溝通
  • 安全與隱私
  • 程式碼標準
  • 開會
  • 金絲雀帶來的麻煩
  • 數據驅動決策
  • 花在開發的時間變少

接著我們也簡單看過每一項的內容。首先是複雜度，有很多可能會發生的問題：

  • 沒有人熟悉這個產品（有太多的功能或細節，沒有人能夠全面了解，就容易出錯）
  • 複雜的架構和抽象化（持續堆疊功能從不重構，直到專案變成一團混亂）
  • 客製化的建置和自動化（雖然應該是自動化的，但實務上常常會需要調整，導致菜鳥需要花更多時間了解）
  • 工具過剩（大量的內部工具，例如自製測試小工具。導致菜鳥要上手的時間變得更長，還需要額外維護）
  • 衝突（越多人做同個專案，就會有越多衝突要解，越多的內容要溝通，產生更多的延遲）
  • 建置時間（專案越大，就跑得越久。而且相關優化的優先度通常都不高）

針對以上問題，作者也提出一些可能的解決方案：

  • 分配一些資深人員專門處理建置優化、內部工具和持續整合等 DX （使用者體驗）部分
  • 把內部工具當成公開工具（產品）一樣地維護
  • 建立菜鳥入職流程和文件，幫助他們上手
  • 不要忽視技術債，合理地安排重構還債
  • 讓工程師去參加一些黑客松或創意週之類的

除了複雜度的篇幅比較長以外，其他七項相對就短一點。這邊就整合在一起（我就不需要再開一張卡片，哈）

跨團隊溝通 現在的大公司常常會有全球工程師分批進行維護，導致溝通時間也會因為時差被拉長。這時候就可以限制負責同個功能的團隊所在位置（例如把某功能的工程師集中放在某兩個區域，美國或印度之類的）

安全與隱私 為了保證符合資安和隱私規範，需要等待很多審查時間。這時候可以聘請一位資安相關的專業人員負責，並且盡可能簡化審查流程

程式碼標準 使用靜態程式碼分析工具，例如 JavaScript 的 ESLint 或 C# 的 StyleCop（沒有用過，過幾天再來研究）

開會、開會、開會 設定議程、限定會議時間、只邀請必要的參與者、事先發送會議文件、事後發送會議摘要

金絲雀ㄟ麻煩 現在常會看到先給小部分使用者使用新功能，OK 之後再增加使用者數量。但逐步增加使用者數量 = 花更多的時間，雖然使用 feature flags 可以緩解（切換速度變快，不用等重新上板），但作者唯一解是同時推進多項工作 QQ

數據驅動的決策 小公司可以冒險，但大公司的決策通常需要看到數字才能進行，例如提出 A/B 測試，並且有成效說服上層之後才可以繼續推。這一項作者沒有提出解決方案…

花在工作的時間變少 員工必須要參加團隊活動、全體會議、培訓、1 on 1 之類的，累積起來佔用了許多時間。這一項也沒有提出處理方式，可能無法迴避

以上人工簡短地整理了文章提到的內容，但每一項作者都有用兩三段來說明他觀察到的部份，有興趣的朋友推薦可以閱讀一下，然後想想自己家有沒有遇到相似的狀況，又是怎麼解決的（或可以怎麼解決？）

我個人看到最後覺得：隨著專案規模變大，速度變得笨重也是無法避免的事。就像文章最後提到的：

A startup with five customers doesn’t need five production environments or complicated feature-gate tooling. But applications with 10 million customers, where problems can cost billions, certainly do.

（一家只有五個客戶的初創公司並不需要五個生產環境或複雜的功能開關工具。但對於擁有一千萬客戶的應用程式來說，問題可能會造成數十億的損失，這些工具肯定是必要的。）

那麼，今天的轉貼就先到這邊。明天見 ><"**