121 基於MVC框架下的網上書店系統 002 項目開發計劃

計劃列表

1、筆記python

1.1 spring、spring mvc、Hibernate、MyBatis、Shiro、Security等框架筆記

1.2 Maven、Gradle、Eclipse、Android Studio等工具使用技巧

1.3 前臺頁面代碼片斷記錄、JQuery、Bootstrap框架使用

1.4 Android學習記錄【以小項目形式】

2、周邊技術spring

2.1 groovy
2.2 Python

3、周邊工具數據庫

3.1 截圖工具
3.2 PS
3.3 Axure
3.4 Powerpowerdesigner
3.5 Atom

4、英文文檔編程

4.1 Spring In Action

計劃說明

1、筆記mvc

  這一部分主要是記錄一些技術上的問題,好比Spring MVC的配置,Hibernate的一對多、多對一,又或者Maven/Gradle多項目構建等。原本是想每一個技術寫一個系列,不過考慮到第一個項目主要是爲了練習、提高寫一個完整項目的能力,是爲了寫項目學技術,而不是爲了技術寫項目。因此就先零散的記錄一些寫121項目期間遇到的技術問題以及解決方案。框架

2、周邊技術編輯器

  這一部分主要是記錄一些Java EE、Android以外的東西,好比說我使用的構建工具是Gradle,可是我應該會同時支持Maven構建,這就須要把Gradle的groovy腳本轉換爲Maven的xml腳本,用python來處理這個問題顯然比較合適。又或者批量處理日誌文件、自動備份數據庫等問題,在我看來,這些問題不只僅是Java EE開發或者Android開發所獨有的,因而我把這些問題的處理須要用到的東西歸爲周邊技術,雖然Python、日誌分析、數據庫管理等每個都是很大的話題,不過如今還不是花費大量時間學習這些東西的時候,能把一些解決方案記錄下來就能夠了。工具

3、周邊工具學習

  這一部分就徹底是備忘錄形式的筆記了,好比PS的簡單使用,Atom編輯器的配置、經常使用插件,或者是Powerpowerdesigner的使用等,只要不是和IDE相關的軟件,所有放到這一部分。如今還處於使用工具的階段,想要達到設計原型或者使用Powerpowerdesigner設計數據庫這種水平,就是之後的事情了,先學會用工具再說。測試

4、英文文檔

  英文對我來講是一個短板,並且個人英語不是通常的差,基本上除了常見的error log能夠看明白,其它的英文一律不懂。可是在如今這個時代,英文水平在某種程度上能夠直接拔高工資水平,因此不想學也得學。而我學習的方法就是看英語技術資料。Spring In Action我認爲就比較合適。

關於學習技術與寫代碼的那些事

  學習編程技術,尤爲是自覺編程技術,歷來不是按部就班的事。我以爲我不可能把Android的UI組件所有學完再去看activity ,這種學習方式不管是從效率上仍是可行性上,都是不高的,我認爲也是不可取的。固然,想要成爲神同樣的技術大拿,確定得對一個領域的方方面面都很是瞭解,可是從頭至尾的「一步一步」學習一個領域的東西,就算能堅持下來,那要不就是真的成了大神,要不就是什麼也沒學會。因此我以爲真要深刻軟件開發的某一個領域去鑽研,那就應該不停的寫項目,寫涉及不一樣需求、不一樣行業的項目。好比我此次寫的是關於在線商店的,那麼下次就可能會是一個OA,多接觸不一樣的行業需求,才能擴展視野,也能加深對軟件開發技術的理解。在寫項目的過程當中,再記錄所遇到的技術問題和解決方法。等到接觸的差很少了,就能夠再重頭開始學習這個領域的東西,那個時候見識也有了,知識儲備也有了,固然也就能夠「一步一個腳印」的鑽研了。

  我以前寫代碼的時候,都是項目能運行,不報錯就行,至於BUG,那基本上就是忽略。此次寫這個系列我也不打算維護每一個已完成的項目,最多挑幾個我比較感興趣的東西長期維護下去。緣由有三:一、能力問題,如今還沒法作到寫出一個完整的設計文檔,再按照設計文檔寫代碼;二、經驗不足,BUG確定會有,把能解決的BUG解決掉就能夠,不能解決的記錄下來,下次再寫相似的項目的時候爭取避免或爭取解決,若是仍是不能解決,就得放到這人系列結束的時候使勁處理了;三、時間問題,這個列表中的項目,每一個深刻的作,均可以作得很大,可是我顯然沒有那麼多時間,在我沒有發現真正想要長期維護的項目以前,每一個項目都只是找一個同類產品去模仿,好比121項目就是模仿噹噹在線書店,若是遇到了想要長期作下去的東西,也許會放到這個系列結束以後再去長期維護。

對本身的要求

  1. 認真記錄問題,以及解決方案,最好能記錄對於同一問題在不一樣情境下最合適的解決方案

  2. 常常push代碼,不再能出現由於電腦壞告終果丟失數千行代碼的事

  3. 儘可能以最佳實踐去寫代碼

  4. 測試驅動開發,由於只有我一我的開發,因此更加應該使用測試驅動開發,這樣若是某一部分有設計上的問題,修改起來就比較容易

相關文章
相關標籤/搜索