一般程式設計師在拿到需求的時候就直接開始寫程式碼了，寫的時候就會發現由於功能的增加，程式碼越寫越多越來越複雜，到後期的時候會造成難以維護；

初級程式設計師在拿到需求的時候，應該梳理一些頁面設計，一個頁面分為什麼板塊，並且清楚的知道有什麼需求和時間，每個時間應該dispatch哪些action；之後就是這一頁的模組當中哪些資料是要放在store裡面的，哪些模組要放在state裡面；

提升設計程式碼的能力：

大家可以瞭解一下TDD：測試驅動開發，可以自行百度百科一下。

TDD的原理是要在寫程式碼之前就要用寫測試用例，這時候你必然就要思考每一個函式和每一個模組還有元件應該如何設計才能使得易於測試，我們也要清楚易於測試的程式碼在後期產品成型之後都比較好維護。所以TDD可以幫助我們設計程式碼，也就是在拿到需求之後不去盲目的寫；

當然也有很多人說TDD很麻煩，這裡只是希望藉助工具幫我們提升在行動之前的思路，至於養成這個習慣之後大可不必再去用了。

初級與高階對產品的理解偏差：

很多初級的程式設計師，都在考慮的是技術的問題，但是偏高階的程式設計師再此基礎上還會思考業務的需求。講一個故事：

我在HW的時候，負責一個版本的開發，這個版本的工作量大約是2000行左右，但是我除了做完這個功能，還將關聯的功能全部掌握清楚了，程式碼（大約10000行）也全部看了一遍，做完這個版本後，我對這個版本相關的整套業務全部很熟悉了。經過一兩次會議後，大家發現我對這塊掌握最熟了，接下來就有趣了：產品討論需求找我、測試有問題也找我、老大對外支撐也找我；後來，不是我負責的功能他們也找我，即使我當時不知道，我也會看程式碼或者找文件幫他們回答。最後我就成了我這個系統的“專家”了。雖然這個時候我還是做業務的，還是寫業務程式碼，但是我已經對整個業務都很熟悉了。

對於企業老闆來說，他基本上不會管你用什麼技術和特性，也許你讓程式碼更加簡潔了，但是在線上出現問題了，你寫的東西還是不行。如果你要是像我講的故事一樣非常注重業務，並且對於產品的需求和測試都很瞭解的話，你會成為辦公室的“專家”，領導自然而然看重你。