閑談軟體開發
前言
??從計算機入門到入坑，一眨眼8年過去，這些年踩過很多坑，也有很多收穫，簡單記錄下，希望大家能有所收穫，水平有限，一家之言，估且聽之。
計算機 科學（理論）與 技術（工程實踐）
??科班出身的人，出來工作會有一個簡單的想法，自己跟培訓學校速成班出來的人有什麼區別？計算機專業的學習計算機組成原理，彙編語言，編譯原理，數據結構，C語言程序設計，模擬電路，數字電路，離散數學，線性代數，計算機網路，資料庫原理，培訓學校會講JAVA基礎，jdbc,java web(servlet,jsp),spring struts hiberna mybatis,xml,json，項目實戰，Linux基礎操作，mysql基礎操作。很明顯學校與培訓著重點完全不一樣，自從windows普及，大家都習慣直接上代碼copy-past這種快餐式的方式，能幹活，至於什麼原理，思維，哲學，who care.學校的教育只專註課程本身，實際技術課程是成體系，有一個思維認知過程，每門課太過獨立，學生將書本知識轉化成實際工作，或者是積累項目經驗，實際上個人感覺大學學習的基礎很有用也很有意思，紮實的計算機知識，增加項目經驗是很容易的事情，有項目經驗反向學習基礎知識也需要花費很多時間。學習，還有知識的積累，從無捷徑。
五花八門的協議
??軟體開發這一行，各種技術層出不窮，剛工作可能會感覺自己啥都不會，一會學這，一會學那，很容易陷入技術迷城中去，不知道學什麼。簡單介紹下自己思維變化，工作中一定有某些東西會給你很大的啟發,茅舍頓開那種感覺。
有一年去跟移動聯調簡訊介面,調用webservice介面，當時用axis1.4,移動那邊的介面版本更舊，一開始各種不通，對方提供了正確的報文格式給我的參考，上網在賓館中找各種webservice相關的資料，因為沒有全局的認知，wsdl，operation,xml,xsd亂七八糟的，後面代碼怎麼搞都不對，搞了個埠轉發工具tcpdump，看下程序執行的webservice請求到底出什麼問題，看了sop協議組裝內容，有一個簡單地想法就是，實在搞不定，我就自己按報文格式拼個xml，http發送給對方，收到對方的報文，搞個filter自己解析xml。webservice就是http+xml,soap協議就是自己定義了特定格式，wsdl描述發布了那些服務，協議其實很簡單，就是某些人為了達成特定的目標，設計了一大堆規範標準，後面的人都按照這個套路去玩。協議其實很簡單，設計了一種協議，相應地也就會搞出一大堆名詞概念，後面的人如果要用，就得去理解。再之後我再看到什麼其他以協議，心理上也就沒什麼壓力了,如redis協議，dubbo協議等。
不是所有的東西都很重要
??有一年看了effiect java,裡面有一段提到了java某些類寫得不好，stack,vector在集合框架中都重寫了，不推薦使用。原來大神寫的java類庫也有不好的，並不是所有的類，或者方法都很重要，後學java的人，其實可以忘記java中有stack,vector之類的類，個人愛好學習除外。學習我們應該抓住重點,折住主線。
提煉核心思想，化繁為簡
??有段時間看了代碼重構，核心思路是寫出易懂，可擴展，好維護地代碼，至於具體地點，1,2,3,4條都忘得差不多了，學習完提煉轉化為自己對知識的理解，這就是收穫，具體的那幾條不是收穫，因為，每一條都是自己地適應場景，我們開發軟體環境也在變化，這就需要我們自己去判斷，這樣寫代碼，是否符合你自己提煉出來的核心思路。
性能測試，知識點全面，榨乾機器性能
??規範一點的軟體開發團隊應該都做過性能測試，或者引進其他技術方案時可能也會自己壓測，以前測試過來要設定一個壓測目標，比如查詢qps,tp99毫秒數。然後搭建測試環境壓測，應用程序的壓測結果可能慘不妨睹，自己還在想qps不能這麼低吧。分享一下以前經歷，從來沒有對tomcat調優過，默認線程數大概是150左右，壓測怎麼弄都上不去，線程池滿了，對tomcat不熟悉，不了解線程知識，找出問題得看運氣.再有一次用jmeter壓也是怎麼都壓不上去，最後發現jmeter用的是默認的jvm內存設置，太小，並發跑不起來.再有也碰到過操作系統參數設置不合理，伺服器網卡帶寬足夠，交換機帶寬不夠等等各種問題。壓測跟環境，跟壓測目標有很大的關係，從程序員的角度來看，壓測一個是找出程序中的薄弱環節，哪些地方可以優化，再一個就是可以對很多參數設定做對比測試，看下基於特定軟硬體環境，什麼樣的參數組合下有最佳地性能表現，壓測的目標就是榨乾機器性能，最好是cpu利用率，內存利用率，盡量都上去, io盡量降低。
閱讀源碼，站在巨人的肩膀上
??寫代碼跟其他工種實際上也是差不多的，先模仿，多寫，多思考，重複這個過程。閱讀源碼可以快速吸取前人的經驗，源碼閱讀是個細緻的工夫，可以找個市面上比較流行的，大家都在用的開源項目，如dubbo，rocketmq等（京東內部使用對應的是jsf,jmq,原理都差不多，不影響對事務本質的理解），網上有些熱心的程序員已經分享了源碼分析的文章，邊看文章，邊看代碼，邊理解，慢慢地就有感覺了，遇到不會地可以適當地去學習下，如完全不懂netty是沒法看懂遠程通信這一塊的實現細節的，當然也可以跳過去，你只需要知道這個介面是走網路通信用的就可以了，不影響其他部分的代碼閱讀.NB轟轟的項目，不一定代碼寫得好，也可能是架構比較合理，使用比較方便，看什麼學習什麼都要加入自己的理解才是正道。
動手寫代碼吧
??學習源碼後，提供架構設計應該是有幫助的，分散式軟體需要考慮各種情況，失敗設計可能比正常功能更重要，軟體不穩定，甚至數據不正確，直接會否定軟體價值。假設你看過各種源碼，開口就是高可用，談高性能就講緩存，無鎖化，消息通信等等，沒真正去自己去寫過服務註冊，序列化，動態調度等，遠程通信的代碼，可以嘗試自己動手試試，可能會有新的收穫，紙上得來終覺淺，絕知此事要躬行。
持續學習
??看源碼或者是看書，看技術博客，總會發現新的點，保持強烈地學習興趣，了解下總沒壞處，深入研究需要慎重思考，畢竟精力是有限的.說個段子，去年你們騙我搞深度學習，剛才坑今年又騙我去學習區塊鏈。投資與市場環境確實會影響技術發展，技術還是有一段時間的積累，再暴發，找到合適地生長土壤，沒長成可能還需要技術沉澱。
從機器和數學的角度思考程序
??有空也可以想想，如程序是什麼，進程又是什麼，線程，協程之類的，電腦是怎麼跑起來的，C語言編譯器可以用C語言編寫,網路連接是什麼，真實地物理世界連接是什麼，從機器和數學的角度思考程序，而不是我們應用角度。
傳統與互聯網
??總有面試的人說互聯網與傳統軟體的區別，真正在區別是工作文化與工作環境，純粹地從技術上講，個人感覺是一樣的，只是你的程序能滿足業務需求，完成業務功能，能做到高可用，7×24小時不停服，並發能滿足線上用戶訪問請求,有一定地餘量，有一定的防護安全攻擊能力，你就達到了互聯網的技術要求。
總結
??前路漫漫，道阻且長，學無止境.
TAG:我就是程序員 |