EEP iCoder如何面對需求頻繁變更
訊光科技/Andy Kao
應用軟體的專案開發過程中，需求通常很難被固定下來，一改再改頻繁的變更需求，這是常態；如果從頭到尾都溝通良好鮮少變動，這是特例個案。所以，如何在需求變動的過程中，還能迎刃有餘如期完成，確實是個大學問。
EEP自從增加了iCoder Wizard之後，生產力就突飛猛進的成長，不但開發起來更為方便、更快速、更為直覺，也可以先透過雲端的 iCoder先設計雛形，完成經過客戶確認後，再透過EEP iCoder Wizard直接產生，對於重新開發的應用軟體專案，帶來革命性的便利。
iCoder的頻繁變更方案
雲端的iCoder與EEPCloud之間的配合，簡單來說就是顧問師(或系統分析師)與程式師之間的配合，顧問師負責設計Word/Excel及使用TRS處理過帳；如果遇到無法滿足客戶的需求，再交給程式師，程式師透過EEPCloud組件的屬性與事件撰寫js程式來滿足需求即可。過程中，不可能一次性完成任務，會來來回回多次，顧問師與程式設計師的分工可能在不同的時間段重複進行，造成互相的干擾與重工，在iCoder與EEPCloud中是透過下列的方式來解決此問題:
1. 程式師在EEPCloud所寫的前端或後端JS是不會被顧問師重複導入Word/Excel所影響的，除非刪除雲端上整個Word/Excel對應模組。
2. 顧問師以iCoder導入Word/Excel所產生的前端或後端組件與屬性，到了EEPCloud中，可分為每次都被覆蓋與每次都保留的屬性(如下圖屬性前方有紅色’*’者就是每次都保留的屬性)；每次都覆蓋的屬性跟著Word/Excel規格走，每次都保留的屬性則由程式師來控制，不受每次導入Word/Excel影響。另外，每次都覆蓋的屬性，如果程式師希望改成每次都保留，可以人工個別將該屬性設定為”鎖定”(如下圖CommandText鎖定之後屬性前方會有一個藍色’*’者)，這樣這個屬性下次就不會被Word導入所覆蓋。
3. 同上，顧問師以iCoder產生的前端或後端組件與屬性，在EEPCloud中程式師可能自行再貼入其他的組件或在原來的組件上增加欄位或功能項等，這些加入的組件與欄位，也會在iCoder重新產生前後端組件時自動被保留。
EEP iCoder Wizard的頻繁變更方案
EEP的開發環境是以Visual Studio為核心，要控制與雲端iCoder同樣的分工效果，難度是非常高的，畢竟VS有自己的標準文件格式，及自己的開發環境設計器，這些都是我們無法干預與複寫的。因此，對於EEP的iCoder顧問師與VS程式師之間的分工模式都有著不小的差異，說明如下:
1. 建議還是讓顧問師使用雲端iCoder來設計雛形，並讓使用者來初步確認，減少不必要的規格誤差往返。
2. 顧問師的Word/Excel交給了程式師之後, 透過EEP iCoder Wizard所產生在VS中的前端程式，程式師通常需要在前端加入JS程式來滿足使用者介面上的特殊需求。而這些程式都是寫在相對的ASPX中，為了避免下次Word/Excel導入時這段JS在APSX中被覆蓋，可以把JS獨立寫在另外的一個.JS檔案中，並在APSX中引用這個JS即可，如下，將”員工資料表.JS”分開寫:
3. 同上，EEP iCoder Wizard所產生的前端程式除了APSX外，還有另一個.CS的程式。而EEP的所有組件與屬性的設定都是存在APSX中，如果因為使用者特殊需求須更改屬性或增減組件時，設定在APSX中的組件內容將會在每次讀入Word/Excel時遺失，因此，程式師最好把屬性的設定與增減組件的工作，寫在相對的.CS當中，這樣iCoder Wizard在每次導入Word/Excel時都會幫你保留這個.CS檔案，避免覆蓋，如下圖的案例:
4. 透過EEP iCoder Wizard所產生在VS中的後端程式(一個Word/Excel會產生一個完整專案目錄)，程式師也會在後端加入C#程式開發Server Method或是撰寫事件來滿足使用者特殊需求。而這些程式都是寫在專案目錄下的Component.cs中，為了避免下次Word/Excel導入時這個Componet.cs被覆蓋，我們的iCoder Wziard會自動幫你保留這個cs，如下圖:
5. 同上，後端所產生的組件也可能會增減或改變屬性內容，同樣也是可以讓程式師在Componet.cs中來完成這個工作，雖然以程式設計來避免這個問題有點麻煩，但總比每次都被顧問師新改的需求覆蓋划算許多。如下，可以寫在Componet.cs的Componet()方法中:
結語
iCoder這個創意，革命性改變軟體開發模式與分工，解決了應用軟體開發的三大瓶頸。第一個就是需求溝通困難，通常使用者說不清楚他要甚麼，透過iCoder的Word/Excel文件與雛型設計方案，可以有效成為溝通橋樑，加快需求確認的時程；第二個瓶頸就是系統設計與開發，通常曠日廢時，透過iCoder可以全自動化產生資料庫結構、後端服務端模組、前端頁面，生產力為傳統的數倍以上，產生之後再透過程式師根據特殊需求在VS中進行二次開發即可；第三個瓶頸就是系統的需求頻繁變更與系統維護，需求變更是必然，不管是顧問或程式師都必須快速反應客戶的變更需求才能提升客戶滿意度；至於日後的系統維護更慘，傳統必須依賴原來的團隊或之前留下的文件來處理，但有了iCoder這個方案，顧問師可重新透過Word/Excel來理解之前的規格並做出改善，並讓開發人員重新接手沒有什麼程式碼的EEP平台來滿足維護需求。
因此, iCoder可以讓應用軟體的開發組織中，顧問師(或系統分析師)與程式師的比率革命性的改變，從原來的 1:2(1個系統分析師對應2個程式設計師) 或 1:3 的比率，變成了 2:1 或 3:1 的比率，除了明顯成本的大幅降低外，可以預見這種不依賴程式開發的開發模式與組織才是未來軟體開發的主流方案。
