一名技術人員的能力高低，不僅僅在於程式設計，更多的是一種思維，越接觸上層的技術與底層的原理，越是如此。當然，作為我們現在所處的位置，肯定要踏踏實實地擼程式碼，不要去過多思考高屋建瓴的東西。熟能生巧，手感熱了，思維自然慢慢地成熟起來。到後面，語言僅僅只是一門工具。
從一個Web站點說起
書的作者自己編寫了一個分享學習程式設計和設計資源的小網站——技匠社（jijiangshe.com） 我覺得這個網站本身就很不錯，提供的資源也有益於個人學習交流。 那麼這個網站是如何開發出來的呢？不同架構師肯定都有不一樣的方案，正如一千個人眼中有一千個哈姆萊特。但是，無論使用何種技術，以下幾個基本流程是不會變的。
-
網站定位與功能設定 1.1 你希望的你網站做什麼？ 網站或者App無論大小，首先應該非常明確這一點。面對的人群是誰，需要給他們帶來什麼他們所需要的服務。舉一個例子，我和朋友即將上線的App “果核”是一款面向本校大學生的校園學習生活服務類應用。 1.2 希望設定哪些功能？ 圍繞“校園學習生活服務”這個核心，我們分了幾個板塊：校園應用（課表/績點/館藏/俱樂部/校車/空教室）；每日推薦（首頁/此刻/彼時/星座/地氣）；小工具（待辦便籤/吃啥/分貝計/翻譯/查快遞等）；論壇（開發中）；健康管理（開發中）
-
資訊架構（概要設計/業務建模） 這個難度就比較高了，需要一定的經驗與思維力度，對不同緯度和粒度的資訊進行抽象，規劃，設計，從而支撐起整個網站的資訊體系。這就是架構師乾的活，如果達到了這個階段，已經步入高手的行列了。
"我經歷過很多不同的資訊架構方法論，從最初基於模組的設計，到後來的領域驅動設計（DDD），面向服務的設計（SOA），Oracle的基於資料建模驅動的設計，再到最新的微服務架構設計，等等。我想說，這些方法論大多是針對那些大規模應用而言的，你需要了解他們，並有意識地在你的系統設計中去匹配這些優秀的架構和設計思想，這有利於你做出擴充性良好的系統，從而避免了因整個系統複雜度的提升而導致大規模重構的風險。"
對照技匠社這個網站來看，需要定義三個實體類：User(使用者)，Resource(資源)，Feedback(反饋)。 圍繞這三個模組，再定義出三個服務：UserService，ResourceService，FeedbackService。 接著再為這三個服務設計需要用到的方法。
-
UI設計 對於資金充裕的專案，需要由專業設計師來操刀。再不濟也需要專業的前端設計和美工，然而很多小型專案，由於***沒有錢***，很多時候甚至由後臺程式設計師來憑感覺畫一畫（比如“果核”）。所以有空時，學一點設計，或者不需要刻意去學，多去領會一些美，品味自然會提升一些，這在我看來是很有必要的。 實際情況是，很多網站開發都會套用開源的模板，這樣可以避免重複造輪子，更為便捷舒適。但是使用模板也有他的缺點，大致分為以下幾點：
- 畢竟是別人的東西，對其思路不熟悉，在擴充時往往牽一髮而動全身。
- 模板包含了大量的對手頭專案來說多餘的和不必要的東西，這需要我們花時間去小心地剔除。
- 模板本身存在缺陷，需要我們修復。
- 在擴充新介面時，需要考慮和原模板的搭配，再次設計。
-
前端開發 就針對技匠社這個網站而言。 目前最流行的前端框架是AngularJS和React。在這個專案中選擇的是AngularJS,有以下兩個方面的原因：
- 我需要的是一個更完整的JS框架，AngularJS能滿足我在全面性方面的要求，可以使用它構建一個完整的Web應用。
- 我希望在將來用Ionic寫一個App，由於Ionic也是基於AngularJS的，這意味著，我將來可以複用很多程式碼。
-
後臺開發 SpringBoot：開發基於REST的服務。 MyBatis：提供基於SQL的持久層支援。 Redis：持久化使用者的Session資訊。 SpringSecurity：提供安全方面的支援。 MySQL：使用傳統的關係型資料庫。 Maven：專案的包依賴管理，以及專案打包。
Spring Boot並不是Spring的一個升級版本，而是一個為構建微服務提供更好支援的全新框架。他是一個能夠提供良好擴充性的框架，在初期可以將所有的功能作為一個整體對外服務，隨著使用者量的上升和系統規模的不斷擴大，可以藉助Spring Boot，並基於Domain Driven Design的設計思想將系統的的服務進行拆分，構建出一系列微服務。
- 部署+運維 對於這塊這塊不是很瞭解，不過至少需要會用Linux+Tomcat/Jetty+Apache+Nginx
技能樹
- 逐漸接觸使用命令列
- 在最初學習程式設計的時候，每一門語言都有整合了編譯器的IDE，這些整合開發環境十分方便，往往只要在圖形化街面上點選一個按鈕，就能完成一系列複雜的操作。這會讓人覺得，這是順理成章的事。而現在的很多工具，都在往簡約高效方向發展，有的甚至沒有圖形化介面。
- 打個比方，就像在玩CS這款遊戲的時候，可以調取選單，然後通過點選按鈕來購買裝備，這似乎並不繁瑣。但是假如你想訓練自己的閃光彈投擲技巧，需要購買無限的閃光彈，並在閃光彈投出以及碰撞的時候留下可見的拋物線，那通過選單點選操作就十分繁瑣了，很多玩家往往直接調出控制檯，輸入指令來完成這些操作。
- 這和使用命令列來控制你的作業系統有異曲同工之處。命令列在一些環境下可以提高工作效率。當然並不支援完全拋棄圖形化介面。
"以前，我在啟動一套本地的開發環境時，總是需要手工地一個個去單擊那些服務，逐一啟動web伺服器，資料庫伺服器，開啟IDE等等。這看起來每次只需要花費2-3分鐘的時間，但這是每天每天都需要進行的操作，而且由於除錯需要，一天之內需要重複啟動好幾次。一個月下來，我光在啟動環境的時間就花費了2-3個小時。後來，我便學著寫了一個shell指令碼，其實非常簡單，就是按照順序去啟動服務的命令，這樣我只要單擊那個指令碼，整個環境就搭建好了。因此，我經常鼓勵身邊的程式設計師去寫自動化指令碼，讓自己從重複性的工作中解脫出來。"
- 使用Git命令列來進行版本控制
-
程式碼重構 封存，以後再寫。
-
規範程式碼
- 封裝/繼承/多型使程式碼更簡潔，可複用率高
- 儘量規範程式碼的書寫，尤其不要使用中文以及儘量不要使用pinyin。
- 常寫註釋
- 多考慮異常捕獲情況
- 等等
暫時就寫到這，這本書整體還是不錯的，但是還是有點偏雞湯型，這種型別的書現階段而言只需讀一兩本就夠了，把握一下方向，更多還是需要去踐行。