程序員們在寫自己用的小程序的時候會考慮設計模式，編程規範等什麼嗎？還是夠用就好呢？

01-05

模式並非是一種照貓畫虎的技能，並不是你先根據需求，然後去書裡面查找能用的模式，再考慮是否要用上。模式是千百種程序的提煉，當你寫過某程序的第一版之後，你自然就會發現哪些地方設計得不好，導致後續不爽，你第二版自然就會進行改進，或者遇到類似問題時你自然就會有所預先考慮。學習設計模式的目的就是在你自己第一次遇到問題時，能夠更快地發現前人經驗對這個問題的解決方式，讓你走得彎路更少。所以無論如何，你需要多實踐，多設計，很快你就會發現應用某些模式簡直就跟吃飯睡覺一樣自然，完全沒有需要提問的必要。

模式就像成語，剛學會總是想找機會用用。長大了就覺得瞎用成語很傻

編程規範當然要遵守，但不用刻意，都成習慣了，想寫不規範的反倒費勁。

設計模式基本沒用過，因為這種東西是搞正式項目、多人協作時才要用的。自己寫的個人程序，源碼全在自己手裡，需要擴展時直接去改基類、改底層庫就是了……

那你要問如果個人項目做大了怎麼辦？整體重構啊。

最重要的是一定要加註釋！不然隔一個月就變成別人的代碼了，想讀懂還不如重寫一遍。

有代碼潔癖的人越是寫給自己的東西越有潔癖

如果是個離線業務，一次性的代碼比較dirty，快速完成就可以了，畢竟老闆喝著茶在等你消息呢，不會考慮什麼模式。生產代碼肯定要考慮架構和模式問題，主要為了可維護性和可擴展性。

對小應用來說，不應該隨意按流水賬方式去編碼，程序員的時間都是很寶貴的，既然開始編碼就應該以寫出高質量的代碼為目標，麻雀雖小五臟具全，這是很好的鍛煉方式，不應該懶惰而放棄這樣的機會。從另一個角度來說，程序員的部分成就感來自於優美的代碼和清晰的邏輯，如果急功近利隨意編碼，是不是軟體做出來也會感覺缺少點什麼呢。

懶惰是一切罪惡之源，不管應用規模多大，等到後期維護的時候，你就能嘗到不規範開發帶來的苦果。不太贊同上面有人說的快速開發完再重構的說法，其實軟體開發從一開始就應該規範編碼，重構不過是一種升級項目的輔助手段，而且好的設計模式和編碼規範是提高開發效率的手段，而不應該是耽誤開發進度的理由。

設計模式和編碼規範我認為是一種習慣，不同的場景會有不同的習慣，軟體的規模、功能、交互方式等不同，造成會去使用不同的設計模式，編碼規範也因習慣、語言等原因而變化。所以對我來說，會根據不同場景來選擇特定的設計模式和編碼規範。

代碼規範肯定是需要的，尤其是代碼風格和一些最佳實踐。變數如何命名比較舒服，代碼怎麼寫能最大程度實現 self-documenting，這都屬於個人長期養成的習慣，不管是幾百幾千行的小項目還是需要多人合作的大型項目都一定會有所體現。

設計模式則往往是從規模和實際需求出發的，跟項目是否「自己用」沒有必然聯繫。就算項目從始至終只有你一個人維護，一個設計良好的架構也能很大程度上讓代碼清晰易讀，從而降低寫出 bug 的幾率，對日後的維護和擴展也大有幫助。換句話說就是自己寫著也爽，以後看著也爽。

但是設計模式這個東西不能說我今天聽說了 factory, proxy, singleton 不錯，明天就一定要把它用到代碼里。寫代碼是為了最終需求服務的，不是為了設計和寫出幾個設計模式。設計模式本質上是對某些問題提出的通用解決方案，如果還沒遇到問題，何來解決方案？因此當你的程序抽象複雜到一定程度，覺得不知該如何下手或怎麼寫都不舒服（例如需要大量膠水代碼、程序各個部分耦合嚴重、修了 1 個 bug 又出現 10 個 bug 等等），就很有可能是因為你的設計有問題，需要進行修改和重構。有經驗的開發者會自然而然的對這些問題採取恰當的解決方案；對於初學者，必須經歷這個發現問題的過程才能把「設計模式」用靈活。在項目開始的時候，不需要過早設計和優化。

