9527號病患您好！我是您今天的心靈導師 小笠宏樹，首先請您來跟我一起冥想一下，ㄡ～ㄇ～

在悠閒的週末下午，就是要來首
Toe - グッドバイ Goodbye Feat. Toki Asako

好～今天我們來延續昨天的主題，來討論B選項，但是會先將題目轉換成軟體上遇到的問題，如果有興趣歡迎兩邊對照看看。

以下是軟體版的故事
「小明是一家交友軟體公司的軟體架構師，他正在苦惱著功能的現況，因為軟體的明星功能「照片配對」雖然還是很多人使用，但由於競爭者爭先恐後地湧入這個市場，在可預見的現在以及未來「照片配對」這個功能的市場會漸漸萎縮，因此現在軟體不得不開始準備努力地尋覓下一個明星功能。就在此時，底下的兩名工程師剛好分別的遞上來了兩份架構提案，兩份都是PM想做的「聲音配對」交友，唯一不同的是，A工程師為了避免麻煩，想直接開另外一個產品，所以會有另外的DB與APP，而B產品經理保證的是他會在完全不動目前軟體架構的狀況下，將這個新的功能融合進去現有的軟體裡面，並且讓他們掛在同一個APP底下，如果這時你是軟體架構師你會希望選擇哪一個呢？」

選B選項，那情況大概會是A的反過來，以下大致列出來優劣勢

優勢：

• 因為會用到現有的架構，因此所需要準備的新的Class、新的Database、新的Server不用太多
• 由於可以以原本的Database去做功能，並且以原本的Function去做生產，因此在資源上可以重複使用，甚至在資料分析上，一開始就可以有一定的基礎
• 因為一開始就將新的功能融入原有的軟體架構，因此新的架構與之前的架構不會差太多，頂多是原有的Class會被擴增功能
• 後續不管是功能成功或失敗，軟體都可以利用原本現有的架構下將多出來的Function、SOP拿掉就好或者直接將資源轉回原本的功能

劣勢：

• 一開始需要花很大量的時間，一個一個Class的研究要如何融入新功能的流程
• 在功能上，會因為原有的作法、資源，導致能做出來的功能會很類似舊有的
• 由於會更改現有Class之間的互動關係，所以在執行的初期工程師方面會有很大的反彈，甚至難改的地方

以上是同一個故事不同平行時空的B部分，歡迎各位看官能對照著看看，說不定你能從工作經歷中找到更多有趣的觀點或者是作法～

以下就來提提我自己遇到此類問題的思考脈絡

1. 新功能的大小和與現有功能差異的程度會多大
   a. 這個目的是為了去思考在當前這個時間點各種架構方式去導入此新功能所需的時間成本和後續影響的大小
   b. 切分功能，將能融入現有架構的部份切開來，並試著找到差異最大的點，這個就是成本會花最兇的地方

2. 去了解這個新功能的未來發展
   a. 成功的下一步計劃，這可幫助我們不會在初期就做太多不能回頭的事，或投入太多不必要的精力在某些細節裡
   b. 失敗了會怎麼退場，會保留功能還是完全刪除，這會讓我們知道到底是要怎麼設計架構，以方便事後處理
   c. 了解新功能可能改變的時間點，用來決定當前要花多少時間成本在哪些部分上

可以發現當有一個比較大的功能進來時，首先要考慮的都主要都不會是程式本身的資訊，而是這個功能本身的“目的性”、“未來計畫”、“必要性”等等的資訊，然後再藉此去決定哪一種架構的方式才是正確的，因此沒有所謂的A架構方式比B架構方式好，而是哪一種架構方式更適合當前所要完成的功能的脈絡，甚至很多時候無腦的建一堆全新的Class和Database出來對於後面來講還比較好移除或是影響較小。

好了，這個兩章的系列文完成了哩～希望各位在看待公司的組織大變動時能有更深一層的體會，甚至是去猜測為什麼公司的架構要這樣調整。
話說上面剛好有講到將新功能退場或刪除的部分，那明天就來講講讓人聞之喪膽的裁員吧～
（不好意思，作者本人突然發現文章的相依性，因此微調個順序）
明天就來講講外包吧～