肯尼那那

接下來 9月份要接新的線上金流付款結帳可能會用Angular來實作，但一直都認為javascript物件觀念不是很強烈，為了因應TypeScript的來襲利用晚上空檔扒一下javascrpt物件的觀念後在加強TypeScript的寫法。

加強了幾個觀念：

1.自動載入的類別實例化與類別建構子 (Constructor)實例化的使用上的差異。

2.另外javascript的繼承的方式是不同的，她採用了原型鍊連接的繼承也就是會 沿著該原型鍊向上存取而得。舉例：var myString = ‘This is my string.’ ， var 一個變數為字串物件型態後myString 就會變成了字串物件那她物件實例化後就會沿著該物件去找她原型錬的函式與屬性。

所以每天工作都這麼做的myString.split(',')，雖然都是這樣做但一直沒去透徹這些方式的觀念。

雖然在教育訓練時老師常說 透過定義並初始設定變數來建立物件而不是變數，在上課時記著了，但沒有深根導正到我的想法經過扒文後才體悟到。
這個月算是收穫兩枚觀念一個為javascript物件原型、另外一個為HTTP標頭的觀念，這些的東西對我的同事們或主管(pao)可能都不算什麼新聞但對我來說可以改善我除bug或製作前台的速度。

工作項目如下：

1.M-結帳流程需增加超商取貨付款

2.專案頁－更新為新版本和跑版調整

3.MS-刷卡失敗讓消費者得知訊息

4.總後台定期定額回傳的修正與畫面的調整

 5.總後台增加paypal相關設定(建置中)

6. M-增加paypal於結帳頁面(建置中)

7.產品圖示頁面載入不顯示的問題。

這個月在做超商取貨的功能時有某一家超商不讓人iframe另外在電腦版和手機android、ios不同拖延到了時程，當然這些問題都己排除了，在製作上預到沒有預過的問題去解決也是一個不錯的學習。

這個月滿充實的一個月，首先感謝老大體恤員工放幾天假舉辦員工旅遊，也謝謝小佩用心的安排這次康樂活動讓各同事之間更有默契更活絡，另外還有課程上的教育訓練。在公司真的學了不少的知識，每次在方案執行時都會想如何做更好的方式讓功能更物件化的寫法或使用上可以更方便，也可以讓後續維護或加入新功能時可以更便利或減少多餘的重工的工作，所以在這製作過程中一點一點累積成長中。另外接下來各方案前端要導入angular相對的MVC架構和OOP導向程式思路要更清楚，所以接下來有一些挑戰需要去完成。另外還有偵測器需要去完成，積欠這個技術債希望可以跟Mark趕快去完成她。

以下為工作事項：

1.BOT-消費者如線上刷卡失敗處理方案

2.MS-暑專案銀行線上刷卡金流API

3.MS-總後台客戶付款內增加定期定付 feature

4.MS-定期定額API判斷參數修正

5.MS-建置暑專案官網的檔案

6.MS- 虛擬帳號補入銀行代碼 、繳費帳號於的訂單內容、訂單列印資訊、email

7.MS-暑專屬網頁加入各方案網址

8.MS-訂單管理增加超取純運送功能

9.BOT-結帳流程需增加第三方付款－進行中。

10.MS-訂單記錄頁面增加訂單註記按鈕。

部門在為了提升程式的管理品質與新的工具的導入也希望縮短人員使用與製作的痛苦期，這個月公司開始安排一些對於我們開發有幫助的教育訓練的課程，所以相對的必須下班後要移出點時間閱讀和預習來加強課程吸收效能，畢竟上課不太可能聽到所有的內容可以馬上理解的我。在公司都花錢栽培我們的技術技能上了，我還是要多花點心思用功用功。對了小寶功能近日都有在假日動工但過程中一直段段續續的好像都抓不出比較完整的時間去完成她，常常因上個禮拜所做的方法下週確忘了那個方法所以要花時間摸索一次又浪費時間在重新測試的問題上，又加上要多看跟教育訓練有關的資訊就又造成小寶研究時間又縮短了有點兩難喔，所以每次看到老大時都感覺提不起頭來的感覺。

以下為這個月的工作事項：

1.B調整付款頁面都市、鄉鎮沒填送出訂單問題。

2.修正購物車訂單沒有虛擬帳號的資訊。

3.修正購物後管理員會收到的信件的顯示訊息遺漏。

4.B購物車串接線上刷卡。

5.MS後台LOGO尺寸提示文字修改

6.B綠界線上刷卡回傳刷卡失敗訂單有效性、和吐出刷卡失敗的機制

7.MS官網-專案國泰線上刷卡串金流API

8.建置MS總後台刷卡定期定額管理介面

9.將設計的暑期方案置入MS專案中

