第一篇：老程序員10年技術生涯的思考 從C++到Java

老程序員10年技術生涯的思考 從C++到Java 2011-04-20 08:17 蔡暉 蔡暉的博客 我要評論(20)字號：T | T

不知不覺,做程序工作已經10年了,從最初學習C++到Java,從困惑到清晰,感覺真的有不少東西可寫,不過總覺得不成體系，大概看了太多八股文章的緣故，被憋得實在難受。所以不管了，想到什么寫什么吧。AD：

1、從C++到Java

C++和Java誰快?從算法上講我認為毫無疑問是匯編〉C++〉Java，不要迷信某些個別評測，單純的回圈測試什么的，比如JNode的官方網站上有Java寫的JVM的性能和SUN的JVM 進行性能比較的結果，JNode中用Java寫的JVM竟然能比SUN公司用C++寫的JVM還快!編譯器完全可以作針對性優化影響測試結果，毫無意義的東西。而且，評測結果不會具備多少實際意義，真正的應用系統的效率是80%取決于整體的設計架構，而非你使用哪種語言。所以討論匯編、C++、Java誰更快這個問題的人恐怕更多是為了自己的面子考慮，雖然Java當前如日中天，但其總是針對C++的批判性態度卻再明顯不過，所以Bruce才會有“C++不垃圾，只是Java很傲慢”之說。

C++和Java根本的區別是什么?我認為毫無疑問是內存分配。編程思想和設計模式是活的東西，和語言沒有直接關系。Java沒有指針，C++寫程序也可以只用引用。JVM是Java在

內存管理上真正有別于C++的地方。JVM的好處是顯而易見的，跨平臺、更智能的內存管理，但能解決所有問題嗎，答案是否定的。

Java沒有內存泄露嗎?當然不是，我認為java的內存泄露往往比C++更加難以排查，因為JVM的緣故，程序員沒法直接對內存進行操控，隱患往往藏的更深。我曾經花了大量時間研究JVM的內存機制，雖然也有了不少心得，但直到現在仍然處于迷惑期。循環引用，緩存機制不合理，Spring等常態Bean的屬性重復加載都是可能吃內存的元兇。

對于一個單一的，低用戶低并發的系統，使用Java是很舒服的，程序員不用去考慮太多事情，照著業務邏輯做設計編代碼就行，不用管內存分配，不用管并發和互斥(其實還是要管的)，就算萬一有內存泄露的隱患，大不了每天重啟JVM一下就能解決了。但對于一個可能在多個應用環境中部署的軟件產品而言，內存泄露這種問題卻絕不能放過。我曾經遇到過在一個環境中運行非常良好，但在另一個環境中卻天天出問題的情況，即使每天重啟JVM也無濟于事。當時懷疑過很多方面，網絡、數據庫、容器等等。那時還不是很有概念，現在想起來還是后來好好看程序，優化了不少代碼，解決了幾個內存泄露，這樣才最終解決了不穩定的問題。舉例來講，在應用環境A中，服務器性能較好，JVM有2G內存，某個應用存在內存泄露的隱患，每次大約造成2M的內存消耗，這樣1000次左右就沒有內存可用了，就會造成JVM性能大幅降低。但在應用環境B中，服務器就沒那么好的性能了，JVM僅有256M，那么100多次操作就足以導致問題出現。而且，每個應用環境的應用使用率是不一樣的，在A中如果每天僅出現10次隱患應用操作，2-3個月都不會暴露問題，而且即使使用內存分析工具，開始階段也很難查出有無問題，但在B中，如果每天有100次隱患應用操作，只需一天問題就出現了。但實際應用過程中，應用的使用率往往很難精確統計的到，也無法預判，這也是造成問題排查困難的關鍵因素之一。應用環境的不確定性不單體現在地域上，也體現在時間上，不同時間的相同應用環境也不盡相同。挑選一個應用環境，常態性監測JVM的內存情況是避免這類問題發生的好辦法。

結論就是，對于中高端的產品化，多用戶，高并發應用，Java和C++一樣，不考慮內存是不可能的，畢竟語言最終操縱的還是計算機。

那Java的優勢在哪里?我認為其在中低端應用上的門檻更低。對大多數小型信息管理類系統而言，并不需要很嚴謹并且考慮周到的設計和編碼，學習java可以讓一個新手很快

上路，而C++卻沒有這種優勢，動不動就越界是新手常犯的錯誤。在一個通常的軟件團隊里面，水平一定會有高低，而且也不是每個人都能通過學習進入深層次，這是C++難以解決的問題，Java在由于規范性方面的優勢更加適合新手使用。

C++就像手動檔汽車，Java更像自動檔，盡管越來越多人愿意開自動檔，可是要想真正跑得快，賽車還得手動擋的。

問題出現總會讓人頭疼,追根溯源常常也會非常艱苦和漫長,但只要還有辦法,就不能放棄,規避問題可以解決陣痛,但永遠無法治根。

2、關于云計算想到的

毫無疑問云計算的概念被擴大化了，云服務、云存貯，SAAS、IAAS、PAAS，理論和概念早已滿天飛。但當我仔細讀來，卻發現大多還是新瓶裝舊酒。雖然說還是有不少實質性內容，但與真正的分布式計算概念還是想去甚遠。在網絡越來越發達的時代背景下，存貯、軟件、外設甚至內存都網絡化了，唯一缺少的就是CPU，依靠網絡使大量CPU協同工作真的是個很誘人的想法，但也是困難而遙遠的事情。也有人認為Cloud Computing是個過度炒作的東西，我覺得有一定道理，如果要我選擇，我也會希望把自己的東西放到自己的電腦上，我會更希望在任何地方使用便攜設備隨時操縱我的電腦，卻絕對不是放到一個看不見摸不到的“云端”上頭，天天被“云端”盤剝和控制。因此，如果云端僅僅是服務或存貯的集中式管理，它是不值得如此進行炒作的。

其實我覺得我不是一個重組概念進行炒作的反對者，炒作對于技術和社會進步是有一定作用的，但水可載舟、亦可覆舟，將一些本無關系的東西牽強附會的聯系在一起進行炒作，只會攪亂理論和學術體系，而理論體系的混亂一定會導致交流上的障礙-----雖然交流變得更多(必然變得更多)更方便了，可是交流的障礙卻大幅度增加了，同樣的一個名詞可以被一百個人給出一百個解釋，本來一句話可以說清楚的事情，現在變成了幾十句才能說明白。

