在台湾的软件公司一向很缺测试，(以下说的都是自动化测试)
但好的测试(我偏向BDD而非TDD)其实可以节省后面很多时间
事实上架构永远都不会够好，以前想multi-thread, multi-process
后来改distributed，现在又变成serverless，太多的架构会跟着改变
更别说每个人观点或每种技术的优缺都不太一样
甚至现在看以前的架构也非常可能觉得不够好！
所以别天真的想说会有一个完美的架构，搞好change control才是
有好的测试其实让你在改动架构或甚至任何改动的时候，可以让你放心去做
当然许多新创在做MVP的时候没做测试是可以接受的，
毕竟如果产品活不下来，技术债是不用还的，测试当然必要性也很低
然而在确定产品可以存活下来一段时间的时候，
最好把该做的测试补上，我指的并非coverage要非常高(>90%)
而是一些核心的功能、API测试先补起来，然后再慢慢把coverage提高
所以现在能建议的就是，尽可能的说服你老板说现在每次的改动其实风险很高
所以看能不能每周(或每一段时间)让你分一些时间去做好测试
至少先把主要功能做起来，让你之后改动风险小一些
我了解在新功能优先的情况下，要说服很困难，
但你可以网站有多少流量、为公司带来多少$$等因素，
来说明如果现在一些风险的控制不做的话，可能会损失多少钱
(如果他觉得这样是因为你的bug造成的，那我想这公司也不用待了？)
※ 引述《zeldo (瓜拉度)》之铭言：
: 在开发网页平台时，除了基本的维护、debug外，还有每次交办下来的新功能以及
: 新需求，有些地方在每次新功能的加入、删除下，时间一长，慢慢也会出现些架构
: 上问题。特别是在公司求快、求好、可以短时间展示的政令下，更是如此。
: 在面对数次的修正之后，还是会有些隐忧存在其中，只是不知道什么时候会跑出来
: ，对于这样的状况，会为求效能而去翻新平台的架构吗？
: 这其实也是小弟我在现在工作上面临的状况，很多地方在需求变更前修后改的情况
: 下，造成不少没作用的code跟function，而且在那时为需求而设计的架构也被东挪
: 西挪，配合使用在其他的功能下，虽说平台的运作上都正常，可那些遗留下来的东
: 西却很碍眼，并且也引起些问题。
: 的确这也与自己当初开发时对于功能弹性没有完善有关，可很希望能好好补救。但
: 现在也还是有许许多多的新功能急着要开发，使得这就有如叠叠乐一般越叠越高。
: 上头也表示现在以完成需求为主，等稳定后再慢慢修，而且会担心如果作大幅度的
: 翻修，会影响到现有的功能...
: 请问在网页平台变大后，还会为求效能去变更架构吗？