要Build一個PHP專案起來，近日體會到是一件不簡單的事情，簡述的說，在以前開發 PHP時程式語言 與 HTML 夾雜時代沒有 OOP、沒有 package、沒有 MVC、沒有 framework，在建置上是簡單的但是不安全引用上也會面臨一些問題，但現在為了讓PHP更安全、後續更好維護達到MVC架構會善用framework或者一些container 在這一年的時間內有點不懂這些的關係，但都會由主管或比較資深人員建置好MVC環境出來我們只要遵照這些規定去做，只要把 php、javascript、jquery寫好把功能做出來就好了。但這一年來都一直想把framework關係在稿懂點，剛好借由做定期來實現MVC製作方式，但一開始一直沒有辦法Build成功經由Max幫忙把這規範做起來，當下我也不太懂她做了什麼，所以這幾個禮拜有空的晚上有試著去建置slime 、DI ，體驗framework和container的關係，但這個部份還是需在加強學習。
所以我體驗到要Build一個新專案起來要如何選擇framework、容器還要善用composer，剩至要多人可以使用這個專案還要會建置docker，才有辦法開始撰寫程式，所以一個專案要Build起來需要經由溝通、協調、評估、文件規劃、開發環境的建置、程式的開發、功能的測試，所以可以體驗到資深程式設計師所說的寫程式才佔整專案百分30，所以相對我還有很多東西還需要多多實作體驗學習。

工作項目如下：
1. B-poject 品牌API

2. B-poject 訂閱喜好API

3.B-poject 讀取yml檔

4.MS 購物預計貨到日期文案調整

5.MS 購物虛擬帳號匯款前台、後端、信件的處理

6.B-poject 自動預約功能的取消預約修正

7.B-poject 已完成預約但還是可以一宜操作的修正

8.MS 定期定額API建置

在開發系統的過程中，最近常在想如何讓系統規劃的更完善，系統規劃完善在增加符合客戶需求功能或者是修改不符合現有市場操作效益時可以更精確或快速找出現有專案中的物件然後加以繼承或加以引用，這對開發程式來說可以減少重工浪費尋找或核對的時間。在公司工作的期間中有時會寫到過去PHP動態和靜態程式同頁的寫法，也有MVC架構的製作方式，也相對的讓我體會了PHP這些的演進的過程與寫法。如何善用MVC的架構方式讓開發可以更敏捷，在系統開發中要更完善不只是程式建置的部份，在開發的前提要做完整的需求分析將分析的結果做適當的分類經由分類規畫出適當的類別，對於現在都是朝這樣的開發方式在進行。但在開發系統會經由計劃階段、分析階段、設計階段、實作階段，這樣的過程中需要明確的記載著這系統要提供什麼的功能要如何達成系統需求然後讓開發團隊建立系統。對於電子商務或電子數位平台來說這樣的過程記載還滿重要的，因為電商平台上架後隨時會後有續追加新功能或修改更符合賣家、消費者操作上的需求，但文件製作更完善的話就不用花很多時間去想當時為什麼這麼做，也可以讓支援者瞭解系統的藍圖知道那些物件已建立可以引用或者需另外開出物件，相對也可以快速分擔原本創作者的工作份量。
這也是在製作BOT專案中體會到的，當然要如何改善這個問題提升開發的效能這是因該多花點時間在加強的，簡單說改變重我們開始讓開發工作更完整和完備。
以下為相關工作項目：
1.MS的詢價功能,在後台購物車訂單管理/詢價商品區/詢價詳細內容中的地址沒有帶到資料
2.MS購物車加購產品金額結算問題
3.MS 超商取貨和超商代碼付款做金額限制
4.MS超取付款訂單狀態修改為不能標示處理中
5.FSB消費者「出貨通知信」加上點數折抵
6. MS活動折扣後的金額未同步於訂單匯出的excel
7.訂單匯出的excel與訂單明細欄位同步
8.BOT購物車webview畫面建置
9.BOT購物車API
10.BOT購物車訂單 ATM、貨到付款串接

以前在補教界、學校或公家機關講課都需要製作課程講義在排版上是沒有問題的只需要幾分鐘就可以很快的排版。但這次不同於如何將以前學習過但沒有真正實作過的系統規畫書製作出來，這個期初讓我有阻礙和沒有方向感的，經由老大的退件後詢求冠旭和pao 諮詢與協助得以找到方向，也讓我在文件化學習到如何將程式模組間的關係可以用更明確的方式表達出建構或繼承的關係藍圖。雖然在報告製作上學會怎麼製作了，但如沒有常常製作還是會忘了這種感覺，但系統報告讓我體恤到可以簡化重工、對症下藥找出痛點、或專案人員討論時比較快速到解決方案。
php算是我這一年裡面主要開發專案的程式語言，但為了安全又可以快速達到製作標地，現在的開發者都會使用framework軟體開發框架來製作，我們的團隊也不例外。相對的有pao 和冠旭對框架上的熟悉度，讓我在這樣的保護架構下去製作專案，一直以來都覺得只要能用就好，不會想去瞭解framework是什麼，但對於後端設計師來說如果沒有去瞭解這個框架有時會找不出錯誤的原因，所以近日也用下班後多花一點時間去瞭解我們專案常用的軟體框架，以提升專業度。