藥廠可以把10幾塊錢的藥重新包裝賣200-300塊，利潤當然是驚人的，可是賺到了錢的老板們卻天天打算著轉移資產到國外，認為國內沒有可持續的發展。這樣的人到底是高素質還是低素質呢? 我上大學的時候曾經在醫院實習，見過一個食物中毒的病人家屬連夜趕了幾十里山路，把一堆借來的硬幣交給醫院做透析;后來工作了，搞圖書館的項目也知道很多地方的人連100塊錢的借書證押金都捉襟見肘。那些天天生活在優越環境下的概念重組專家們會為這些人群考慮多少呢?“云端”的概念炒作顯現了他們的壟斷思想，現在中國的貧富差距基本還是在財產方面，信息方面基本還是對等的，這也是一個農村的孩子經過十幾年苦干可以成為大企業家的前提所在。可是“云端”一來，你的一舉一動都在我掌控和監視之下，沒錯，你是方便了，也少花錢了，可是卻失去了信息方面的平等地位，于是，屁民將永遠是屁民，永遠沒有咸魚翻身的機會。

3、關于信息爆炸

10年來我也做了很多技術方面的工作了，最初幾年看到一項新技術、新概念，腎上腺激素濃度就會大幅度增加，要是不用一下晚上恐怕覺都睡不著。可是后來慢慢地就變得理性多了，技術的選擇一定要根據需求來，絕不能為用技術而用技術。很多的新技術、新概念，看幾眼就差不多知道來源，也知道優點和缺點了。以前總以為環境得適應程序，后來明白了程序得適應環境。

大型的應用系統，越簡單越好，如果做不到簡單，寧可拆分為多個系統單獨設計。否則，當我面對一大堆連自己都難以看懂的概念和代碼，真會有抓狂的感覺。

一些社區雖然是不錯的技術社區，但是依然缺乏體系組織和管理。論壇、知識庫，Q&A，這些東西的模式差不多，雖然方便了信息交流，但缺乏信息的組織和管理。比如我希望做一個信息系統，那應該選擇什么樣的技術?這個問題目前只能靠自己去摸索，慢慢體會，找到真正適合自己的技術方案。Wiki可能是更好的平臺，但普及度不夠。

其實每一個Questioner或者Answerer都在極力尋求相互之間的共同語言，共同語言和語義的理論體系形成之后，交流才能順暢。翻翻帖子，不乏問東答西的案例。一個交流平臺如果能形成一套語言和思維方式，那就是非常成功的了。而這也使得技術選型的模型成為可能，當你想采用一套新技術時，Google一下，各說各話，對的有，錯的也有，搜索引擎為何判斷不出已定論的東西誰對誰錯呢，就是源于語義的復雜性。信息的膨脹速度遠沒有我們想象中那樣快，其中相當一部分是語言語義產生的泡沫，擠掉這些泡沫呢?信息真的有統計數據顯示的那么“海量”嗎? 統計數據經常是面子工程強有力的支撐者，可扔掉這些浮華，細細究一下統計數據是怎么做出來的?常常就會讓人哭笑不得，而且大多是7分真，3分假，或偷換概念，總之目的就是把一棵小草說成一座森林。信息是有欺騙性的，商業運作會大量運用這種特性，換來的除了腎上腺素之外還有人和人之間不信任的感覺。信息爆炸的時代，交流的作用變成空前重要，但在交流越來越方便的同時，效率也越來越低了。也許幾十年后，人類會不堪信息的重負，那時信息規范化和有序化才會真正站上歷史的舞臺。

第二篇：程序員-從C到Java,10年技術生涯的幾點思考(精)

不知不覺,做程序工作已經10年了,從最初學習C++到Java,從困惑到清晰,感覺真的有不少東西可寫,不過總覺得不成體系，大概看了太多八股文章的緣故，被憋得實在難受。所以不管了，想到什么寫什么吧。

1、從C++到Java

C++和Java誰快？從算法上講我認為毫無疑問是匯編〉C++〉Java，不要迷信某些個別評測，單純的回圈測試什么的，比如JNode的官方網站上有Java寫的JVM的性能和SUN的JVM

進行性能比較的結果，JNode中用Java寫的JVM竟然能比SUN公司用C++寫的JVM還快！編譯器完全可以作針對性優化影響測試結果，毫無意義的東西。而且，評測結果不會具備多少實際意義，真正的應用系統的效率是80%取決于整體的設計架構，而非你使用哪種語言。所以討論匯編、C++、Java誰更快這個問題的人恐怕更多是為了自己的面子考慮，雖然Java當前如日中天，但其總是針對C++的批判性態度卻再明顯不過，所以Bruce才會有“C++不垃圾，只是Java很傲慢”之說。

C++和Java根本的區別是什么？我認為毫無疑問是內存分配。編程思想和設計模式是活的東西，和語言沒有直接關系。Java沒有指針，C++寫程序也可以只用引用。JVM是Java在 內存管理上真正有別于C++的地方。JVM的好處是顯而易見的，跨平臺、更智能的內存管理，但能解決所有問題嗎，答案是否定的。

Java沒有內存泄露嗎?當然不是，我認為java的內存泄露往往比C++更加難以排查，因為JVM的緣故，程序員沒法直接對內存進行操控，隱患往往藏的更深。我曾經花了大量時間研究JVM的內存機制，雖然也有了不少心得，但直到現在仍然處于迷惑期。循環引用，緩存機制不合理，Spring等常態Bean的屬性重復加載都是可能吃內存的元兇。

