1.設計控制流程圖

        工程師進行到開發軟件這一步時會情不自禁地開始書寫代碼。這種思維定勢就像在原理圖還未完成之前就開始嘗試畫PCB。當著手開發軟件時，克制寫代碼的沖動，取而代之的應該是軟件流程結構圖表的設計，這點非常重要。流程圖能清晰地呈現給開發人員軟件的各個需要的組成部件，正如電路圖列出硬件設計所需的各種元器件一樣。做到這點能很大程度上使程序整體更易于組織，而且也會減少占開發周期較長的調試工作量進而節省時間減少調試的繁瑣。

        2.使用狀態機控制程序

        流程狀態機是20世紀優秀的軟件發明之一。應用程序一般被分解為多個不同的狀態，每一個狀態控制一個特定的程序分支。狀態機包括內部狀態和依據不同激勵所控制的狀態轉換。使用狀態機機制設計軟件能夠使模塊化的可維護的軟件開發更加容易而且易于理解。狀態機原理與算法的示例隨處可見。

        3.避免使用全局變量

        在過去的函數式編程中，程序員使用函數編寫程序，他們的唯一目標是使程序盡可能快的運行而不考慮程序的結構和重用性。這類程序風格在使用全局變量時不注意變量的作用范圍引起其他函數修改的危險性。這樣變量會被多次占用和重寫。如今面向對象的程序設計中，成員變量被定義在最小的作用范圍之內并封裝起來避免被重新復值和濫用。所以建議盡量少地使用全局變量，實在需要的話，使用C語言中的關鍵字“extern”來修飾。

        4.充分利用模塊化的設計理念

        如果你問一位工程師項目的哪一部分最有可能會拖延交付并超出預估時間，那答案一定是軟件周期了。軟件通常是復雜而且不易開發和維護的，特別是當項目應用程序集中在一個單一的文件里，或者幾個結構松散的文件中時。為了便于代碼重用和軟件可維護并減小軟件的復雜度，強烈建議發揮高級程序設計語言模塊化的特性，在程序的結構中把公用的函數分離出來作為一個獨立的模塊。通過這種方式可以讓程序員開始創建包含有常用函數和常用的聲明定義，它可以很容易的被其他的代碼重用，這在以后的測試階段不僅可以節省時間代價還能提高代碼的質量。

        5.中斷服務事件

        保持簡練中斷服務事件是中斷處理器正在執行的程序，轉而去處理觸發該中斷的外設的請求的一種機制。處理器響應中斷請求需要大量的系統開銷，具體表現在保存被中斷程序的狀態（入棧下條指令的段地址、偏移地址和程序狀態寄存器，有時還會入棧若干寄存器的值），執行中斷服務程序然后恢復中斷點繼續執行（依次出棧各寄存器），雖然現在的處理器速度非常快但是這種系統開銷仍然需要考慮。一般來說，為了避免與主程序沖突程序員總想使中斷執行時間減小到最小。這就意味著中斷服務事件應該短小簡單。不能在中斷程序中調用函數。另外，如果中斷需要處理的事件特別復雜或者需要花費較長的時間，這個時候中斷服務程序應該滿足最小的需求，例如將數據載入到緩沖寄存器、設置標志位，而讓主程序去處理讀入的數據。這樣處理器的工作大部分周期都在處理程序而不是中斷。

        6.使用處理器示例代碼

        測試設備對于硬件設計，在畫板之前標準的測試電路有助于工程師理解電路的特性。同樣可以適用于軟件設計，半導體廠商通常有測試微處理器各個部分的功能的示例程序提供工程師體驗各部分是如何工作的。據此可以提前組織軟件的結構并且預知在設計中的問題。提前確定在設計潛在的障礙遠比在產品完成前幾個小時發現問題更加科學合理。而值得注意的是廠商提供的代碼通常不是模塊化而且不做必要的修改是很難直接用于實際的軟件中的。

        7.控制函數的復雜度

        在工程設計中有句俗語叫“KISS”，意思是“Keep It Simple Silly”。在處理一些復雜的任務時最簡單有效的方法是把它分解成若干個簡單的子任務，當任務或者功能很復雜時，人們很難留意所有的細節也很難不出錯。當工程師寫了一個在當時能夠理解的復雜函數，可一段時間后需要維護程序了還能不能清晰的呈現出當初的設計思想這是值得考慮的。有大量的技術來衡量函數的復雜度像“循環復雜度”。經驗告訴我們，函數的循環復雜度應該低于10比較好。

        8.詳細的文檔

        在激烈的軟件開發競爭中關注的焦點很容易就局限在代碼的書寫和調試而忽略文檔的編寫。有時迫于壓力要求寫文檔，開發人員通常把文檔安排在項目開發的最后的一個環節集中編寫。然而給代碼寫文檔應該乘在頭腦里面還比較清晰的時候比較關鍵，這樣在后續的開發或者自己閱讀注釋的時候能很快的回憶起當時的設計思想。