以下為相關工作項目：
1.UML專案文件報告
2.專案API測試報告書
3.M＿Bot 訂購預約必填會員資料
4. Booking 直接確認預約API流程調整
5. M＿Bot 直接預約確認Push至F_Bee 通知訊息
6. Booking 直接取消預約和通知F_Bee
7. Booking 需管理者 F_Bee 確認或取消預約
9. M＿Bot 結帳 web畫面
11. MS客戶後台－綠界刷卡分期加入文案文字
10. 小保全 web application和 AP 連接製作

來到知識算是跨了一個農曆年了，也學習與製作了很多寫程式的方法，要感謝 寶耀、團結的RD們的幫忙與支持，也謝謝老大讓我們嘗試新東西。在這農曆年後就努力的邊做邊學習更多，貢獻更多於公司了。

終於在這個月底前趕著將相關預約功能製作完畢，3月初將這些測試一下就讓她上線，後續就接著能幫忙著將Bot購物流程。

現在著手製作UML的文件和讓小保全完成各組件的安裝。

以下為這個月完成工作項目：
1.MS總後台增加綠界設定功能、前台購物車分期手續功能
2.修改MS綠界線上刷卡－分期沒有開通分期不傳送分期期數參數
3.MS國泰刷卡失敗或未付款改為不需要寄信
4.M-Bot自動預約確認流程
5.M-Bot手動預約確認流程
6.M-Bot 預約通知Line串接
7.M-Bot 預約庫存
8.讓預約成立顯示於MS訂單中
9.修正M-Bot 加入Bot的會員可以更新Store
 

雖然我沒有歷經知識的前十年，但可以體會知識十年的歷程是滿足內心創造事物的渴望又符會數位市場的需要與變遷所產生的公司，與一群熱愛程式的工程師們，將創意願景的產品具體化的實現出來，讓產品更符合市場也讓工程師們得到創造的樂趣與滿足感。

但未來的十年或廿年知識在製造市場需要的產品上需要做更整體化、垂直化的管理、架構設計、實作和實現。當然這樣的做法也沒有抺滅掉知識創造的初衷，但需要加入更制度化的管理元素，但在這制度化的過程需要付出代價，這麼說好了，依人月神話一書學說的車庫開發程式年產值會在1000行 以上，但正規團隊的開發速度據說是年產約有1000行內的程式碼為什麼會有這樣的差距，經過了閱讀的瞭解和經身體驗程式開發過中如何讓程式更通用性、維護性高、文件齊全、完成測試、介面系統整合性高而後產出符合市場的產品，所以這些必須要制度化才可以達成公司未來的目標，但制度化過程必需要要花費以前3倍的時間產出產品必須花到9倍的時間，所以知識的十年前或現在的產出程式是很快的，但這程速度會慢慢的降低，因為我們正從車庫或英雄式的開發中做轉變。所以在車庫開發程式是有樂趣，但制度化的寫程式是苦難的，但如何讓制度化變成快樂的有樂趣的這必須做更整合化的分工垂直化的管理。

在制度化管理下如何讓團隊極具生產力，當然也不是猛加入人力就會改善，我們就依人月用醫院的外科手術團隊的例子來說，一個手術團隊會有那些人員：外科醫師、副手、助理基本上這些人員加一加會有基本成員5個人當然不包含實習生、觀察員、麻醉師。

外科醫師：稱之為首席程式設計師，他會負責定義功能上程效能上的規格、設計程式、編寫程式、測試程式、並撰文件。

副手：相當外科醫師的分身，能夠做任何外科醫師做的事，只是經驗較為缺乏。但在設計時擔任出主意、參與討論、評估的角色，外科醫師也可以把一些構想交給他去嘗試，但不盡然要接受他的意見。副手常常代表外科醫師去開會因為開會會佔到專案執行過程中的1/3的時間，和客戶或別的團隊討論功能、介面等事宜，當然無疑她也是個備胎，他甚至也會寫程式，但並不對任何程式負責。

助理：程式助理的專業職責就是分擔程式設計師的一些例行性工作，並保證在一定的效率之下，很有條理地處理一些容易忽略的瑣事，並強化整個團隊最珍貴的資產－工作產品。