對于一個單一的，低用戶低并發的系統，使用Java是很舒服的，程序員不用去考慮太多事情，照著業務邏輯做設計編代碼就行，不用管內存分配，不用管并發和互斥(其實還是要管的，就算萬一有內存泄露的隱患，大不了每天重啟JVM一下就能解決了。但對于一個可能在多個應用環境中部署的軟件產品而言，內存泄露這種問題卻絕不能放過。我曾經遇到過在一個環境中運行非常良好，但在另一個環境中卻天天出問題的情況，即使每天重啟JVM也無濟于事。當時懷疑過很多方面，網絡、數據庫、容器等等。那時還不是很有概念，現在想起來還是后來好好看程序，優化了不少代碼，解決了幾個內存泄露，這樣才最終解決了不穩定的問題。舉例來講，在應用環境A中，服務

器性能較好，JVM有2G內存，某個應用存在內存泄露的隱患，每次大約造成2M的內存消耗，這樣1000次左右就沒

有內存可用了，就會造成JVM性能大幅降低。但在應用環境B中，服務器就沒那么好的性能了，JVM僅有256M，那么100多次操作就足以導致問題出現。而且，每個應用環境的應用使用率是不一樣的，在A中如果每天僅出現10次隱患應用操作，2-3個月都不會暴露問題，而且即使使用內存分析工具，開始階段也很難查出有無問題，但在B中，如果每天有100次隱患應用操作，只需一天問題就出現了。但實際應用過程中，應用的使用率往往很難精確統計的到，也無法預判，這也是造成問題排查困難的關鍵因素之一。應用環境的不確定性不單體現在地域上，也體現在時間上，不同時間的相同應用環境也不盡相同。挑選一個應用環境，常態性監測JVM的內存情況是避免這類問題發生的好辦法。

結論就是，對于中高端的產品化，多用戶，高并發應用，Java和C++一樣，不考慮內存是不可能的，畢竟語言最終操縱的還是計算機。

那Java的優勢在哪里？我認為其在中低端應用上的門檻更低。對大多數小型信息管理類系統而言，并不需要很嚴謹并且考慮周到的設計和編碼，學習java可以讓一個新手很快

上路，而C++卻沒有這種優勢，動不動就越界是新手常犯的錯誤。在一個通常的軟件團隊里面，水平一定會有高低，而且也不是每個人都能通過學習進入深層次，這是C++難以解決的問題，Java在由于規范性方面的優勢更加適合新手使用。

C++就像手動檔汽車，Java更像自動檔，盡管越來越多人愿意開自動檔，可是要想真正跑得快，賽車還得手動擋的。

問題出現總會讓人頭疼,追根溯源常常也會非常艱苦和漫長,但只要還有辦法,就不能放棄,規避問題可以解決陣痛,但永遠無法治根。

2、關于云計算想到的 毫無疑問云計算的概念被擴大化了，云服務、云存貯，SAAS、IAAS、PAAS，理論和概念早已滿天飛。但當我仔細讀來，卻發現大多還是新瓶裝舊酒。雖然說還是有不少實質性內容，但與真正的分布式計算概念還是想去甚遠。在網絡越來越發達的時代背景下，存貯、軟件、外設甚至內存都網絡化了，唯一缺少的就是CPU，依靠網絡使大量CPU協同工作真的是個很誘人的想法，但也是困難而遙遠的事情。也有人認為Cloud Computing是個過度炒作的東西，我覺得有一定道理，如果要我選擇，我也會希望把自己的東西放到自己的電腦上，我會更希望

在任何地方使用便攜設備隨時操縱我的電腦，卻絕對不是放到一個看不見摸不到的“云端”上頭，天天被“云端”盤剝和控制。因此，如果云端僅僅是服務或存貯的集中式管理，它是不值得如此進行炒作的。

其實

我覺得我不是一個重組概念進行炒作的反對者，炒作對于技術和社會進步是有一定作用的，但水可載舟、亦可覆舟，將一些本無關系的東西牽強附會的聯系在一起進行炒作，只會攪亂理論和學術體系，而理論體系的混亂一定會導致交流上的障礙-----雖然交流變得更多（必然變得更多）更方便了，可是交流的障礙卻大幅度增加了，同樣的一個名詞可以被一百個人給出一百個解釋，本來一句話可以說清楚的事情，現在變成了幾十句才能說明白。

藥廠可以把10幾塊錢的藥重新包裝賣200-300塊，利潤當然是驚人的，可是賺到了錢的老板們卻天天打算著轉移資產到國外，認為國內沒有可持續的發展。這樣的人到底是高素質還是低素質呢？

我上大學的時候曾經在醫院實習，見過一個食物中毒的病人家屬連夜趕了幾十里山路，把一堆借來的硬幣交給醫院做透析；后來工作了，搞圖書館的項目也知道很多地方的人連100塊錢的借書證押金都捉襟見肘。那些天天生活在優越環境下的概念重組專家們會為這些人群考慮多少呢？“云端”的概念炒作顯現了他們的壟斷思想，現在中國的貧富差距基本還是在財產方面，信息方面基本還是對等的，這也是一個農村的孩子經過十幾年苦干可以成為大企業家的前提所在。可是“云端”一來，你的一舉一動都在我掌控和監視之下，沒錯，你是方便了，也少花錢了，可是卻失去了信息方面的平等地位，于是，屁民將永遠是屁民，永遠沒有咸魚翻身的機會。

3、關于信息爆炸

10年來我也做了很多技術方面的工作了，最初幾年看到一項新技術、新概念，腎上腺激素濃度就會大幅度增加，要是不用一下晚上恐怕覺都睡不著。可是后來慢慢地就變得理性多了，技術的選擇一定要根據需求來，絕不能為用技術而用技術。很多的新技術、新概念，看幾眼就差不多知道來源，也知道優點和缺點了。以前總以為環境得適應程序，后來明白了程序得適應環境。

大型的應用系統，越簡單越好，如果做不到簡單，寧可拆分為多個系統單獨設計。否則，當我面對一大堆連自己都難以看懂的概念和代碼，真會有抓狂的感覺。

CSDN是不錯的技術社區了，但是依然缺乏體系組織和管理。論壇、知識庫，Q&A，這些東西的模式差不多，雖然方便了信息交流，但缺乏信息的組織和管

理。比如我希望做一個信息系統，那應該選擇什么樣的技術？這個問題目前只能靠自己去摸索，慢慢體會，找到真正適合自己的技術方案。Wiki可能是更好的平臺，但普及度不夠。

其實每一個Questioner或者Answerer都在極力尋求相互之間的共同

語言，共同語言和語義的理論體系形成之后，交流才能順暢。翻翻CSDN的帖子，不乏問東答西的案例。一個交流平臺如果能形成一套語言和思維方式，那就是非常成功的了。而這也使得技術選型的模型成為可能，當你想采用一套新技術時，Google一下，各說各話，對的有，錯的也有，搜索引擎為何判斷不出已定論的東西誰對誰錯呢，就是源于語義的復雜性。信息的膨脹速度遠沒有我們想象中那樣快，其中相當一部分是語言語義產生的泡沫，擠掉這些泡沫呢？信息真的有統計數據顯示的那么“海量”嗎？

統計數據經常是面子工程強有力的支撐者，可扔掉這些浮華，細細究一下統計數據是怎么做出來的？常常就會讓人哭笑不得，而且大多是7分真，3分假，或偷換概念，總之目的就是把一棵小草說成一座森林。信息是有欺騙性的，商業運作會大量運用這種特性，換來的除了腎上腺素之外還有人和人之間不信任的感覺。

信息爆炸的時代，交流的作用變成空前重要，但在交流越來越方便的同時，效率也越來越低了。也許幾十年后，人類會不堪信息的重負，那時信息規范化和有序化才會真正站上歷史的舞臺。

第三篇：Java從入門到精通讀書筆記—c++程序員學java

Java從入門到精通讀書筆記—c++程序員學java

第一章：

2分鐘看完，老生常談，即使沒怎么用過java也知道這些。

第二章：

1.instanceof應該是c++中沒有的，c++使用RTTI解決這個問題的，很難用。

2.super這種引用父類的方法也是比較簡單的，C++中是用父類名::父類方法()解決的，有點難看。

3.自動類型轉換和C++一樣，精度變高的隨便轉，精度變低的會丟失。

4.強制類型轉換只有(type)這一種，不像c++有static_cast、dynamic_cast、reinterpret_cast、和const_cast。

5.運算符什么的和c++幾乎一模一樣。

半小時看完。

第三章：

1.break可以跳出語句塊，c++中沒有語句塊。語句塊的定義就是在一段語句前加上花括號和冒號；

其他基本上和c++一樣，5分鐘看完。

第四章：

1.java數組越界會在運行時拋異常，c++不會，聲明數組的方法也有些不一致。

java 聲明數組的所有辦法

int[] a = new int[4];

int a[] = new int[4];

int[] a = {1, 15, 26};

int a[] = {1, 15, 26};

2.java的數組是一個對象，自帶length屬性，使用簡單。c++的數組不自帶方法和屬性，要知道數組長度只能sizeof(arrayObject)/sizeof(int)。當然如果使用STL中的vector之類的也和java一樣簡單。

3.java的所謂數組賦值（或者叫數組拷貝）其實就是c++中的兩個數組指針的賦值，java沒有指針，所以作者費了一大堆口水。好在java有垃圾回收，要不然一個指針的內存就算泄露了。至于真正的數組內容賦值，是使用System.arraycopy(ir, srcPos, ir, destPos, length);而C++一般使用memcpy等函數。若使用STL中的vector，那么就看vector的拷貝構造函數怎么寫的，應該是vector的對象賦值過去而不是指針指過去。

4.重溫了冒泡排序（時間復雜度O(n2)），和快速排序（最壞情況的時間復雜度為O(n2)，最好情況時間復雜度為O(nlog2n)）。

5.For-Each語法被引入java了，在很多地方用起來真是簡單。Python和c#早就支持了，c++中雖然STL的algorithm包中引入了for_each，但是由于需要使用函數指針還是略顯繁瑣。

這章挺多，看了一個多小時啊！

第五章：類和對象

1.Java中方法的重載和c++的一樣，都是通過參數的不同來區別。但是c++中可以設置默認參數，而java不可以。

2.java中的對象大部分只能new出來，或者clone出來，或者反射出來，而不能直接在棧上定義出來。而c++的對象在棧上和堆上創建的都很多。

3.基本類型的參數傳遞，java和c++都是傳值。對象的參數傳遞，java是傳引用，c++是拷貝，也就是傳值。其實c++中大部分時候也是傳引用或者傳指針，但java沒有指針，也沒有選擇耗時耗空間的拷貝，只能傳引用了。

這章對于c++程序員來說太簡單，幾分鐘過一遍就可以了。

第六章：繼承

1.方法被覆寫后，如果要調用父類的方法，c++必須用父類名：：方法名，而java用super.方法名即可。

2.多態和動態綁定，java和c++幾乎一樣，都很簡單。

3.final關鍵字：java中的final關鍵字可以將一個類限制為無法繼承的，同樣的還有C#中的sealed關鍵字。而c++是沒有這個玩意的。

4.java的抽象類和c++幾乎一樣。

5.java是獨根語言，引入了Object類，它的clone方法就好像c++中的拷貝構造函數，它的equals方法是用來比較內容的，而toString方法是將對象作為字符串輸出的。

這章對于c++程序員來說同樣簡單，幾分鐘過一遍就可以了。

第七章：接口

1.java中有接口。C++沒有，唯一類似的是含有純虛函數的虛類（沒有純虛基類這個說法）。但是COM、CORBA等中間件中都有IDL語言（接口定義語言），使用這些中間件的c++程序員也沒有少寫接口。

2.接口實現的一些規定：

1）如果實現接口的不是抽象類，則必須實現其接口的所有方法才能被實例化；

2）接口中所有的方法默認為public；

3.接口可以用來實現多態；

4.java的內部類和c++差不多，都沒人關心，最多懶得想名字的時候用用那個匿名內部類（例如什么UI的響應函數）。

5.java的對象克隆，吹了一堆就是個c++中的拷貝構造函數。所謂什么“淺克隆、深克隆”問題，就是c++中拷貝構造是遇上類中定義了指針的問題。C++程序員一望即知。

接口是為了維護單繼承機制弄出來的，花半小時看看還是值得的。

第八章：面向對象編程

C++程序員不用看。

第九章：異常處理

1.java的異常處理中有finally語句塊，而c++中沒有，所以程序員要自己想辦法來處理異常發生后諸如“資源釋放”之類的問題；

第十章：線程

1.java語言自帶線程機制，c++目前還是不帶線程機制的。雖然boost::thread庫也被眾多c++程序員廣泛使用。但是windows下用得最多的還是windows SDK自帶的線程函數；而linux下用得最多的還是pthread。另外還有一些號稱同時支持多個平臺的多線程庫。

2.java多線程有兩種方法實現，第一是派生Thread類，第二種是實現Runnable接口。

3.java線程分為4種狀態：new、runnable、non runnable和done，這和其他線程庫大同小異；

4.run、start、stop、sleep、suspend、resume、yield、wait、notify和notifyall等方法的含義也和其他線程庫一致。但suspend、resume和stop等方法是不建議使用的，因為可能會導致死鎖。

5.java可使用join方法來等待線程結束，而在某些線程庫中join方法經常是不可用的。

6.java的互斥使用synchonized關鍵字實現，它很類似于boost.thread中的lock(mutex)，只不過它是對線程對象隱含的鎖加鎖。其實這很不利于新手理解。另外還介紹了synchonized的一些亂七八糟的用法，相信對于新手這只有反作用。

這一章對于線程，介紹得比較淺顯，實現簡單的多線程應該沒問題，但是稍微復雜一點的也許就需要其他的開發包了。Java線程連個Mutex類都沒有，這是最讓我吃驚的，僅僅使用synchonized來實現同步、互斥、信號量該多麻煩啊，也許是我還沒弄懂java多線程吧。

第十一章：圖形編程

1.IDE的年代，GUI還是畫出來吧。Java中也就Layout類需要看看，其他大部分Layout類也是湊數的，根本不會有人用。

第十二章：事件處理

隨便看看了解即可，新手可以試著寫寫代碼，老手直接IDE中添加事件即可。

第十三章：Swing用戶界面設計

同第十一章，隨便看看即可。界面一般有專人搞，普通程序員能看懂就行了。

總結：《java從入門到精通》這本書整體質量尚可，c++熟手大概一到兩天可以看完，掌握程度在80%左右。看完后能夠有一些基本概念，可以寫一些基本程序。看完后離入門還早，更談不上精通了。

說說我看完后的兩個迷惑之處吧，第一是從來沒有提到java中的對象、常量、代碼所在的堆、棧等內存分布情況，對于c++程序員來說是很難適應的，可能是篇幅的原因吧；第二沒有介紹垃圾回收機制，這可能是c++程序員更感興趣的吧。

第四篇：從程序員到技術總監,分享10年開發經驗

在中國有很多人都認為IT行為是吃青春飯的，如果過了30歲就很難有機會再發展下去!其實現實并不是這樣子的，在下從事.NET及JAVA方面的開發的也有10年的時間了，在這里在下想憑借自己的親身經歷，與大家一起探討一下。

明確入行的目的

很多人干IT這一行都沖著“收入高”這一點的，因為只要學會一點HTML, DIV+CSS，要做一個頁面開發人員并不是一件難事，而且做一個頁面開發人員更容易找到工作，收入比普通的工作還要高一些，所以成為了很多高校畢業生的選擇。如果您只是抱著這樣一個心態來入行的話，那閣下可真的要小心了。因為干IT這一行競爭本來就比較激烈，特別是頁面設計這方面，能夠開發的人很多，所以為了節省成本，大部分公司都會在需要的時候才招聘這類人員;在沒有訂單的時候，一些小公司還可能找各類的借口或者以降薪的手段去開除這類員工。而在招聘信息上常常會看到“招聘頁面設計師，條件：30歲以下??歡迎應屆畢業生前來應聘”這樣一條，因為這一類工員對技術上的要求并不高，找應屆生可以節約成本。所以在下覺得“IT行業是吃青春飯的”這句話只是對著以上這類人所說的，如果閣下缺乏“進取之心”，而只抱著“收入高，容易找工作”這樣的態度而入行，那“IT行業是吃青春飯”將會應驗了。

選擇合適的工具

JAVA、C#、PHP、C++、VB??10多種熱門的開發語言，哪一種最有發展潛力呢?其實開發語言只不過是一個工具，“與其分散進攻，不如全力一擊”，無論是哪一種開發語言，只要您全力地去學習，到有了一定的熟悉程度的時候，要學習另一種的語言也是輕而易舉的事情。開發語言主要分為三大類：

1.網絡開發

現在網絡已經成為世界通訊的一座橋梁，好像Javascript、PHP、Ruby這幾類開發語言大部分是用作網絡開發方面。

2.企業軟件開發

JAVA、C#、VB這幾類開發語言都實現了面向對象開發的目標，更多時候用于企業系統的開發。

3.系統軟件

C語言、C++、Objective-C這些軟件更多是用在系統軟件開發，嵌入式開發的方面。

當然，這分類不是絕對，像JAVA、C#、VB很多時候也用于動態網站的開發。在很開發項目都會使用集成開發的方式，同一個項目里面使用多種開發語言，各展所長，同步開發。但所以在剛入門的時候，建議您先為自己選擇一種合適的開發工具，“專注地投入學習，全力一擊”。

明確發展方向

當您對某種開發語言已經有了一定的了解，開始覺得自己如同“行尸走肉”，成為一個開發工具的時候，那您就應該要明確一下自己的發展方向了。

平常在公司，您可以看到做UI層的開發人員大多數都有20多歲，他們充滿干勁，而且沒有家庭負擔，在兩年前ASP.NET MVC、Silverlight等剛出現的時候，他們可以在晚上回家的時候買幾本書或者直接上網看看，研究三五個星期以后，對需要用到的技術就已經有一定的了解了。而年過30的人多數是已經成家了，他們每天9：00點上班唯一的希望就是快些到6：00點，能回家吃飯。吃完飯只想陪孩子玩一下，看看孩子的功課，對新增的技術缺乏了學習的欲望。所以很多接近30歲的程序員都有著一種逼迫感(包括30歲時候的我自己)，再過幾年應該怎么辦?這時候，您就更應該明確一下目標，努力向自己的發展方向前進了。歸納一下，可從下面幾項里選擇適合自己的一條道路：

1.從技術向業務過渡

在國外，很多發達國家都很重視人才，一個高級的程序員與一個Project Manager收入相差一般不超過15%。但中國是世界上人口最多的國家，國內人才眾多，所以人才濫用的情況經常可以看到。一個小公司的開發部里面經常會見到新面孔，但PM卻不會常換。因為做老板的對技術是一竅不通，依他們看來只到拉住PM的心，那技術方面方面就能搞得定，至于技術部要換人，他們根本不需要費力氣去管。所以從一個技術員過渡到一個PM是向前發展的一個選擇，但開發人員也需要知道，要成為一個PM不單單是使用技術，而更重要的是對管理方面的認識。一個PM主要的工作是組織團隊，控制成本，管理業務，控制項目進度，與客戶進行溝通，協調工作，定期進行工作報告等。所以要成為一個成功的PM更要重視組織能力，PM必須能提高團隊的積極性，發揮團隊所長，在有限的開發資源前提下為公司得到最大程度上的利潤。成為一個PM后，通常不需要直接接觸技術開發，而著重管理的是業務發展，但PM對技術也需要有一定的了解(在下曾經為PM對技術了解的必要性寫過一篇文章，得到很多支持但也惹來不少的爭議)。在這里我還是要強調自己的觀點：要成為一個成功的PM最重視的是管理能力，但對技術也應該有足夠的了解，因為這是與團隊成員溝通的橋梁，只有這樣才能與整個團隊的成員有著緊密的結合，讓團隊成員感覺到他們自己存在的意義，從而調動團隊的積極性，而不是漠視技術人員的存在。技術并非成為一個成功PM的充分條件但卻是必要條件!

2.從程序員向技術管理發展

其實一個Team Leader的職責與Project Manager相像，但Team Leader更著重于技術開發方面，通常一個大型項目都會有一兩個開發團隊由Team Leader帶領，負責開發核心部分，而其它部分分派給不同開發小組或者分派給外包公司。在網上常看到幾句話，貼切地形容了PM與TL的區別：“技術人員樂于被領導;但他們不喜歡被管理，不喜歡像牛一樣被驅趕或指揮。管理者強迫人們服從他們的命令，而領導者則會帶領他們一起工作。管理是客觀的，沒有個人感情因素，它假定被管理者沒有思想和感受，被告知要做什么和該如何做。領導是引領、引導，它激勵人們達成目標。領導力是帶有強烈個人感情色彩的，它不是你能命令的，也不是你能測量評估和測試的。”

無論是PM與TL，對業務與技術都要有深入的了解，只是PM更側重于業務的管理，盈利的多少，風險的大小等等，而TL則側重于項目的成本，開發的難度，軟件的架構等技術方面的問題。在某些人眼中，技術與管理就像魚與熊掌，不可兼得，但依在下看來，兩者卻是秤不離砣，密不可分。只要及時提升自己對技術與管理的認識，不斷地向深一層發展，要從程序員提升到技術管理人員只是時間的問題。打個比方，一個普通的.NET程序員，開始可能限制于ASP.NET的頁面開發，但一旦他有了發展之心，他自然會對ASP.NET MVC、Silverlight、WinForm、WPF這些UI的開發手法感到興趣，學習不需要多少時間，他可能就會認識這些UI開發只不過是一些工具，其實在開發原理上沒什么區別。接著他就會向深一層的通訊模式進行了解，認識TCP/IP、Web Service、WCF、Remoting這些常用到的通訊方式，這時候他可能已經感覺到自己對開發技術有了進一步的了解。進而向工作流、設計模式、面向對象設計、領域驅動設計、面向服務開發等高層次進發，最后成為技術的領導者。上面只是一個比喻，但要注意的是，在學習的時期必須注意的是與同事之間溝通，很多的開發人員喜歡獨來獨往，開發的項目總想一個人搞定，不受外界的干擾。但要明白，就算你有天大的本事，一項大型的項目也不可能由你一個人全扛著。所以團隊的合作性與同事間的溝通是必要的，這也是成功一個TL的必要條件。

3.單方面向技術發展

能成功進行技術開發的尖端人才，這是在下最向往的工作，卻也沒本事登上這個位置。很多從事開發的人都會認為，業務總會帶著“金錢的味道”，老板從來不管開發是否合符開發原則，是否經過必要測試，他們只會在客戶面前無盡地吹噓，項目到期能成功交貨，只要不出什么大問題那這個項目就算成功了。其實我們也要明白：開發項目最終目標是為了賺錢，在開發過程中對項目成本的限制和效率的控制這也是必須，所以這才需要管理人員對項目進行管理。但開發人員也很想避開這“金錢的塵囂”，全心投入到技術的世界當中。所以對技術有著濃厚興趣的人，往往會深入地研究某一項技術，成為技術上的精英。但在這里說一句令人心淡的話：中國已經屬于是世界上第二大經濟體同盟國，但國民生產總值主要來源于第三方加工產業方面。中國可以說是人才濟濟，但卻在高新產業上卻比發達國家落后。這幾年的確看到我們國家在高新科技上有著質的飛躍，但跟歐美發達國家還有著一段距離。所以想在中國成為尖端技術的人才，無可否定比在國外要難。依在下看來，要想成為尖端的開發者，必須對C、C++、匯編語言、嵌入式開發、Windows API、Linux API這些底層技術有著深入的了解。要知道解JAVA、.NET??等這些之所以稱為高級開發語言，并不是指它們比C、C++、匯編語言更高級，而是指它們封裝了C、C++等等的功能，更適合用于企業軟件的開發，使開發變得簡單。但如果要開發一些底層的軟件，大型的系統的時候，就必須用到C、C++、匯編等開發語言，這是成功尖端人才的一個條件。

確定未來的目標

人是從歷練中成長的，古人云：三十而立，形容的不是一個人的社會地位，經濟來源，而是形容一個人對未來的目標，對人生的意向。要成為一個成功人，就應該早日為自己定下長期的發展目標，作為一個開發者也當如此。隨著人的性格，取向各有不同，大家為自己所選擇的路也有不同：

1.自立門戶，勇敢創業

快30歲了，很多人會認為要想真正賺得了錢，就應該自立門戶，為自己創業建立一個基礎。像北京、上海、廣州這些一級城市，要買房子，一手樓基本要在2萬~4萬元/平方米左右，而在一家普通的IT公司當上一個項目經理，基本收入一般都在1.5萬~3萬之間(除非在大型的跨國企業內工作，那另當別論)，要買一間100平方米左右的房子，就算不吃不喝也幾乎要10年的年薪，所以選擇自主創業，是很多IT開發人員的一個未來目標，想要達到這個目標，就應該更多地把業務作為重點。不可否認的一件事，在中國社會里很多時候講的是“關系”，即使這30年的改革開放使中國的經濟蓬勃地發展起來，但幾千年來留下的歪風還是不能完全的磨滅。所以想要創業的人事建議你要多跟客戶打好關系，與合作伙伴保持互利互動的模式，這將有利于日后事業的發展。

2.急流勇退，退居二線

這也是不少人的選擇。很多人在有了家庭以后，感覺到壓力太大，人的一生并非只有事業，他們想把更多時間用于對親人的照顧，對孩子的關心上。所以很多人會選擇一份像系統分析、系統維護、高校教師、專業學院講師這一類的工作。收入穩定，而且往往沒有一線開發人員那么大的壓力。

3.不懈努力，更進一步

無論你是一個Project Manager或者是Team Leader，如果你想繼續晉升一級，那還是會兩極分化的。從一個PM到一間公司的管理層，那所面對的事件會有很多變化。一個公司的總經理，要管理的不再是一到兩個項目的成本，而是整個部門的運作，整間公司的業務流程，所以要肩負的任務會更重。在下曾經有一位上司彭博士，他是企業的最高領導人，年薪超過三百萬，而且在報紙雜志上也曾經亮過相。平常只會在某些會議上輕輕地亮下相，說兩句講詞，平常的公司運作與業務管理都不需要他直接執行。這并不是說一個作為管理層很清閑，因為他們要面對的是更多的社會關系，與公司合作企業的聯系上。這跟一個PM的工作有很大的區別，所以要從一個PM晉升到管理層，那可是要付出更多的努力與汗水。

如果要從Team Leader上升為一個技術總監，那工作的方向也有所改變。像之前所說：一個TL可能更重視的是技術層面，講求與團隊之間的互動合作性，更注重的是開發的完善。而一個技術總監就無需要直接參加某個項目的開發，而注意的是開發的效率與成果，如何合理使用有限的開發資源，控制開發的風險和可能帶來的效果。

發展感受

經歷了8年多時間，在下從一個程序員到一個項目經理，之間經過很多的曲折，但因為每一個人的際遇都有所不同，所走的路也有不同，正所謂條條大路通羅馬，成功的路不止一條，在下也不想令各位誤解，而只想為大家說一下我的發展方向。如果您是一位開發人員，“程序員->架構師->Team Leader(Project Manager)->技術總監”是一條不錯路，這也是在下選擇的路。在我國，想要進一步提升自己，無論你想是以技術為重點還是以業務為重點，都離不開管理二字。在一些大型的企業，一個團隊往往會配備一個PM與一個架構師，盡管兩個人負責的任務各有不同，但你會看到一個架構師的收入往往不如一個PM，PM往往是這個團隊的核心領導者，是關鍵人物。因為公司能否賺錢，PM有著重要的作用。PM與TL并沒有絕對的區別，而且在一些中小型企業，一個開發團隊只有3~5人，一個TL往往會兼備業務處理、成本控件、架構設計、開發管理等多項任務。所以在下會把Team Leader與Project Manager定于同一層次，一個公司的老板往往不會知道團隊的架構師、程序員是何人，而只會向PM詢問項目的進度，所以只有晉升到這個層次，才有機會進一步提升管理能力，讓自己有上升的空間。至于要成為一個技術總監，那要求就不再單單是對單個項目的管理，而應該更則重于新興技術的引用，開發資源的合理利用，對開發項目敏捷性的處理等等，對此在下也在試探當中，未敢多言。

與編程牽手 和代碼共眠 從程序員到技術總監

從業IT十年,從程序員成為技術總監,現在回頭看一看,這條路也伴隨國內的IT一起風雨兼程10年,對IT技術由其是IT的純軟件開發這一塊,向即將要從事軟件技術研發的朋友談一談我的看法:

一.認清當前IT形勢,選擇合適的技術方向和技術起點

估計大家都多多少少知道,這個IT行業知識的更新很快,競爭很急烈.如果你對自己以后發展的方向在從業前有一個清析的計劃或認識,相信你會比別人走得更好,走得更遠,賺的錢也更多...呵呵

IT軟件從業的方向,一般都會有這些機會:產品售前(市場,業務),產品開發(編碼,設計,測試),產品售后(支持,實施),產品管理(項目管理等)

A.產品售前(市場,業務)

要從事這一塊的工作,主要是在軟件開發的前期(無產品),或者合同簽訂前期(有產品).一般要求對相關的業務和技術都要求很高,這可不僅僅是要求人際關系,交際能力.要想別人買你的產品,你得以專業的產品品質為后臺,以專業的談吐,專業的技術和專業的業務理解能力來取勝.從業者要求:

要求從業者要有一定的社會經驗,技術經驗或業務經歷,或一定的社會圈子和交際能力.建議:

剛剛從學校畢業的朋友或不符合上面條件的朋友最好要考慮清楚了.當然這世上沒有什么絕對的東西,就看你自己了.現實情況:

據我所了解的,作這一塊的都會是公司一些高層(有關系,有經驗)和業務專家或特殊背景的人員等.B.產品開發(編碼,設計,測試)

這一塊的工作,當然是IT從業大軍的主力了,但也得要考慮清楚.如果你要作設計師,或測試,最好先作一段時間的編碼, 一個好的設計師是不可能不精通相關技術平臺的!

國外好的測試人員也幾乎是從開發人員中選出來的,基至是軟件開發高手.a.代碼編寫

在這一個職業選擇范圍內最好是從代碼編寫開始.當然你也可以先作測試,看看人家是怎么寫代碼的是如何來作這個軟件的，借用人家的測試經驗也可以,以后有機會再來編一段時間的代碼也行.有時自己去寫一個軟件也可以,所以作編碼和測試都是一個雙向交互的.而不是編碼在前測試在后的.作代碼的編寫最好自己先看看別人的軟件,或由一些高手帶著指導一下,現在技術的學習都不成問題,關健是要連成一條線來學習和思考就會有一定的局限了.所以要熟悉整個的項目流程或業務流程不是靠個人編碼或在培訓班學一下就能解決的,個人的技術學習和培訓班大部分只能解決技術的學習問題,但作軟件不僅是要技術呀

三分技術七分業務說得不為過,業務的學習也是一個開發人員所要必備的,如果你在不熟悉業務細節之前建議你不要急著去寫代碼,那樣肯定會是對以后軟件的影響很大.先要熟悉一下業務.所以軟件開發人員掌握一門技術平臺和語言是必備條件但同時也必須要有一定的業務知識,這樣才是一個合格的軟件開發人員.當然精通軟件編碼,懂設計,熟悉業務,熟悉軟件項目開發流程的軟件開發人員是優秀的,那是高級研發人員的必備條件.如果你才入門或轉行或剛畢業,建議從基礎的代碼編寫開始,跟著高手或找一些成熟的項目多學習, b.軟件設計

當然這個職業要求行業的經驗,技術經驗都要有一定的基礎,薪水一般也會高很多,所以也是一些開發人員熱烈追逐的目標.但一個好的設計師不是一二年所能練就的,精通編碼,熟練設計模式和公司所采用的技術平臺,熟練一些設計理論并實際多運用,熟練公司業務,其實這個層面的壓力也最大,一個好的軟件在設計上的比重幾乎要占到七成.建議剛畢業的朋友或軟件初學者不要在這一塊來湊熱鬧,即使你作成了設計師,但在我眼中看來你也不是一個合格的設計師...當然你有這個能力來作設計師就要恭喜你了.c.軟件測試

熟練軟件測試的各種理論或實際運用,也要熟悉編碼技術及相關的技術平臺,熟練掌握業務.軟件測試中一般都會有:

單元測試,要求你熟練開發技術進行跟蹤調試,也就是白盒測試了

集成測試,對整個項目流程的測試,要求掌握業務知識,對設計的軟件能作功能上的測試或壓力測試等 ,屬黑盒測試

確認測試,對業務要很熟悉,測試軟件是否完全滿足了客戶的業務需求.總體建議:

1.熟練一種技術平臺,熟悉一種業務

剛入門的朋友很容易犯的一個毛病是,熟練:VB,VC,.NET,JAVA,C++,C,Dephi,PB,幾乎市場上要用的他全部會,唉,如果我看到他的簡歷上有這么一句話,這個人肯定不會在我考慮的范圍了.現在全球用得最廣最多的技術平臺體系也就三大體系:

sun的J2EE技術體系(JAVA):在高安全性,高性能上更勝一步,中高端市場上用得多

微軟件的技術體系(C++,.NET,c#,VB):在中,低端市場占絕對優勢,也是全球個人電腦操作平臺用戶最多的.CORBA技術體系統(一種分布式技術體系和標準)，全稱:Common Object Request Broker Architecture：公共對象請求代理結構,可以用不同的編程語言寫成，運行在不同的操作系統上，存在于不同的機器上。

一般介于底層和上層管理軟件之間，其他的還會包括底層開發:C,匯編,屬純底層的開發,當然要求技術的起點和業務背景更強,最好是學的專業:電子電氣,嵌入式行業,機械制造,數據采集等...看中你想要從事的技術體系,選好一門語言工具,好好上路吧...:)

永遠要記住:你什么都想學,你什么都學不精

2.從基礎入手,不要好高鶩遠,眼高手低,要與實際結合 B.產品售后(支持,實施)

這一塊對于開發技術的要求來講不是那么明顯,主要工作會在軟件開發后的工作,跟客戶打交道多,但更多要求體現在對業務的把握和客戶的交際上.有些軟件產品業務比較成熟,如果參與這一階段的工作,可以快速學習很多的業務知識,積累客戶交往的經驗

建議:剛入門或剛畢業的朋友,可以在這個工作上多選擇,等待時機成熟,立馬殺入軟件的開發或設計階段,當然,這一塊的工作作得好也不容易,如果適合你作, 工作環境或工資都不錯你就大可不必多想了...C.產品管理(項目管理等)

這一塊的工作主要體現在管理上,當然適合有一定經驗或管理能力的人員來擔當, 最后的技術從業方向總結：

技術型:先選擇好一種技術平臺,熟練一種開發語言和數據庫...專業專注的搞幾年再說

技術+管理型:如果你有一定的技術經驗了,并且人際交往,管理能力不錯,你就可以向這個方向發展

技術+業務型:精通一種技術平臺,精通一種業務,好好搞,這種人才最受歡迎...管理型: 如果你有一定的社會經驗,從業經驗,如果人際交往,管理能力還可以,老板也喜歡,就搞這個

業務型(市場):如果你對業務很感興趣,跟客戶的交往等也不錯,你可以選擇了,有適合的專業技術就更能錦上添花了

技術+市場+管理:老大的位置....:)

