软件开发有个情境或许大家都不陌生：
团队可能接手外包所开发的程序，或是接手团队其他成员所写的程序继续开发，
但碰到了一些难以继续开发或维护的问题，这些问题造成的原因可能很复杂，
成因可能都与你无关，但你无法改变过去，却也害怕改变现状。
例如：
专案没有留下文件，且当初时并没有订定良好的规范，程序码的实作杂乱无章，常常有无法预知的 bug。
专案没有写测试，当初交付时也没有完善的验收流程，接手时发现专案与预期落差太多。
重点是，目前接手的这个专案，已经上线了！
对於持续开发或维护一个已上线产品的团队来说，常常是进退两难，只能一直长痛下去。
因为没有测试，没有文件，谁也不敢乱动，索性就不要随便动手好了，反正线上的东西还能动就好，深怕一动了，就下不了班了。但是若要加新功能又只能在目前的债上继续加债下去，每天还有找不完的 bug 要修。
然而放任这个痛楚一直持续下去的话，其实也影响了团队的效率及产出价值。
有时候在负面的情绪之上，刚接手的人很容易冒出一个念头：重写啦重写啦，砍掉重练啦。
但是重写就能解决问题吗？
请再回想一下，我们必须要解决的是「现实问题」，但我们必须考量「现有资源」以及「时效」。
这个时候需要好好思考一下这三个面向，才能好好做决策：
（呜呜，这里其实要好好说明一下，但目前来不及）
每个团队面对的情境都不一样，没有一套能完全复制来照着做的决策与流程。
因此，身为团队的一员又或者是管理者，如何评估利弊及情势，又是一门学问了。
明天再来讨论一下团队及管理者的关键要素。
啊啊啊啊啊啊啊，我明天开始一定要好好写文章
每天都压线好哭哭
我这麽废，菜逼八的，哪时候才能当快乐的 IT 管理人，哭哭
>>: Day2. 好设计的准则- 从生活中的物品理解什麽是好的设计
v-on 监听DOM并进行触发 v-on: -> 简写 @ v-on:click="...
8.5 一些 Leetcode 例子 今天来拖点稿子，解几题跟连通有关的题目吧。 Leetcode ...
mutation 当作 state 的 setter 使用。 要符合 setter 的使命，挡掉错误...
为了让 Gradle 在运行的时候可以更弹性，Gradle 支援一系列载入建置环境（Build En...
在「排序大家族」这个主题，会介绍几种常见的排序，也会简单分析他们的特性和演算法，第一天登场的是气泡排...