設計模式，編程規範等，代碼寫多了會形成一種本能的。

絕不是亂用、套用，是根據場景需求，去平衡取捨的。

設計模式能用上的時候，自然會用。

但前提條件是代碼量超過一定數量以及是否需要合理的對象管理。

首先是設計模式本身的架子也是要一定的代碼量的。要是你不用設計模式寫出來的代碼只有很少一點，那麼用設計模式就多餘了。

其次，如果無所謂對象生存周期的嚴格管理，只是為了驗證某些小演算法。不需要內存管理，大部分對象都是一次性的，那基本上不需要。

代碼規範啊，這個想違背也難了。寫的不好，自己看的難受。多少有點強迫症了。

學多了會變成本能的。

不能習慣性使用的話說明你沒學透。

至少我會

不然難受

最近看到臨時變數賦值就難受

做了個do函數

把各個函數串起來【haskell里叫monad】

有庫叫pymonad 但我只是想要把函數串起來

考慮，現在看到惡心得代碼，總會花點時間把他砍幾刀才舒服

都可以看作是某種問題的解決方案，包括設計模式，編碼規範什麼的。這些東西都是幫你避開坑的。一般新手都要被坑幾次才知道重要性。

首先設計模式從來都不是一個照葫蘆畫瓢的東西...

面向對象的特徵就是封裝,多態,繼承...為了解決的問題就是解耦...複雜問題拆分小問題...

而設計模式,是為了達到面向對象需要解決的問題由此誕生出來的工具...

而且解決實際問題時,基本沒有什麼設計模式可以單一使用...

所以,當你熟悉了一些設計模式以後,解決實際問題的時候,是會根據自己對模式的理解,來優化自己的代碼的...因為當你的level達到一定的層次,即使寫小程序,也會不自覺的遵循面向對象的原則...

所以,題主問,寫小程序是否會刻意的使用設計模式...我的答案是不會刻意去用...

因為我出於本能的,要寫出面向對象的代碼...

至於編碼規範???

你說的是變數命名么?在程序達到一定程度之前,我一般懶得刻意去取名字,一般就abcd了...(不過我會寫注釋)

用熟了之後，就沒有設計模式的概念了。代碼本身就能流露出相關的設計思路。又何必刻意去想怎麼用設計模式呢？

大部分都被libraries實現了，你寫的那點業務邏輯代碼應該不需要這些玩意兒。

最開始的是不會的，先把最主要的邏輯實現出來。

後面再添加特性，進行修改的的時候，就會明顯的感覺到不方便，這個時候就會思考、套用一些設計模式。

然後一直迭代。

這樣的程序寫的多了，心裏面大概就有譜了。

在寫之前，心裏面大概就已經把設計模式想好了。

模塊該怎麼劃分，該怎麼解耦，怎麼相互調用，已經能夠想的七七八八了。

設計模式不能強硬套用，根據實際的情況去優化，

優化了之後再翻書，就發現，咦，好巧啊，差不多就是這個模式。

我個人認為，設計模式是經驗的總結，照搬和學習可能會生硬，反而糟糕。

代碼的注釋什麼的，一定不能省。

總代碼量1/3屏以內可以隨便寫不裝函數都無所謂

過了就必須class

設計模式看需求比如開多線程的爬蟲多進程的照片格式轉換什麼的就要不然進程間管理很亂

雖然小程序但是經常比生產系統還cpu/io intensive啊

過度設計、不正確使用設計模式本身就是反模式。

在考慮設計模式的時候主要還是要考慮設計模式反應出來設計原則，在head first上有很好的體現，他雖然在說設計模式，但是更多的是講為什麼這麼做，然後講怎麼做，體現什麼oo原則。設計模式可以不用，oo原則還是要考慮的。