雖然從事軟體開發很多年，但是從未認認真真的思考過軟體功能開發應該怎麼去著手做，往往都是需求來了，僅僅去實現「它」。
從工作角度來說，有什麼需求做什麼「需求」，以「最終需求結果」為目標原型來做，實現乙個和「最終需求結果」近似或一樣的目標，這是完全正確的。
但是從軟體開發層面來說，僅僅是完成任務是遠遠不夠的。
在堅持軟體設計的基本原則（可靠性、健壯性、易於擴充套件性、安全性等等）的前提下，如果能引用更適合的設計模式來解決問題，那麼請使用更好的設計模式。
功能開發其實和做事一樣，要想功能做的好用，思考必須全面，各種輸入情況都要考慮在內，雖然不同體量的軟體的開發採用的標準在嚴格程度不一樣。
比如商業軟體一般會採用「防禦式」程式設計(對於外部提供的函式引數採用不信任策略，必須校
驗引數的型別與值是否合乎要求），這樣就會攔截異常的請求，把引起的panic問題扼殺在
函式入口部分；大部分的內部軟體開發一般只是約定好介面引數名稱，對於接收到的值，
可能會做一下型別轉換，增強一下「健壯性」（要注意：型別轉換在部分情況下是有損
失，如果是字母轉數字，可能是致命的），如果不轉換，那麼資料可能就會引起panic了。
另乙個就是看你腦子靈光不啦，做軟體的大約一半的人腦子不是那麼「聰明」（聰明人都去做投資賺錢了，早就實現了財務自由，哪還寫什麼**）。我們要死背設計模式（二十三種設計模式，是先驅工程師們留給我們的瑰寶，待我回頭編個歌謠，背記起來更方便），然後在適當的情況運用適合的模式及模式組合，提高軟體開發的抽象層次，提公升自己的抽象能力，鍛鍊自己的架構能力，增強自己的見識。
拷貝貼上一把梭，對於能力的提高是沒什麼用的，唯手熟爾，當然對於吃喝來說應該是綽綽有餘了。
最後一點，軟體抽象分層固然很好，但是最好還是保留每個抽象層對開發人員的可見性，盡量不要寫黑匣子，身為開發人員，要管控好你寫的**，所有層的資料對你可見，這樣除錯起來，得心應手，不要把自己堵在核心**外邊。當然如果抽象的層夠簡單、夠強壯，夠安全，你就可以無視這一點，不給自己留這一層的後門，黑匣子也不是不可以。
總結一下，工作還是需要點技巧的，保持優良**風格的的同時，要發揮自己的想象力，展現自己的「才華」，才能獲得成長，走的更遠。
2019-09-27
不僅僅是土豆
這是一則職場寓言 小張和小王是同班同學，他們一起進了一家公司，小張工作勤勤懇懇，風風火火，小王辦事慢條斯理，但是一年後，小王被提公升為主管。小張很不服氣，所以找到領導劉總。劉總，這次人事調整我很不服氣，我和小王是一起進公司的，在學校的時候我比他成績好，在單位，我勤勤懇懇的工作，為什麼公司提拔他而不提...
不僅僅是土豆
小張和小王是同班同學，他們一起進了乙個公司，小張工作勤勤懇懇，風風火火，小王辦事慢條斯理，但是一年後，小王被提公升為主管。小張很是不服氣，如是找到領導劉總。劉總，這次人事調整我很不服氣，我和小王是一起進公司的，在學校的時候我比他成績好，在單位，我勤勤懇懇的工作，為什麼公司提拔他而不提拔我呢，我很困惑...
不僅僅是吐槽
今天和乙個同事聊到現在的工作，沒想到一聊就是二個多小時，大多是對現在的處境的吐槽 同時展望了一下以後的工作領域。乙個人走著想了很多 總感覺要寫下來點什麼，生活不能這麼將就 更多的是一種感慨，也希望給自己定乙個目標，讓自己去改變 因為這不僅僅是吐槽。公司主要是erp產品，因為是垂直行業的產品，加上這幾...