03 March 2014

開發者都會經手很多專案,有些專案目標很確定,而且時程很短,這種專案命名時就不會太難,甚至可以用編號來命名。不過很多時候產品名稱是後來才決定的,這時通常會替新專案取個代號 (code name) 來稱呼。代號當然是各個組織都有一套偏好的習慣,我自己也有一套代號的命名規則,從務實的角度出發。

規則一:短

專案代號一定要短,為什麼?因為它會出現在你程式的所有地方:

  • 檔案的目錄名稱,你每天都會 cd 一次以上,scripts 也會一直寫到。
  • git repository 名稱、branch 的名稱... 等等
  • 在 Java 裡,所有 class 檔都會有 package,因此每個 .java 檔都會包含 code name
  • 你可能會用 code name 當做物件的名稱,比方說 FooUtils
  • 相關的設定檔 (例如 xml) 會一而再再而三的寫到

專案代號幾乎滲透到所有程式碼,你每天都會鍵入數十次甚至上百次。如果你取代號名稱要十個字母,那你是在整自己。不只打字容易出錯,而且多花無謂的時間鍵入。我個人最偏好 4 個字母,不過最長 6 個字母左右也還 ok,再長下去就不太行了。

  • 好的例子 - kaze
  • 壞的例子 - cappuccino

規則二:好唸

這個規則和規則一相關,專案代號除了程式裡會出現,你每天跟你的團隊溝通都會用這個詞,簡單好唸很重要。如果你取了個很饒舌的,或是跟其他的常用字唸起來很像的,這只會增加溝通的成本。雖然只是個單字,但日積月累下來也是很可觀的。我個人偏好純母音結尾的單字,而那些字母間或是結尾有那種不發聲的子音的單字我都盡量避免。用頭文字去組代號名是 ok 的,但是不要拼出像是 SQL 這種大家對唸法很有爭議的單字。

  • 好的例子 - mio
  • 壞的例子 - scsi

規則三:好拼

滿足了規則一、二,通常規則三也自動滿足了,如果你字母少的話,通常不會拼錯字。如果你的單字唸起來單純,沒有夾那種發音很弱的子音,你也不會漏打那些字母。專案代號不見得會是字典裡有的單字,為避免拼錯還是選簡單的組合吧。

  • 好的例子 - anta
  • 壞的例子 - antarctica

規則四:與產品無關

這個規則有點不直覺。不過如果你手上有專案超過二年的,也許會有點感覺了 - 專案的目標和需求是會變的,這在新創公司更容易出現。專案的方向錯了,重新調整再出發是很有可能的,如果你當初取的代號跟原產品有關,忽然切換就會很彆鈕。

比方說原本要做一個 email 的 app,當初便取了個叫 postman 的代號,後來你們公司 pivot 了,因為發現原來 email 裡的廣告才是好賺的方向。轉換過程中,你的程式碼盡可能的重用,裡面滿滿的是 postman 這單字,但其實功能都是些廣告相關的了。要重構 postman 這個單字也是不切實際的,只會累死自己而已。

因此我建議選擇代號不要跟產品的內容或方向有關,甚至是個無意義的詞更好。找不到好詞你可以取公司附近的地名,地名跟大部份的事物都沒什麼相關性。

  • 好的例子 - nanji (南極)
  • 壞的例子 - postman

小結

專案代號通常是產品名尚未定案前取的。它會用在溝通,用在程式碼的各個角落。也許你會結合你的座右銘或是你對專案的期許在代號內,不過,為了開發與溝通的效率,我建議還是簡化代號的名稱吧。


回響

可以用 Tag <I>、<B>,程式碼請用 <PRE>