讀《構建之法》感悟

 

     初次看到構建之法時，感受一門課，居然發兩本書，還要求咱們寫技術博客，而且經過博客與老師和同窗們交流，任務不少，很重的樣子，咱們大多數人根本沒有多少的實際開發經驗在這種狀況下，去學習軟件測試，會不會滿是理論，都是一些虛無縹緲的東西，會不會如同雞肋呢？不由心中打起了小鼓。不過聽了授課老師的介紹，感受還不錯。隨手翻了翻，感受故事性挺強，不知不覺就看了兩章，以後我就有時候在睡前看個十幾頁，而後睡覺。

    有時候想這本書若是在大一的時候，就看到了，或許對程序員這個行業就會少一些迷茫，多一些準備吧。這本書讓我更加了解這個行業，我感受這本書與現實的接軌仍是不錯的。給我指引了一些方向。在一些重點字眼上，還會加粗，咱們就會容易的找到那些關鍵詞。書中有不少人物間的對話，那些對話不少具備趣味性，讓咱們讀的感受不那麼枯燥，在開發的過程當中，不一樣人物之間對項目的見解，對項目的某些問題產生的疑問，以及日常生活中都會碰到的溝通問題等，都給了我不同的角度。

    印象最深的就是給咱們介紹了軟件=程序+軟件工程，這個道理原本很普通，但經過一個例子，理解的較深一層。程序和工程的差異差很少就是工做量的大小不一樣，經過一個很簡單的小例子阿超給他的孩子寫了個程序，擴展到一個知足各類功能的應用軟件，在擴展到能保證服務質量的軟件服務，這期間就展示了軟件工程的重要性，雖然這期間只是多了一點點的需求，可是前期若是沒有對這個程序進行良好的需求分析，後續的維護會變得有點複雜。軟件工程的目標，就是創造「足夠好」的軟件，其中用戶滿意度，可靠性，可維護性都會在阿超發佈在網上的軟件上體現出來。咱們的老師，讓咱們本身每一個人寫一個簡單的四則運算，而且和同窗們比較了一下各自程序的功能，實現方法的異同，還有各自的優缺點。在這其中我發現每一個人擅長的語言是不一樣的，每一個人的想法也不一樣，編程習慣，方法在不知不覺中，已經發生了變化，。經過對比代碼，才發現本身的格式，註釋，還有編碼習慣都有許多須要改進。

   還有也理解了一些，爲何好多軟件公司爲何老是缺人，而學習計算機的畢業生也是不少的，也不至於老是供不該求吧，聽到一個HR說寧缺毋濫，由於每一個人的工做質量都直接影響着最終軟件的質量。用了個踢足球的例子，若是隊員中又一個很弱，不管你制定什麼樣的策略，用處都不大，因此提高我的能力很重要，在咱們的職業發展中，孰能生巧很重要，在熟能生巧上，能弄懂，那麼你就是更上一層樓，都說程序員天天的工做就是搬磚，那你的工做量就是有多少塊磚，要搬多遠。簡單的衡量你的工做質量就是多塊搬完，搬得過程當中損壞了多少塊磚。

    做者經過玩魔方的例子，給咱們講了軟件工程師的成長，我開始思考本身的能力以及問題所在。曾經以爲本身學過html，還學過java，ps,自學了javascript, jquery等也本身嘗試的寫了網上商城。可是，這真的就夠了嗎？知識與實際的應用能力仍是差一大截。中間出現了一步錯誤，我就須要好久才能發現。知道、掌握和精通這幾個關鍵詞我本身究竟到了哪一步呢？這麼多的技術我差很少都只是停留在了知道的層面，那比起那些不是軟件工程專業的人，我有什麼是突出的呢？ 對於學校的考試來講，知道這些足以應付考試。可是我若是要想成爲一名Web前端的開發者，還有多少的路要走呢？

   軟件測試在咱們的軟件中的地位愈來愈高，而它的測試工具，方法也是多種多樣，不由讓我有些茫然，項目經驗的缺乏，是一個大BUG呀，可是經過軟件測試，我仍是能獲得一些感悟的，人的思想老是有些地方考慮不全，經過經驗，咱們能減小一些錯誤，可是其中存在缺陷是不可避免的。因此我會在我寫的代碼中多一些留意，多一些單元測試。儘可能完善本身的代碼。

     書中的一些其餘，團隊管理經驗，讓我能夠作個好的員工，也可讓我作一個有效的管理者，在一些小細節上，這本書已經對我產生了一些小影響，我想《構建之法》這本書，我在不一樣時期，讀的感悟也會有所不一樣吧，是一本值得多讀幾遍的好書，每次都能有新的體會。

個人疑問：

1. 若是我想帶着本身的一個完整的做品去找工做，那麼這個完整的做品能夠是什麼樣子的呢？
2. 大學期間到底應該怎樣更好的學習？
3. 書中列舉了幾種的職業發展之路，那麼怎樣選擇纔是最適合個人將來職業發展呢？
4. 一個項目團隊的創立，發展，它的週期性有多長合適，如何長期維持下去？
5. 咱們常常看見，軟件公司招收的人員都是要具備工做經驗的，那麼咱們這些菜鳥，如何度過無經驗到有經驗的大神呢？