第五篇：2016年終總結—從技術助理(采購)到 程序員

2016年終總結

從2015年的7月份，…給了我一個以應屆生的身份感受社會的機會。在…的第一份工作是…。經過2015年的對崗位職責的了解，2016年我已經能夠獨立負責一些部門業務。我的工作主要是以下幾個部分，線上線下的采購、ERP系統的操作（主要包括bom搭建、采購、生產、銷售）、臺賬統計、部門報銷以及部門小庫房的出入庫管理。

采購應該是一個公司節約成本的開始，電子元器件這個市場本身就是質量魚目混珠，價格參差不齊，一件物品輾轉幾手可能就成為了高價。質量放在首位，貨比三家，保證價格的合理性，是我們采購時的最好的追求。線上平臺主要用于一些量小、不太常見的且不在硬件中起到主導地位的電子元器件以及一些部門研發需要的附屬物品等。線下平臺一般是合作過多次并且有良好的信譽的供應商，建立了一些商業上的信任，可以大批量的采購一些硬件所需的主要器件，這樣能保證質量的同時，價格也是相對低的。當然平時也要注意供應商的擴展，以免采購處于被動狀態。

ERP操作，是記錄生產流程，財務流向的直接有效的工具。從一開始的采購到后來的生產，銷售，能夠保證每一項工作有理可依，有據可循。也是部門與部門之間的無聲交流。一條貫穿公司業務流程的主線。我在2016年1月到6月，完成了IDTT、故障指示器、總保、核心板等上千個設備的ERP生產操作，主要包括搭建BOM、采購、生產、委外、銷售一系列的流程。雖然實際的采購、生產、銷售等是很重要的一環，但其實對于公司來講記錄這些也是不可或缺的一步。臺賬的記錄，如果說ERP是部門與部門的溝通，那么臺賬就是自我記錄的很好的例子。采購中合同的簽署，付款的規則，合同執行的進度等等，在臺賬中可以很直觀的看到。自我總結是必不可少的，2016年上半年幾十甚至上百個合同的記錄和執行都很詳細的記錄在了我們的臺賬中，并且實時檢查，每個月通過臺賬制定下個月付款計劃等。