在中小型公司，雖然一個專案執行如需用到5個人以上在成本上相對較高，但如何分配同一個專案如何去讓我們製作出的產品更有延展性、掌握到市場的新鮮度、文件規格相關文件的完整性，這是知識開發團隊接下來須面臨的課題。

很多人都這樣認為，名牌產品（如知名電商）是不會有危機的，事實卻並非如此就如手機Nokia、底片科達、單眼相機nikon或者是富士等等，都在這競爭的殘酷性、環境的快速變遷、市場的全球化等使這些品牌都無法保證自己在多變的市場環境中不會發生波動乃至危機。

發展出整體發展戰略：

有一套好的、完善的整體發展戰略是產品和企業更好地發展的重要元素之一。產品怎樣發展？價格怎樣定位？不同市場採取怎樣的營運手段？有許多問題都需我們認真思考，勇敢去面對。不同地區、不同人、不同產業，對產品的需求和要求不同，所以有許多企業的危機都是因為其缺少整體發展戰略而造成的。

管理機制健全：

有一套健全的管理機制，企業才能更好地發展，然而並非每個企業都會這樣，因為沒有有效的管理機制而引發危機的企業是存在的。缺乏監控系統：對於一個企業而言，制度的實施、員工的工作、領導的決策都須監控，如果一個企業沒有有效的監控體系，制度沒得到合理、正常的實施，員工、領導的工作就會偏離軌道，所以要做好有效的預防和控制。危機管理制度不健全：危機管理制度是危機管理的基礎，是企業朝更好的方向發展的保護傘，它的健全於否對企業的影響很大，如果它不健全，企業就不會對危機進行預防，也不會對此有效控制，更不會對具體危機具體應對。

有一種說法認為『企業的壽命只有三十年』。但我覺得這句話挺妙的。個人體會是一個經營者創業後找到一個商業模式並只靠著同一個模式獲取收益持續成長的話或許頂多能撐過三十年左右的榮景，如何擺脫這樣的危機我認為商業模式必須隨著時代一起改變。

以經營公司的想法很簡單，就是製作出符合電商市場、讓客戶和消費者使用方便的操作平台，製作出的產品盡量多賣就行了，當然在市場對於我們所開發出來的BOT市場佔有率還沒有很普及，新鮮度很高的狀況下用這樣的方式就能順利將產品或公司經營下去。但如反之新鮮度、市場佔有率面臨挑戰時對的這樣的產品就面臨到問題了。

套句Motive 商業行銷創意一句經典：經營品牌，就像人生一樣，妳永遠不知道『下一秒妳會面臨什麼樣的危機或是難題』，這個麻煩製作者，可能來自於妳的對手、消費者、甚至是品牌自己。

許多危機之所以為危機，就是你忽視、小看、不注意、認為沒什麼，最後就演變成無法收拾，最怕的是我們最後一個才知道！

我們得到市場的認同是企業的原點，也是生命線。畢竟私人企業，對於銷售額和利潤的追求也是不得不為。不過我認為在新鮮度過了之後如要能繼續保有該產品的收益平衡或者是獲益，不應當把銷售的追求擺在第一位，我覺得『首要之務就是企劃要做的更嚴謹讓產品更優良』顧客的滿意度自然也提高，銷售額和利潤就會上揚。

『以高品質提供顧客大大的滿足』這句雖說是一個廣告詞，但我覺得公司一直保持這的態度，我相信這樣的態度最後會促使企業壯大起來。所以高舉標語『品質＆滿足』作為產品的理念。

這個月的24號算是來知識滿一年了，在知識的日子裡學了很多的技能知識，很感恩RD程式組前輩們的指引與幫忙，讓我在這一年內有那麼多的收穫，接下來這新的一年第一季要跟阿信挑戰完成F聊天機器人的製作和阿寶偵測器功能，相對這一季雖然有挑戰但相對有新的技術要突破。

工作項目：
1.F Bot消費者填完會員資料後繼續原流程
2.MS購物車加入綠界刷卡分期手續費
3.修改 F Bot API 預約日期、時間過期不顯示問題
4.全館折扣加入綠界物流訂單
5.修正F Bot會員綁定流程有重覆問題的修正
7.讓F在Booking或綁定會員時填完會員資料後回到原流程
8.F的Booking自動完成預約成功動作

這個1~2個月大量使用到物件導向的方式，在這個過程中學著去思考如何讓開出來的function可以重覆的利用，減少重覆的製作或者後續修改時可以從當下的物件和方法去修改，就可以改變相對使用的功能。另外在開API時必須要想好前後的邏輯性，如沒有想好可能很多東西都要重工，所以這也需要一點時間去累積的，這個是無法從課本或網站上得知答案的。