在台灣的軟體公司一向很缺測試，(以下說的都是自動化測試)
但好的測試(我偏向BDD而非TDD)其實可以節省後面很多時間
事實上架構永遠都不會夠好，以前想multi-thread, multi-process
後來改distributed，現在又變成serverless，太多的架構會跟著改變
更別說每個人觀點或每種技術的優缺都不太一樣
甚至現在看以前的架構也非常可能覺得不夠好！
所以別天真的想說會有一個完美的架構，搞好change control才是
有好的測試其實讓你在改動架構或甚至任何改動的時候，可以讓你放心去做
當然許多新創在做MVP的時候沒做測試是可以接受的，
畢竟如果產品活不下來，技術債是不用還的，測試當然必要性也很低
然而在確定產品可以存活下來一段時間的時候，
最好把該做的測試補上，我指的並非coverage要非常高(>90%)
而是一些核心的功能、API測試先補起來，然後再慢慢把coverage提高
所以現在能建議的就是，盡可能的說服你老闆說現在每次的改動其實風險很高
所以看能不能每周(或每一段時間)讓你分一些時間去做好測試
至少先把主要功能做起來，讓你之後改動風險小一些
我了解在新功能優先的情況下，要說服很困難，
但你可以網站有多少流量、為公司帶來多少$$等因素，
來說明如果現在一些風險的控制不做的話，可能會損失多少錢
(如果他覺得這樣是因為你的bug造成的，那我想這公司也不用待了？)
※ 引述《zeldo (瓜拉度)》之銘言：
: 在開發網頁平台時，除了基本的維護、debug外，還有每次交辦下來的新功能以及
: 新需求，有些地方在每次新功能的加入、刪除下，時間一長，慢慢也會出現些架構
: 上問題。特別是在公司求快、求好、可以短時間展示的政令下，更是如此。
: 在面對數次的修正之後，還是會有些隱憂存在其中，只是不知道什麼時候會跑出來
: ，對於這樣的狀況，會為求效能而去翻新平台的架構嗎？
: 這其實也是小弟我在現在工作上面臨的狀況，很多地方在需求變更前修後改的情況
: 下，造成不少沒作用的code跟function，而且在那時為需求而設計的架構也被東挪
: 西挪，配合使用在其他的功能下，雖說平台的運作上都正常，可那些遺留下來的東
: 西卻很礙眼，並且也引起些問題。
: 的確這也與自己當初開發時對於功能彈性沒有完善有關，可很希望能好好補救。但
: 現在也還是有許許多多的新功能急著要開發，使得這就有如疊疊樂一般越疊越高。
: 上頭也表示現在以完成需求為主，等穩定後再慢慢修，而且會擔心如果作大幅度的
: 翻修，會影響到現有的功能...
: 請問在網頁平台變大後，還會為求效能去變更架構嗎？