面對乙個體系很龐大（相對我而言）的程式的開發，首先應將程式合理的劃分一些層次和模組，
不要至上而下的開發，不然可能呆坐半天而下不了手，應該先把下層的小模組做好，再組裝起來，即使組裝的時候發現了很多需要修改的地方，也不是很要緊，利用resharper和vs的強大的重構和提示功能，完成修改並不算困難。
寫這段話的時候,還是我實習中剛開始參加開發工作的時候(2023年的8-9月份),那時我水的一比,給我乙個很小的功能模組,我都下不了手.
我還記得這段話的背景是:我要開發乙個小功能,讀取文字檔案,裡面有一些座標和衛星影象的引數資訊,我需要讀取出來,然後通過乙個複雜的計算公式,求出某個投影座標,我需要將它封裝成介面,讓其他人呼叫,輸入引數是文字檔案位址,輸出引數是儲存座標資訊的二維陣列.我當時對介面其實都理解的很淺,對整個功能模組的開發,完全沒有思路.
其實現在想來蠻可笑的,但我想也許大部分的初涉開發人員,其實都會有這個問題.
這其實不是編碼能力的問題,而是做事方法,不知道應該怎麼去做一件事,沒有自己的一套方法學的指引,感覺很茫然.
在枯坐半天之後,我只好去請教帶我的前輩,他只是問了我幾個問題(原話不是這樣,我提煉一下意思):讀取檔案你會嗎?會!字串解析會嗎?會!公式計算呢?雖然演算法比較複雜,但是有現成的公式套用,我也可以寫出來. 那不就得了,你先把檔案裡面的內容讀出來再考慮下一步.
ok,現在目標變簡單了,我終於開始寫**了,在一番嘗試之後,我做到了第一步,然後接下來越寫越順,雖然在資料中間流轉環節遇到了很多問題,但我都有思路了,慢慢調式,重構,最終也搞定了這個功能.
在這裡不得不感謝我實習的這家公司,現在回想起來,我們那批實習生,其實根本不能創造多少價值,反倒是公司定期組織人手給我們培訓,而且我們還能拿點工資.我自己都知道,公司在我身上的投入遠遠大於我對公司的貢獻,而且因為種種原因我們能留下來的,其實是少數,公司也知道這點.因為這種行為已經持續7年了,按照每年的經驗總結,大概最終只會留下20-30%,我那年也沒例外.但公司仍然不介意.
這其中有這家公司和我們學校有合作的原因,但其心胸也足以令人欽佩.
這公司老總是武大教授,研究生以上學歷佔一半以上,大部分員工都是武大和地大出身,裡面的氛圍很輕鬆,和我在學校時都沒什麼差別.而且師兄師姐比較多,我那個樓層的boss和帶我的boss都是我的直系師兄,所以我自己也不拘謹,只是最終因為我不想呆在北京,公司由於專案原因,技術比較老舊(.net 2.0 winform)還是選擇離開了這家公司.
不要在乙個函式裡面做太多的事情，這句話以前一直聽到，但真正有體會，還是要等到自己實際遇到，我有乙個函式，解析dal物件傳遞的字段，控制任務物件的開啟、關閉執行緒，修改資料庫。但是當我應理解出錯或是需求更新，需要新增和修改功能的時候，就麻煩了。這個函式被改來改去，同時還要修改任務物件的介面，dal解析的內容，函式本身的引數。如果我當時能把這些功能合理的分割下，修改的時候就只需要修改相應地方就可以了。所謂「原子化」意為不可分割，表示這個功能一執行就全部執行，不執行就全部不執行，如果乙個函式的功能是這樣子的，那麼這個函式被修改的可能性就很小了。但是分層也需要注意合理性，不然層次太多，各種跳轉，也是無謂的加大了**的複雜度。
一看就知道是個全域性私有變數，taskstate則可能是個區域性變數，要注意有效範圍了。類名的存放位置同樣如此，依據dal-model（definition）-class的層次存放類檔案，我們引用或檢視的時候，對類的結構首先就有了乙個大致的了解。
不過我老是不記得這點，寫著寫著就忽略了，不過後來發現resharper的命名提示功能不錯，尤其是它還可以自定義不同內容的命名規範，利用這個小工具，一定程度上可以保證名名規範。
新手的一些廢話
分而治之思想，面對乙個體系很龐大 相對我而言 的程式的開發，首先應將程式合理的劃分一些層次和模組，不要至上而下的開發，不然可能呆坐半天而下不了手，應該先把下層的小模組做好，再組裝起來，即使組裝的時候發現了很多需要修改的地方，也不是很要緊，利用resharper和vs的強大的重構和提示功能，完成修改並...
雜談 一些廢話
2020 8 18 這好像是我第一篇部落格，感覺想寫就寫了，之前因為覺得markdown，latex 有點麻煩 在我有限的腦容量裡是無法佔據一席之地的，因為太虧了，就連這個 latex 都要用一些奇奇怪怪的符號 導致我註冊好幾個月之後沒有發一篇部落格，甚至還忘了密碼orz，我的問題我的問題qwq 今...
關於學習設計模式的一些廢話
物件導向的軟體設計中有一些基本原則可以遵守，包括單一職責 開閉原則等，我們運用這些原則，去設計我們的軟體，最後達到的效果是高內聚 低耦合，也就是說各個模組內部聯絡緊密，但是模組之間的聯絡不緊密，只是通過一些公共的api來進行通訊。我們追求高內聚 低耦合的目的是為了使得程式更加易於維護 易於對應客戶的...