2016年7月，公司又給了我另一個機會，崗位從技術助理調整成軟件工程師。工科畢業的我本就對編程有著濃厚的興趣，得知本部門有軟件崗位的需求，便提出了轉崗的要求。

我接觸的第一個項目是…，我負責此項目的客戶端部分，初遇C#我，是措手不及的,C#的面向對象對于我來說是一個新的思維模式，所以學習新的知識成為必經之路，轉崗之前自學了C# Primer Plus，涵蓋了計算機語言的基礎知識和面向對象語言的獨特之處。但這本書是以入門為主，看完這本書之后直接接觸了…項目的部分程序，經過兩個星期的熟悉，基本上能了解之前程序的思路，此時我主要負責的是winform搭建界面部分。

這部分還需要實現的是…這些功能。2016年7月到8月，基本完成了上述幾項任務，也學到了很多，此時才是我感覺自己真正入門的時候。通過這兩個月的學習和工作，我對面向對象的理解也更加深刻，在修改或者添加程序時，也會去學習功能的具體實現方法，思考邏輯上合理性。尤其是在修改的時候，必須兼顧上下運行的邏輯，避免錯誤的出現，慢慢的感覺到其實語言真的是互通的，不管是C還是C#我的邏輯是一樣的，只是在面對不同語言時，就像是在使用不同的工具，但是殊途同歸，順著自己的思路不管用哪種語言總是能實現相同的功能，體會到這一點后，我感覺自己對C#的學習又多了幾分信心。因為對這個程序的了解，在功能實現階段之后，客戶端程序都交由我負責。在上個階段時，為求快速實現功能會有很多邏輯簡單但是代碼冗余的情況出現，比如…功能、…功能、…功能。自此我便走上了簡化代碼的道路。統計分析和分辨率自適應都是因為多用了列舉的方法，各種不同情況出現都要重復幾乎相同的代碼，所以摒棄了這些方法，做到讓程序自己判斷不同情況做出不同處理。設備配置是關乎用戶體驗的一項功能，之前的操作較為繁瑣，不能只是簡化方法那么簡單。而此時軟件正在強調設計文檔重要性，本著試試的態度，開始了就設備配置而言的程序設計文檔的編寫。

