※ 引述《wandallin (万大林)》之铭言：
虽然你同事提的是有利后续长期维护程式码的事务和规则，
但是从大局来看... 你们才刚上线还要再补功能，同时商业模式又还不确定....
也就是说现有运作模式再大修的机会不小，
因此 1,3,4,5,6,7 点有可能做了以后没多久就变无意义...是否值得令人疑惑。
再从实务来看，你们用的是实现逻辑的速度快，但 bug 相对复杂难追踪的 js，
这种情况下若没有新的功能需求，那程式架构没严重问题就不该去动，
免得改完架构是好懂好维护了，却有地方不小心改坏掉，越改越不稳定....
这样你跟老板都会不好向负责的对象交待。
再加上你们没有人会写测试，每次改完都要一一手动检验成果，很难快速与完整，
这使你们相对不容易检查出前面那些问题，专案因此曝露在失控的风险中。
最起码等到有人先引进测试的做法，系统运作逻辑也稳定下来后才适合去落实其他原则。
整体而言，目前的状况你觉得烦...我觉得合情合理，没什么问题啊~
是我的话也会叫他们先指出那些想重构的地方并记在 issue tracker 上，
待时机成熟时再来搞这些东西~