84669 人學習
152542 人學習
20005 人學習
5487 人學習
7821 人學習
359900 人學習
3350 人學習
180660 人學習
48569 人學習
18603 人學習
40936 人學習
1549 人學習
1183 人學習
32909 人學習
当我们构建一个App的时候，经常会对设计模式，架构进行选型。也有可能因为需求的变化导致最初的选型不是一个最优解。那么，在极端情况下，我们就会选择过早优化。
但是架构并没有完美的，所以，我们在开发的过程中，是一边开发业务需求，一边重构比较好，还是一开始想清楚，再下手比较好？
走同样的路，发现不同的人生
「過早的最佳化是萬惡之源」這種說法對不對，為什麼？或許可以參考一下這個問題
任何時候優化程式碼結構都不早
不知道你們的開發方式是什麼樣的。
一開始就想清楚這個是比較理想的情況，這樣的時候並不多。
最好是在每一個sprint裡（或開發週期）用一部分時間優化結構。不要等！一旦等的時間稍長，基本上架構只有被替換或將就著一直使用了。
而且，花費大量的事件在程式碼架構的最佳化上也不太可能。畢竟業務線不會給那麼充裕的時間。
Work -> Right -> Fast並不是寫爛程式碼的理由
「過早的最佳化是萬惡之源」這種說法對不對，為什麼？
或許可以參考一下這個問題
任何時候優化程式碼結構都不早
不知道你們的開發方式是什麼樣的。
一開始就想清楚這個是比較理想的情況，這樣的時候並不多。
最好是在每一個sprint裡（或開發週期）用一部分時間優化結構。不要等！一旦等的時間稍長，基本上架構只有被替換或將就著一直使用了。
而且，花費大量的事件在程式碼架構的最佳化上也不太可能。畢竟業務線不會給那麼充裕的時間。
Work -> Right -> Fast
並不是寫爛程式碼的理由