PHP項目的“苦逼”經曆與思考
PHP項目的“苦逼”經曆與思考
PHP零基礎,但由於項目人手不夠的原因,被安排到一個使用者“定製”項目。該項目是用PHP產生的統計資料報表。而使用者又有新的3個需求,需要在已有的代碼基礎上完成。
一、初識PHP
由於本人之前沒有接觸過PHP代碼工程,所以需要花費一點時間過一下PHP的基本文法。個人感覺和C++很像,有類的定義、繼承和派生,但其又比C++簡化很多,沒有C++、C的資料類型的概念,所有資料想用什麼直接聲明賦值即可。並且,其字串很強大,可以嵌套定義,是C的字串、結構體、聯合體、枚舉類型等的組合體,可謂“一專多能”。
做到對基本文法有大致的瞭解,一些通用函數基本是現用現查。
二、代碼結構梳理
定製項目的特點:在已有功能相對完善的基礎上,增加或修改新的功能,以達到使用者的“定製”需求。需求會有《**需求說明書》可供參考。
因為項目周期短,基本是直奔主題。期間採用了“關鍵字”搜尋的方法,縮小代碼範圍。但由於代碼結構甚是龐大,且“先輩”少給代碼注釋,整個代碼的跟進進展一直很慢。沒有方向感,感覺代碼“跳來跳去”,又回頭初始讀的地方,“串不成線”。
整個過程持續了5天,龜速前行。
三、找准“入口”、實現功能
從項目實現新功能或修改功能的“全景”統籌視角,要達到使用者需求,需要以下幾步:
第一步:找到“代碼”新增或修改的進入點,可能不止一處,可能會涉及多個PHP檔案,在走讀代碼的過程中,對這些“可疑點”都要堤防並標註便於自己尋找的記號。
第二步:在讀懂“可疑點”代碼邏輯的基礎上新增或修改代碼,並自己反覆測試,直至達到客戶功能。
第三步:形成補丁包或者增量包,提交測試部門測試,待測試無誤後提供使用者驗收。
第一步非常關鍵,往往會花去整個項目的近一半的時間。
期間需要結合新功能的實現及已有代碼架構進行思考,以找准“入口”。如,要實現報表新增資料,資料從哪而來?資料可能和mysql資料庫有關,要從資料庫裡擷取統計分類資料,已有的資料是如何擷取的?新統計資料的擷取是否要修改SQL語句才能達到?如何修改?這樣修改前台能顯示正確嗎?是不是需要先後台驗證?……
四、思考
從項目高效達成目標的角度和自己欲哭無淚的苦逼經曆,特思考以下幾點供跨語言開發和未來項目借鑒。
第一、“工欲善其事,必先利其器”。
閱讀代碼初期,由於發現SourceInsight對PHP代碼支援的不好,所以用Nodepad++去讀代碼,其不同PHP檔案代碼跳轉的痛苦可見一斑。後來,搜尋發現其實SourceInsight對PHP是支援的,網友有提供配置方法。這樣,搜尋關鍵詞及代碼跳轉又高效了不少。再後來,從高手哪裡發現,這種前台的代碼實際上可以通過Subline Text2進行閱讀的,實驗了下,的確好用,一直用到現在。
所以,好的代碼編輯、編譯工具會讓你思路相對順暢,提高工作效率。
第二、“順藤才能摸瓜”。
多麼複雜的代碼,只要別人能寫出來並且能實現功能,我們看不懂。不要“罵娘”,不要埋怨代碼注釋不夠,靜下心來花些時間去“順藤”,去理順代碼邏輯,這樣你才能逐步建立起代碼架構的整體思維。
“順藤”一方面可以走讀代碼去順,當代碼邏輯非常複雜時候,可以通過列印日誌的方式去列印關鍵函數,以此理順代碼的調用關係。兩種方法結合會事半功倍。
初期,由於時間原因,可以先徒手在本上畫出流程圖,供走讀代碼參考。待項目總結時再畫出規範流程圖,以備後用。
“藤”理順了,新增和修改代碼就不會那麼繁瑣。之前也強調,“順藤”的時間要遠遠大於“摸瓜”的時間。所以,前期要有耐心,切記浮躁。
第三、細節很重要。
我在修改代碼時,需要往數組裡新加成員。誤將“dataRow”寫成“dateRow”,PHP誤認為是新的定義成員,並沒有報語法錯誤。導致我在另一個PHP檔案擷取新增值總是擷取不到。我逐步縮小範圍排查,縮小至寫入的地區,函數前、函數內部、函數後都新增日誌列印對比。這樣還是沒有發現問題根源。但確認問題就出在寫入部分,最後近1天時間才發現問題所在,就是前面提及的拼字錯誤。
其實類似的錯誤,一些編譯環境都能通過“補全”避免掉,有的語言還會報語法錯誤。但細心是程式員的必備的品質,當引以為戒。
第四、不宜貪多,一個一個來。
項目需求多時,看到那麼多的需求和為數不多的時間容易使得自己淩亂。所以,需求要一個一個去實現。不要一把抓,一把抓往往成為沙漏,只能抓住一點。一個小功能完成實現後,要知道自己的Next。如此Next、Next遞推下去,項目就能相對緊湊的完成。
2014-6-18 pm20:58思於家中床前
作者:銘毅天下
轉載請標明出處,原文地址:http://blog.csdn.net/laoyang360/article/details/32173571
如果感覺本文對您有協助,請點擊‘頂’支援一下,您的支援是我堅持寫作最大的動力,謝謝!