There is no prefect, there will always be struggle
Before you go. 2014

一樣，中文在下面～～

The design of projects actually contain different layers, from the higher layer of functional defined, effecticency demand, restrict of design, to lower layer of pseudocode, class uml, design pattern, and the proportion actually depends on project size and team size.

The higher layer of design could obtain multiple small architectures, whatever it is multiple modules, MVC, MVVM, Redux or others. Design itself is a process to transfer the demand to real program, although we all hope thing could run properly, but design of project could be change, it might be follow the consistency of full project, demand changed, framework limit or other reason, facing the try/ error is usually, just remember one thing, there isn't a best design or best architecture for all software, only the one suit yours.

think about complexity

The cause of complexity is not always about coding, it could include demand, infra, communication, but to us as engineer, we try to make the reasonable, decouple, easy to maintain application from a chias real world, and the complexity only growth with the real world problem size.

The best thing we can do is divide and conquer, yes just like the algorithm, we divide problems into small pieces, rather than one huge concept, we humans are better at handling multiple simple blocks. This is not just fit program design, it is divided into pieces that should be implemented into abstract, class, function, variable...etc, almost every part of the program could use it to decrease complexity.

readability and complexity

The following question is common, I have a demand, should I focus on complexity, readability, or consistency, in my opinion, a simple and readable solution, is better than efficiency but difficult solution, the program itself should be easy to understand by other engineers, and with the solution, when we facing to preference optimize, we could easily understand what problem it try to solve, and make a proper schedule for refactor it, this is more effective than trying to find the minimanize BigO solution for every demand.

中文

專案的設計包含了不同層級，從較高層次定義的功能、效能、設計限制，到更接近編程的虛擬碼、類別依賴圖、設計模式等等，而高低層次的設計佔比會依照專案和團隊的大小而有所不同

高層級的設計，應該要能包含多個低層級的設計，不論是多模組, MVC, MVVM, Redux任何的架構都應適用，設計的本質是將規格書轉換為可運行的代碼，儘管我們都希望設計可以一次到位，但這卻不切實際，會造成設計更動的原因很多，像是專求變更，維護一致性，框架限制，語言特性等等，整個過程需要不斷地試錯，已找到最適合現在專案的設計

考量複雜度

造成複雜度的原因不總是在編程，其中包含了需求，infrastructure, 溝通等等，我們作為工程師，要把不斷增加複雜度的現實需求和狀況，變成有著合理設計，低耦合，易維護的程式，

而應對的方式，就是分而治之，就像是那著名的演算法，我們比起處理一個大問題，更擅長應對多個小問題，而這不僅適用於專案設計，在抽象、物件、函式、變數等真實程式的各層級也適用

可讀性與複雜性

常常聽到一個問題，有一個新需求，在撰寫時應該要注重哪點，可讀性、複雜性還是一致性？
以我來說，一個可讀且簡單的程式，遠比複雜且難懂的程式好得多，工程師寫的程式，不只是要可以運行，還要能讓其他人可以理解，當我們真實遇到效能問題時，一段好理解的代碼，也能明確讓工程師知道他處理了什麼問題，從而根據效能難點做優化
這種作法，能更合理的規劃時程，也不會變成在每個功能上過度鑽牛角尖，寫出過度設計的代碼