最近一直在忙于寫代碼,因為春節前必須提交用戶.所以每天便是瘋狂的敲擊鍵盤,為了趕進度,為了按時完成任務.這幾天做的差不多了,也開始考慮自己的個人發展問題.很快就30的人了,雖然還是喜歡寫代碼、喜歡調試程序、喜歡面對各種有意思的問題、喜歡鉆研技術,但年齡還是把我推向了一個該好好考慮自己的個人定位的時間,因為在中國30歲應該是程序員的墳墓了。結束編碼生活,開始一個全新的開始,但應該開始什么呢?我自己也不知道,這么多年的編程,讓我除了編程還能干什么呢?現在可以想到的就是系統分析、或者再鉆研一下業務,去搞需求,或者就是告別這個行業,進行一種全新的創業,但項目是什么?頭疼呀,但卻不得不頭疼。三十而立,馬上就三十,可是三十我將要一無所有,想想畢業時一心想搞開發,現在呢,說不清當時的決定是對還是錯?????
mysql的jdbc驅動的問題,到http://downloads.mysql.com/snapshots.php下載了mysql-
connector-java-3.1-nightly-20051118.zip或mysql-connector-java-5.0-nightly
-20051118.zip都可以解決
看了好幾天的IOC,今天才算看明白,實際上使用的就是一個很簡單的面相對象的理解,就是子類可以替換父類原則,使用一個類盡量要使用抽象的父類(抽象類和接口),需要具體實現的時候,用具體子類進行替換.替換的方式包括構造注射、值注射和接口注射。
構造注射:在使用類的構造方法中,通過參數,將使用類作為參數(抽象類)
值注射:可以理解為一個屬性,通過set方法進行設置(參數當然還是抽象類)
接口注射:沒太仔細看,好像是在使用者和被使用者之間添加了一個中介
總之所謂的注射也就是一種解耦的辦法罷了。
最近兩周一直在忙于重構以前的一段代碼。代碼是一個很復雜的算法,總共有4個主要的方法,代碼行數之和大概有4千多行。這個算法以前不是我寫的是一位已經離職人員的大作,剛開始接受的時候我看的頭都大了。現在想想造成這種情況主要原因主要有:
1 因為這是一個很復雜的算法,需求文檔寫的也不是很詳細,導致理解起來很費力,最后是通過不斷和測試人員不斷交流,才了解了整個算法的大概。
2 看代碼最可怕的事情是什么?結構不好、變量命名不規則、實現思路不符合常規。都不是,最可怕的是沒有注釋,我所要面對的是我可以自由發揮想象的代碼,可是 一個算法不是我可以隨意定的。剛接手代碼時的主要工作就是,給代碼添加注釋,一邊看一邊補注釋,最后可能達到每5行代碼就可能有一行注釋,就這樣才把代碼 的實現絲路搞得差不多了。
3 方法過長 4個方法,4千多行代碼,平均每個1千行,但最大的那個方法有2千多行,看著無注釋的兩千行代碼,我暈。
4 重復功能的代碼 接受別人的代碼,如果感覺是重復的代碼,自己也不敢給立刻改造,需要把兩段代碼仔細的比較,生怕有紕漏,導致一些更可怕的問題,畢竟當時對代碼和算法不熟悉
5 龐大的if else、for while 循環,看代碼的時候需要對那些{},眼暈,代碼太長了,如果你想了解一段代碼的功能,難了。
6 數據類的命名 那位老兄懶點,有些后來添加的屬性,他懶得添加代碼,就用原來的方法,看看代碼就給帶溝里去了。
7 很多無用的變量充斥其中,讓你四處查找該變量在哪用的,最后發現,沒用,氣瘋了
痛苦的經歷,當時看這些代碼辭職的心都有,型號當時在外面做項目,可以慢慢的消化,如果在公司,問題日清,恐怕我也要被清理走了。
下面說說我重構的過程,主要是針對上面提到的幾點:
1 不用說了,理解算法,才能作出正確的實現,也才能保證修改的代碼減少出錯的機率。
2 注釋以前添加了很多,現在在回頭再仔細看,當時有些理解是不正確的,修正那些注釋,同時把自己最新的理解添加到程序上。添加注釋時對于實現長點的代碼可以 用一些特殊的符號 象#$等一些特殊的符號分隔開,注釋里說明這段代碼實現的功能,同時在開始和結束的注釋上 添加一個簡單的start、end,看起來舒服多了
3 方法過大,沒有其他的解決辦法,拆方法,但拆方法的時候要考慮變量的作用域,盡量確保一個變量的作用域在一個方法中,這樣可以減少代碼的出錯的可能性,是在不行的就通過返回數據的方式,給變量重新賦值
4 對于重復的代碼,沒其他的辦法,抽象出一個新的方法,讓后在主方法中調用。但這種修改可能會造成一個不太好的現象,就是代碼調用層次太多,調試起來也很麻煩,這問題只能等以后在做大的重構的時候,對實現思路的重構了
5 對于if else ,或者循環,看看是否可以通過continue、break 來減少嵌套層次
6 數據命名,這是每個程序員進入新公司的必修課,如果沒人管,那只能說管理有問題。可以通過一些重構工具來修改變量、方法的名稱、相應的工具會修改引用的名稱,減少出錯的可能性
7 多余變量已經要堅決刪除,不是考慮什么效率問題,知識考慮代碼的可讀性。現在地很多開發工具可以表示出沒有引用的變量,刪除、重新編譯看看有沒有引起相關的錯誤
本來前些時剛看完設計模式,想用用呢,因為算法中有很多相對的算法可以通過策略模式解決,可是最后犯懶,以后再說吧。
一點感受,希望能和大家交流:)
構造注射:在使用類的構造方法中,通過參數,將使用類作為參數(抽象類)
值注射:可以理解為一個屬性,通過set方法進行設置(參數當然還是抽象類)
接口注射:沒太仔細看,好像是在使用者和被使用者之間添加了一個中介
總之所謂的注射也就是一種解耦的辦法罷了。
最近兩周一直在忙于重構以前的一段代碼。代碼是一個很復雜的算法,總共有4個主要的方法,代碼行數之和大概有4千多行。這個算法以前不是我寫的是一位已經離職人員的大作,剛開始接受的時候我看的頭都大了。現在想想造成這種情況主要原因主要有:
1 因為這是一個很復雜的算法,需求文檔寫的也不是很詳細,導致理解起來很費力,最后是通過不斷和測試人員不斷交流,才了解了整個算法的大概。
2 看代碼最可怕的事情是什么?結構不好、變量命名不規則、實現思路不符合常規。都不是,最可怕的是沒有注釋,我所要面對的是我可以自由發揮想象的代碼,可是 一個算法不是我可以隨意定的。剛接手代碼時的主要工作就是,給代碼添加注釋,一邊看一邊補注釋,最后可能達到每5行代碼就可能有一行注釋,就這樣才把代碼 的實現絲路搞得差不多了。
3 方法過長 4個方法,4千多行代碼,平均每個1千行,但最大的那個方法有2千多行,看著無注釋的兩千行代碼,我暈。
4 重復功能的代碼 接受別人的代碼,如果感覺是重復的代碼,自己也不敢給立刻改造,需要把兩段代碼仔細的比較,生怕有紕漏,導致一些更可怕的問題,畢竟當時對代碼和算法不熟悉
5 龐大的if else、for while 循環,看代碼的時候需要對那些{},眼暈,代碼太長了,如果你想了解一段代碼的功能,難了。
6 數據類的命名 那位老兄懶點,有些后來添加的屬性,他懶得添加代碼,就用原來的方法,看看代碼就給帶溝里去了。
7 很多無用的變量充斥其中,讓你四處查找該變量在哪用的,最后發現,沒用,氣瘋了
痛苦的經歷,當時看這些代碼辭職的心都有,型號當時在外面做項目,可以慢慢的消化,如果在公司,問題日清,恐怕我也要被清理走了。
下面說說我重構的過程,主要是針對上面提到的幾點:
1 不用說了,理解算法,才能作出正確的實現,也才能保證修改的代碼減少出錯的機率。
2 注釋以前添加了很多,現在在回頭再仔細看,當時有些理解是不正確的,修正那些注釋,同時把自己最新的理解添加到程序上。添加注釋時對于實現長點的代碼可以 用一些特殊的符號 象#$等一些特殊的符號分隔開,注釋里說明這段代碼實現的功能,同時在開始和結束的注釋上 添加一個簡單的start、end,看起來舒服多了
3 方法過大,沒有其他的解決辦法,拆方法,但拆方法的時候要考慮變量的作用域,盡量確保一個變量的作用域在一個方法中,這樣可以減少代碼的出錯的可能性,是在不行的就通過返回數據的方式,給變量重新賦值
4 對于重復的代碼,沒其他的辦法,抽象出一個新的方法,讓后在主方法中調用。但這種修改可能會造成一個不太好的現象,就是代碼調用層次太多,調試起來也很麻煩,這問題只能等以后在做大的重構的時候,對實現思路的重構了
5 對于if else ,或者循環,看看是否可以通過continue、break 來減少嵌套層次
6 數據命名,這是每個程序員進入新公司的必修課,如果沒人管,那只能說管理有問題。可以通過一些重構工具來修改變量、方法的名稱、相應的工具會修改引用的名稱,減少出錯的可能性
7 多余變量已經要堅決刪除,不是考慮什么效率問題,知識考慮代碼的可讀性。現在地很多開發工具可以表示出沒有引用的變量,刪除、重新編譯看看有沒有引起相關的錯誤
本來前些時剛看完設計模式,想用用呢,因為算法中有很多相對的算法可以通過策略模式解決,可是最后犯懶,以后再說吧。
一點感受,希望能和大家交流:)
| |||||||||
日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
---|---|---|---|---|---|---|---|---|---|
25 | 26 | 27 | 28 | 29 | 30 | 1 | |||
2 | 3 | 4 | 5 | 6 | 7 | 8 | |||
9 | 10 | 11 | 12 | 13 | 14 | 15 | |||
16 | 17 | 18 | 19 | 20 | 21 | 22 | |||
23 | 24 | 25 | 26 | 27 | 28 | 29 | |||
30 | 31 | 1 | 2 | 3 | 4 | 5 |
常用鏈接
留言簿(1)
隨筆檔案
搜索
最新評論

- 1.?re: IOC的簡單理解
-
其實很多fashion的思想在Thinking in java 中都有提過
好好研究一下Thinking in java 還是很有收獲的 - --Sung
- 2.?re: mvc是model驅動view還是view驅動model
- 評論內容較長,點擊標題查看
- --SongOfSky
- 3.?re: mvc是model驅動view還是view驅動model
- 用Observer將Model和View解藕
- --Xuefeng