理想與實際會有非常大的差異，在軟體界更是尋常可見！可是因為軟體並非實際的物品，所以通常不易讓「外行人」了解！不過當你看到這張圖解理想與實際的軟體架構，就能大概知道開發一個軟體將有哪些狀況會發生。
此圖取自IT狗的俄羅斯方塊，很高興這張圖寫實地描繪出我所經歷過的狀況ＸＤ～
軟體界所謂的規格(Specs)，以我過去的經驗來看，大致只有在初期開發時管用，新的技術、新的需求、新的人事物⋯⋯都會影響啊～
我常笑說，我寧願從無開始打造，也不想要去維護他人遺留下來的「毒（技術債）」。
開發軟體就像興建房屋，必須要有鉅細靡遺的藍圖，考量得非常周到，就能在預期的時間內完成！不過這過程總是會有些問題產生，特別是新的需求產生，將會重大影響接下來的發展。
我最近面臨到創業案，需求不斷地變更，可能是因為領導者沒有經驗，也可能是因為投入的金錢與時間不夠用，這讓我非常傷透腦筋，原本我已完成的功能與流程，還必須修改兩到三次，還不一定能完美地做好，畢竟跟原本我所計畫的結構有許多不同點。修改後產生的後遺症就如上圖那樣⋯⋯
上週日我跟他說，他這個交友平台我不感興趣，所以也沒有太大的熱情在開發上，只要能夠讓我非常順利的建構出來，我就能幫他開發好iOS App。我想他也沒有預料到，原訂3個月就要完成的產品，居然要拖到一年半之後，而且已經刪減掉超過一半的功能。
至於我新報到的港商公司，是專門在做自有產品，跟過去五年我在接案公司所做的工作不一樣。
接案子與做產品的差異
- 專案時間：短期 VS 長期
- 人力資源：人少 VS 人多
- 規模：小 VS 大
- 狀態：0-1 VS 1-100
我個人的感受：
- 開發速度：快 VS 慢
- 成就感：大 VS 小
過去我一個人就能把iOS App做出來，現在我必須與另兩位iOS工程師協同合作，因為我是最後才加入，首先要了解已定型的軟體架構，每個功能的增修都要「瞻前顧後」，深怕一個不適當的寫法，測試後儘管沒有出現問題，卻可能埋下日後的「技術債」。
我們家的產品屬於UCG平台，它是類似臉書的社交平台，目前已開發將近一年，總算要完成上架囉！話說我在香港的iOS同事，做了個「樂高系統」，給我的感覺真的很像上圖的俄羅斯方塊！任何功能和流程都要遵守MVC架構或MVP架構，儘管看似開發速度不快，卻能讓未來增修功能流程時，能夠非常清楚明瞭每一部份的脈絡。
期待一個月後搬到信義區的辦公室，能與這位來自香港的資深工程師攜手合作，打造連我自己都想用的產品！
註：UGC是「User Generated Content」的縮寫，中文可譯作：用戶原創內容。UGC的概念最早起源於互聯網領域，即用戶將自己原創的內容通過互聯網平臺進行展示或者提供給其他用戶。
逍遙文工作室 
Comments on: "[圖解] 理想與實際的軟體架構" (3)
[…] 理想與實際的軟體架構 […]
讚讚
[…] 過去一個大功能我能在一天內完工，現在一個小功能我可能一天內還無法安心動手，落差非常大啊⋯⋯有時候真的想要不管既有架構，把可運行的Code塞進去，馬上就可以有正確的效果，只是長久來看，只會不斷增加「技術債」，這我在圖解理想與實際的軟體架構有提過。 […]
讚讚
加油 💪
讚Liked by 1 person