程式設計有點像搞園藝。比起竭力去對付bug（蟲子），我們更願意把一切弄得整潔有序，以免最後落得個身在荒野叢林中。低劣的架構會拖我們的後腿，也會使得bug更容易鑽進系統裡去。
想要對你的專案進行架構，方法有多種。我相信，根據你的實際情況對架構進行演進，要遠比堅持一些條條框框的教條更好。接下來我將會介紹一些基礎的方法以資您思考。
將所有的東西都放在乙個檔案中
最簡單的專案可以被放到乙個檔案之中。而這就是我所選擇的用來處理我的webpack 配置的方法。這種方法最大的好處就是所有你需要的東西都在這乙個檔案中了。如果你是從上到下對你的**進行組織的，那麼這就會是乙個合適的做法。
你可以用類似的方式開始乙個react專案的工作。當你在進行原型設計時，想要去試圖弄明白層次結構，就可以在乙個檔案中把元件都梳理出來。而這樣會隨著檔案的慢慢增大而變得笨重起來。例如對測試的處理就會比原先要困難一些。檔案分支的合併也將會是個問題。
拆分成多個檔案
解決這個問題顯而易見的方式就是著手將一些東西進行拆分。開始的時候你可以把各個元件挪到各自分開的檔案中去，像這樣：
如果你想要對你的元件進行測試，可以增加乙個用於測試的單獨的目錄，並在那裡面進行測試**的開發。甚至你還可以嘗試一下測試驅動開發的方法，在實現之前就全盤考慮好元件的約束條件。
使用這個基礎的架構你可以走得相當的遠。儘管它也有它的侷限性。例如，如何處理樣式？主樣式檔案 main.css 可能會變得相當的大。其前景是有點可怕的。
將元件放到它們自己的目錄下
③ 現在與每個元件相關的測試可以不費吹灰之力就能找到。我們也可以仍然在專案根目錄下擁有乙個 /tests 目錄，以用來處理更高階別的測試。
當然真實的專案複雜度會更高，而當前的這種架構將開始突破複雜度的限制。不知道這適不適合你的想法呢？
將檢視新增到架構的組合中
這種架構遠還可以進一步擴大，不過即使是它，隨著專案的增長也會受到限制。我建議在檢視和元件之間增加乙個像「功能特性」這樣的概念。功能特性就是以某種方法和形式對元件進行聚集，當然功能特性本身也是可以聚集的。
處理資料問題
鑑於大多數實用的應用程式都得對資料進行不同程度的處理，我們目前的架構所做的可能還不太夠。這在很大程度上取決於你選擇了什麼樣型別的架構。將一些資料問題放到當前的架構中處理或許還是可以的。或者你可能會引入新的根級別的目錄，比如 /actions、 /constants、 /libs、 /reducers、 /stores，這裡只是給你提供一些思路。
總結
譯者：傑微刊－leo xu
建立乙個react專案
之前一直在用引包的方法使用react，現在學習react基礎也有一段時間了，想工程化的完成乙個react專案，結果只是搭建react就糾結了好久。參考了很多大佬的方法，但是一直有問題，最後總結一下我的成功辦法吧。在命令列工具中確定node是否已經成功安裝 npm vnode v均出現版本號則說明安裝...
如何清晰地描述乙個專案架構
要讓對方掌握專案架構，乙個清晰的介紹架構和順序可以事半功倍。在介紹專案架構之前，首先要介紹一下專案本身的意義和目的，便於對方了解專案背景 專案針對使用者需求或問題，開發了哪些功能 在介紹功能的時候，最好要有使用者視角，而且可能還涉及到多個不同角色的使用者。比如tob的終端使用者，b端企業使用者，企業...
react開啟乙個專案 webpack版本出錯
npm start 在命令列裡執行以上語句就可 前兩天剛剛發現，最新版的react對webpack的版本要了新要求，大概是他新加的內容使用到了webpack高版本中的一些內容，所以使用時注意你的node版本和webpack版本，可能有一些版本要求 就是這麼的簡單 如果本文對您有幫助，請抬抬您的小手，...