寫程式，第一步想的不是資料結構也不是演算法。

首先，需求者會丟出想法，需求者可能是老闆，可能是End-User或自己。

接下來第二步，我會用直覺，真的就用直覺，應該說資訊科學的學養，想看看這種想法能不能實作出來，試著跟需求者溝通後調整。

第三步，大致上在紙上畫出幾個系統架構，衡量自己熟悉與不熟悉的部分，當不熟悉的份額太大時，往往是失敗的開始。

第四步，幫不熟悉的技術部分找到資源，大部分來自書籍與網路資料，並就瓶頸技術部分先寫一些小程式熟悉並突破。

第五步，當所有不懂的部分都有些眉目之後試著把這些技術，組合起來，就變成了系統。所謂有眉目，就是有自信在系統開發時完整時做出來。

接下來回歸主題，每個功能怎麼安排。以物件導向程式設計的觀點來看：

第一步，要切割class，以及繼承關係。

第二步，盡可能地列出member function的名稱，包含Constructors，Destructors，operator overloading，對呀，只有名稱。

第三步，盡可能地列出data member。

第四步，開始設計member function，由被呼叫的class著手(比較複雜的function，需額外寫一些簡單的驗證程式)，一邊寫一邊調整data member、member function與class的切割，包含member function的修飾子(public or private等等)。

第五步，除錯。

系統架構 不是 [程序員] 該去思考的

程式設計沒有SOP, 如果真的要說有, 應該是系統規格書, 不管程式如何寫, 程式運行的結果一定要符合系統規格書的規範結果.

程式設計是門藝術, 好的程式設計師寫出來的程式, 您可能永遠不知道他(她)如何寫出來的, 有一套大堆頭的書: The Art of Computer Programming, 雖然已經很久了, 但內容還是學好程式設計的人可以參考的.

寫程式就像是寫給電腦看的工作指示書, 如果一定要說有什麼想法, 就是能不能像電腦一樣的思考吧!

不具思考能力的不叫程設師叫打字員
我們這邊每個人都要會思考
為怎麼這麼做，為什麼這麼寫
系分師，架構師有時候不會思考到很細的部份，他們思考的比較概觀，影響層次比較大的部份
程設師不能這樣寫，不能這樣做，狗屎的公司
如果我帶，你要告訴我理由，問我問題你要先想過
如果連自己都沒想法，不但你辛苦，你的架構師也辛苦，錯都不知錯在哪裡，而且也永遠不會進步
寫程式就去看
你要寫車，你要知道什麼是車
你要知道車有哪幾個部分
你要知道你要做什麼車
你要知道車的哪些部分是你要做的
哪些部分該用買的
你要知道什麼先做，怎麼後做

先從最簡單的開始著手是一定的
當寫小工具都沒問題時 可以慢慢朝更大的架構開始著手
當你程式寫越多 累積的經驗也就更多
或者你也可以從"抄襲"開始
從別人的程式開始看或許會有很多不懂
但也能夠知道人家的精隨

流程（精簡版）
想法 => 紙筆 => 動工 => 驗收跟修正

不過，要用什麼方法構成程式，要靠撰寫程式的經驗

這跟規劃不一樣

規劃不需要你要多會寫程式

兩馬子的事情

你的問題就是你的解答。

你想要寫程式，目的是什麼? 因為公司有一個需求，而你認為要用程式去達成這個目的。

所以，你的目的是什麼？

從你的問題可以猜想，也許公司想要把銷售這個部份給系統化，而你覺得弄個購物系統是個辦法。所以你想寫個程式來達成具有購物系統目標。

也許我猜錯了，你只是想學programming，那麼程式語言這麼多種該學哪一種？

我的建議是，先從公司內部已經有的系統去研究，先了解公司運作流程、程式邏輯與基本的語言結構，想辦法去改善它，這比重頭打造一個新系統來得有效率。

為什麼是先從公司系統入手？因為上班時間研究公司的系統不浪費時間也比較有成果，一點點的改變也可以提高你在公司的價值。

程式百百種，邏輯只有一個。

理解、分解、再構成....

你需要看這一本書：

Code Complete: A Practical Handbook of Software Construction

它是一本軟體構築的實手冊，有中譯本。

可以研究一下 UML 及 OOP ..

另外，對於所使用的程式語言儘量的熟悉核心規則、開發工具、相關的 API .. 等，當這些知識越多，就會有越多更好的想法幫助你的程式開發。

網路上可以找到相當多開放源碼的專案，都可以研究研究，從別人的程式中推想為什麼要這樣寫，這樣寫有什麼優點和缺點；開發速度、程式執行效能、執行時耗用的資源、未來維護流程、將來的擴充、新加入的人員接手難易度、多人開發的配合方便性、使用不同程式語言所開發的系統間的介接、多國語系... 等等，依照需求重點的不同，都會影響到程式開發的想法。

不過，我猜你想知道的應該是製作流程，提供給你參考參考...

1. 為系統定義變數成員、常數、編碼規則、功能行為(函式名稱)、狀態項目、事件..等。
2. 為系統功能、行為、事件、使用者介面、資料管理、語系辨別管理、例外處理... 等分類拆分為獨立區塊。
3. 畫圖，程式運作的程序流程圖、使用者的操作動線圖、系統結構圖、資料關係圖... 等。
4. 依照畫的圖，為拆分的區塊個別撰寫內容的程式功能及行為邏輯。
5. 測試及除錯。
6. 簡化程式碼、優化效能、降低資源。

大致上這樣，有點籠統，還是要多實作才比較會有心得。

初期寫程式就像是寫文章一樣，目的是如何完整的將你的需求表達出來讓電腦完全明白並完成所交付的任務；慢慢熟練後，就要開始練習如何不多說廢話，相同的判斷與演算規則不應該在多處地方重複出現，不斷的複製貼上是文書處理人員在做的事，不應該是寫程式的人在做的工作；之後，就要練習多說成語了，一句話在很多地方用起來都很通順，讓同一支程式放到另一個系統中，一樣能正常運作。

想法就在日常生活中。

一個塑膠袋，要放進大小不同的十件食物容器，容器分別裝有固體液體食物...
怎樣放才會好提？
怎樣放重量才會平均？
怎樣放液體才不容易晃動滲出？
怎樣放才容易取出？

聽起來像是超市收銀員的工作？是的，一位好的超市收銀員，應該具備好的收納本領，幫客戶把東西放妥..這就是行行出狀元的意思。

程式設計的原則和邏輯是一樣的..只是領域不同。