進入第二間公司 後，學到最多的是對於金流、物流的認識，從介接第三方的金流到物流商的資料介接，雖然不是直接開發，但從一起合作的工程跟文件也學到三、四成功力，還有一些跟 EC 相關的商業邏輯也在處建立一些常識。
整個系統最大的特色是用 MVC 這也成為主流了，但用的不是坊間常開到的 framework, 而是自己開發整個 MVC 的架構，其中也包括了一部分上商品的 Business Model。那時候開始摸 CI, cake PHP 等等的 framework, 過去待過的第一間公司雖然想用，但無奈機器的承載不太好，必須要求極輕量的開發，所以只有大量的 function 使用，根本無所謂什麼 Design Patten 等等… 最多就是 View 有切開
而身在其中，最主要完成一個對外的 api 專案
整個頁面比較特別的是都用 php doc 的邏輯去建立文件，這樣的好處是程式寫完，註解有寫清楚，其實文件也寫完了。另外從未寫過類似的 code 我也是從 token 的取得跟授權方式去參考別人後弄出來。
我在邊開發時，邊進行對商品上架的程式做重構的動作。C2C 的買賣有個 domain know how 是商品的修改歷程紀錄，而這個的紀錄又與商品是否賣出有相關，商品若賣出後，之後的修改就變得有限制，於是乎 model 的邏輯判斷就有一些複雜性。原本的程式邏輯是很多個判斷句，於是乎多一種商品性質，就多了一個判斷，到最後 if 的判斷句因描述太長變得冗長無比。
class good extends store {
function good_add($upload_data){
//process upload data
//verify data
//connect db
//insert db
}
function good_modify()
{
//process upload data
//verify data
//如果賣出過，則商品的描述只能用 append 無法全部修改
//如果賣出過，則商品的價格不能更改
//connect db
//insert db
}
}
將 veify data 提練出來
Class good extends store {
function good_add($upload_data){
//process upload data
$this->verify_data();
//connect db
//insert db
}
function good_modify()
{
//process upload data
$this->verify_data();
//connect db
//insert db
}
function verify_data()
{
//如果是主商品
//如果賣出過，則商品的描述只能用 append 無法全部修改
//如果賣出過，則商品的價格不能更改
//如果是贈品
.......
}
}
因為 verify data 的部分其實都重覆了，除了增加一段 function 之外，另外商品也因為商品的型態而檢查不同的欄位
Class good extends store {
function good_add($upload_data){
//process upload data
$this->verify_data();
//connect db
//insert db
}
function good_modify()
{
//process upload data
$this->verify_data();
//connect db
//insert db
}
function verify_data()
{
$check_field = $this->verify_check_point();
//針對回傳欄位判斷規則等等
.......
}
function verify_check_point()
{
if(主商品)
{
if(已賣出)
{
$verify_field['主商品'] = array('規格'.... );
}
else (未賣出)
{
$verify_field['主商品'] = array('標題', '描述', '價格', '規格'.... );
}
}else
$verify_field['加購品'] = array('標題', '描述', '加購價' .... );
$verify_field['贈品'] = array('標題', '描述', .... );
}
}
}
程式沒有寫得很精準，如果寫太細可能就把前公司的 code 給揭露啦，裡面還有更複雜的邏輯，不過大致就是將重覆判斷的區塊提鍊出來，另外再將這區塊可攜性再加強，就算很多巢狀判斷句也盡量讓語句精準不要超過一頁。
原本疊層架構的程式架構也必須換成改用另外判斷的方式去增加未來的擴充性。光是為了做這個的改進，我其實就多花了2週，不斷的重構跟調整，接下來對應到的好處是，後來公司跟批發商有談新的需求，那時候我只要改增加一種商品型態就可以直接做完了，判斷的入口只要看有無重覆就可以馬上使用了。
我想講的是，軟體工程師往往最花精神的地方，是外面看不到的地方，就好像蓋房子花最多心力的，其實是水電的配置，地基的佈局。不過房子是蓋完就不再變更，放在網路上服務的 Web 服務卻是不斷的再蓋房子，再拆掉部分，重新擴充，而這裡面的心力也是往往外面看不到的。
雖然我寫完後，有想再進行重構，但公司有些人事問題就放著沒有再努力開發了。但真的要進行重構之前，必須對現有的程式流程、及商業邏輯等等有所掌握，再逐步進行重構的調整會比較理想，基本上若是有留 Test Case 就可以重新跑過這些 Case 但如果沒有留，還是先別冒然更改。
現在回想起來，若當時可以繼續改善的目標是將 Design 的抽象繼承引入才是。現在不知為何年紀大了都在回顧過去了，有點兒糟。
- 谷關溫泉騎馬之旅 - 2024-08-16
- 用 Notion 來回顧一整年的看劇活動 - 2024-01-01
- 如何用 Notion 來規畫新的一年，即將到來的大日子 - 2024-01-01
1 Comment
回顧過去才能展望未來啊！