從界面設計到每個方法的實現都寫了下來，發現寫文檔是一個很好的拓寬思路并記錄思路的過程。其實之所以決定寫文檔更大的原因在于寫這個程序之前，雖然有一定的思路和想法，但是無從下手，從何寫起是一個大問題。這次文檔編寫，規范思路，找到程序入手點，拓寬思路，有條不紊的實現過程其實是有一種成就感的，沒有緊張混亂的情緒使這次開發感覺很輕松。之后也寫完了這個功能程序并封裝成了類庫放進了原來的項目中。9月到10月期間對此項目的完善也讓我對winform的運用更加熟練，也有了一些自己對于程序的思路和 想法。

應項目需求，需要把…的實物展示改造為線路模擬形式的展示，并實現原來界面上的所有功能，包括…功能、…功能、…功能、…功能、…功能等。這次改動的特別之處在于…，之前…項目的的總保最高上限是6個，所以把每個都作為一個單獨的對象處理。現在數量是20到30個，之前的方法在此顯得不太合理了。在11月完成了這個任務，這個解決方法應該再用回到…項目中（正在實施）。

12月份參與了…的編寫，初步了解了Window系統的API函數和Winform的GDI+畫圖技術，當然這兩項技術需要今后在學習中鞏固。但是因為故…持續時間應該準確到毫秒級別，但受Windows系統的限制，精確度并沒有達到。對于這次開發，我也認識到了自己的不足，知識面狹窄，利用新的技術的手段有很大的局限性。學會一項技術很重要，在開發項目面前最有效的方法是使用技術。

2016年對我來說是很特別的一年，感謝所有給過我機會的人和事。我在2017年一定會更加努力的去學習更好更多的技術，從網絡、書籍等不同的途徑獲取更多的知識，拓寬我的知識面，為之后的工作打下堅實的基礎，也希望我的知識能夠為公司創造更多的利益。