i'm 安追

原題：11 Tips of My Beginner (Not Best) Practices in a Project.

最近參與一個被操得不成人形快樂的專案使用CodeIgniter開發, 由於有一些前人開發的歷史包袱因素, 因此有了一些我覺得下個版本需要改善、或是我認為值得重構的地方。在這邊做一下筆記, 希望以後在開發時以我小小記憶體的腦袋不會遺忘。 

1. 把各個階段的測試機器設為第一階的subdomain。

alpha.projectName.domain.com
beta.projectName.domain.com
production.project.domain.com

或者更簡化成

a.projectName.domain.com
b.projectName.domain.com
p.projectName.domain.com

由於現在的瀏覽器都有智慧型輸入搜尋, 這樣的網址命名方式可以在開發時縮短你打網址的時間, 積少成多, 聚沙成塔啊。

2. API的Controller與頁面的Controller應該要分開。

由於先前的設計與架構上缺少對大量使用Ajax的考量, 所以在controller的繼承上API與頁面的controll都繼承相同的controller, 這樣會導致有些不必要的資料被render, 如果Ajax呼叫的很頻繁應該就會看出效能的差異了。所以僅僅只需要互相傳遞data的API Controller應該要額外設計並額外繼承。也可能要考慮在API中i18n或是其他東西是否多餘, 而只需要將必須的config讀進來就可以了。

3. helper、library應該要切開

這次因為在設計考量時因為helper用到的不多, 就直接寫在library裡面, 也因為沒有覺得這個helper應該歸在哪的class, 就變成了現在的成果。雖然設計模式告訴我們摻在一起做灑尿牛丸啊笨蛋! 不該為了用模式而用模式, 也不該為了想重構而重構, 但是未來若有機會再重構一次時應該要好好的切開或許會更漂亮一些。

4. 與Front-End Developer (FED) 合作

Front-End Developer在Web 2.0以後已經成為不可或缺的角色, 但是backend與frontend要如何合作是一個蠻重要的課題。雖然蠻多Framework都推出了像Smarty一樣的樣板引擎, 可以直接在原始碼中鍵入{variable}這樣的變數來取得值, 讓FED可以直接在編輯HTML或JavaScript時可以直接看到字樣, 但是這樣似乎也沒有我們這次的做法來的舒服。

我請FED建立一個叫做fed_config.php的檔案, 這個檔案裏面包含著許多像是$name、$email這樣的變數, 然後FED利用include_once函數來將其include進來, 接著FED就可以想拿怎樣的值就可以拿了, 我們只要訂好變數的名稱就相當好溝通了。

當然, 這前提是FED要裝WAMP或LAMP來進行測試, 而且他還要有取PHP值的小常識, 也就是至少看的懂啥叫<?php echo $name;?>。

或許你會問: 這樣Visual Designer怎麼辦? 這是個好問題, 因為類Smarty採用{name}這樣的作法就是要協助網頁的視覺設計師在其編輯介面上也可以直覺式的編輯, 但是這問題目前因為敝公司的FED與VD合作無間中, 所以這問題可以被降低它的優先順序。

5. Log、Log、Log!

Log的有依照等級定義, 像是debug、info、warning和error, 這在CodeIgniter裡面就少了warning這個等級, 或許似乎沒這麼必要, 不過應該要多點層級讓人可以直接自訂似乎會比較方便, 或許這也是因為歷史包袱因素, 在最新版的CodeIgniter或許已經改變我還沒跟上, 不過在看過log4php之後, 深深覺得下次有機會應該要整合log4php進去CodeIgniter裡面, 因為單用CodeIgniter的log function實在需要花費一段時間再好好客製化一番。

6. Exception、Exception、Exception!

Exception是我這次花最多時間的地方, 也是我最不喜歡卻很重要的一個部分。因為一個web網站要考量的點很多, 要注意的事情與特殊情形更是多到難以掌握, 尤其是與網站介接的模組一多, 惡夢就到了。在Exception的處理上我覺得使用Java的方式來try catch和throw感覺架構最漂亮也比較不會miss掉一些沒考慮到的case。

7. 錯誤處理

當錯誤發生時要怎樣處理? 回傳錯誤代碼(Error Code)? 強制導引(利用JavaScript強制轉頁, 儘管使用者是開啟iframe時產生錯誤)使用者至錯誤頁面並顯示錯誤代碼?

這沒有標準答案, 只是強制導引使用者至錯誤頁面並顯示錯誤代碼是一個統一並且比較方便好開發的方式。

8. 資料型態

我們都知道資料型態很重要, 但是由於在這次專案中SPEC裡的資料型態全都被訂為String(字串), 所以有些資料在轉換型態時還必須要使用擔心轉換失敗時的錯誤處理。這樣的結果就變成了設計時的方便, 卻造成了實作上的困難與阻礙, 同時也可能損耗了不必要的效能。

9. 出Build時能用Build Script做好的就先做好

專案快結束時才有時間做了一些小工具以及重構前人寫的Build Script, 有些讓人覺得厭煩卻不得不做的小事情在開發階段因為沒有先用Build Script和小工具來幫忙, 想當然爾, 在自命為海賊王藝術家的工程師們心情連帶受影響後當然會造成了開發的效率大幅減緩。於是我寫了個Java小程式讓Front-End不用再經歷console.log這種IE不理的語法錯誤發生時卻會被開defect的痛苦，或是把某個語言當作預設的語言複製進去該在的資料夾等等。

這些該做的事應該在一開始就做好, 真的, 工欲善其事, 必先利其器。 

10. Unit Test

身為一個developer, 而且在強者我前同事York寫了一篇Engineering：為什麼Startup更需要自動化測試後, 其實更應該要早點做好unit test才不會讓自己在開發時洞踩不停, 所以PHPUnit會被排在高優先權與CodeIgniter整合的名單中。至於像是使用Selenium來做一些網頁上的automation test則是已經完成, 但是我目前只會簡單粗淺的部分, 要深究似乎又要花一點時間了。

11. 文件很重要, 溝通才是王道

這絕對不是因為要湊十一個而寫的一項。寫文件很重要, 不論是L1、L2或是L3的SPEC, 都是把你做的事情記錄下來讓你不能狡辯的東西。但是, 我深深覺得溝通才是王道, 在專案的執行過程中, 如果溝通上出了問題, 儘管文件寫的再怎麼完善與精美, 推動的過程一定困難重重。不過, 文件真的也很重要, 像我這樣年紀輕輕就得依靠智慧型手機幫我記住所有事情的人, 少了文件的紀錄, 真的可能剛剛講, 現在就忘了。就像我本來想多加一點變成十二點的卻怎麼想也想不起來一樣...

(The copyrights of the photos are from the original authors. I'll remove it ASAP after anyone of your sends me a message.)