怎么說呢，最近遇到一大堆程序的時候真的有點手足無措，感覺很被動阿。

迎難而上才能有所得。這次的經驗是面對一大堆要寫的代碼該怎么辦呢？
答案：先搭框架！
其實上面這四個字著實有點太忽悠人，寫代碼少的人很有能夠真正理解框架是什么意思。其實這個詞含義真是太豐富了，可是現階段我自己的所謂的框架，就是要完成我的功能，需要添加的代碼的結構。

1 分解的過程，也就是理解和總結思路的過程，這種形式的分解粒度可能會比較粗，這種形式分解結果將其寫在紙上。包括model，behavior等等。

2 假如現在準備寫某一小塊的代碼了，可是由于代碼可能也不是那么直接，可以在更具體的級別再進行一次分解。這次的分解結果函數之間可以寫出函數體，函數內部可以將分解的各個塊的注釋一一羅列。然后在寫代碼的時候不斷的填充這些函數和注釋和分解這些內容即可。

P.S. 自己在寫程序的時候，不論是同一模塊或者是不同模塊的關鍵的接口函數的注釋一定要清晰，注釋要包括此接口函數的粒度，在整個模塊中的位置，參數類型，參數的意義等等。。不然后果不堪設想。

補充1:
有時候在大框架時候，也一時不知道該如何各個步驟去做什么？這是因為要寫的部分的運行機制沒搞清楚。這個時候，應該拋開代碼，找到機制的核心最關鍵部分，畫出圖和數據結構來，理一下這部分怎么成功運行的。然后在將其按照上面說的“注釋化”，“代碼化”。
總結：這是個由粗到細循環往復的過程。精簡如下：
核心機制--->機制分解細化--->機制分解具體化---->想好程序接口---->將接口內部的代碼注釋化---->"代碼化"
在上面最后一步的代碼化的過程中，可能就又進入了上面的這個思考流程中，這是由粗到細逐步細化代碼的過程吧，我是小菜，不斷總結學習。

補充2:
進行補充1中的注釋化的時候，要注意很好的區分程序的層次，即是將邏輯處理層，物理操作層區分開來。其實這也就是由粗到細的過程，粗的層面可能對應于邏輯控制，細的層面可能對應于更加細致的邏輯控制或者是物理操作。因此一開始先注重邏輯，而不要太容易陷入物理操作，這樣也是在不斷的開發過程中明確需求的好辦法。
在寫某個函數的注釋化的過程中，要定位此函數的操作粒度，是高層次的邏輯處理層，還是低層次的物理操作層，不要將不同粒度的操作寫在一起，同一層次的操作的粒度要盡量趨于一致，這樣有利于層次的劃分。

補充3:
要認清自己在寫的代碼的定位，然后用不同的方法來研究需求。比如說以前寫的代碼是應用型的代碼，下層都有完整的接口，只要想清楚用戶希望把產品做成什么樣子，那就利用這些現成的接口去做就好了，技術思想的要求上真的沒有那么高。

可是現在我自己在寫文件系統，首先在上層碰到的問題是我該如何設計向上層，向用戶提供的接口？他們需要什么操作？各個操作的參數又應該是怎么樣的？需要好好學習這一塊。
現階段再沒有強大理論做指導的情況下該如何設計接口函數呢？最簡單也是最實用的方法是--站在用戶的角度嘗試著去使用這個庫，將接口函數設計成用戶使用最方便的樣子。

接口函數的聲明定義要包括3方面：

• 各個參數的意義，參數是I/O。
• 函數真正的功能，就是說此函數究竟想去干什么。
• 返回值的意義，是不是不同的返回值代表不同的意義？比如是不是-1代表出現錯誤了？

只有接口函數使用時候的以上3點的需求都是清晰的了，我們使用interface function的User才能更加了解程序，對于開發接口函數的人來說這就是需求，我們需要了解清楚以上3點的需求，才能寫出好的接口函數。

補充4:
作為一個模塊庫的開發者，需要分清楚錯誤的來源，從而區別對待。
假設用戶調用open函數來打開一個文件：

• 如果是因為用戶輸入的參數導致的打開文件失敗，FileSystem里面處理這一塊的函數要嘗試將錯誤碼層層的返回給User調用。
• 如果碰到譬如inode用盡這種情況，不用再返回給用戶了，這種嚴重的系統錯誤就直接panic暫停系統就行。

當然在寫程序的時候，主線還是將錯誤碼層層返回給調用者User。在遇到嚴重系統錯誤時候，單獨對待處理。

補充5:
在閱讀別人的代碼時候。先提前思考下要是自己去寫這段代碼會是怎么樣的布局，會去怎么樣寫。自己真正的去思考過了，再去看別人怎么寫的，再去取長補短，這樣也容易理解對方的代碼。

總結

以上是生活随笔為你收集整理的面对困难的代码，分解困难各个击破的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。