- 我成為了一名職業程序員，但是我發現所有的算法別人都已經實現了，我只要調用就可以。似乎我們公司的軟件與數據結構、算法的關系都不大。那我當初辛辛苦苦學習的數據結構和算法有用么？如何區分一個好的程序員和不好的程序員呢？
體會：書中舉的四則運算的例子做深了以后可能還涉及一些相對比較復雜的算法，可是在現實中接觸到的系統很多是業務驅動的系統，用戶量可能不會超過2000，CRUD，業務復雜流程交給成熟的工作流系統去做了，CRUD是很簡單的數據庫表操作，數據庫操作有現成的框架，前端有現成的框架，后端有現成的框架，程序員要做的事情就是熟悉現有的框架，完成相應的業務模塊的開發。典型的開發過程是：拿到一個業務需求，建模->轉換成實體類->對這個實體類的CRUD->拖出一個工作流流程圖->把流程涉及的表單用前端框架做好->調用封裝好的工作流的方法實現業務流程操作。在整個過程中，似乎用不到任何復雜一些的算法和數據結構（最多可能會考慮一下實體類之間一對多之間的關系），但是仍舊有些程序員做的很好，bug非常少，功能也很穩定，有些bug很多，這樣可以區分去好的程序員和不好的程序員么？
- 有人說一個人就可以快速成長為一名全棧工程師，這讓我想起街頭賣藝的單人樂隊(One-man-band), 他們什么都會一些，可以很快地演奏一些曲子。
體會：我大概聽過兩類企業，有一類是每個工程師就是一個螺絲釘，在自己的某個技術上發揮極致的能力，有一類是每個工程師類似一個"大雜燴"（這個比喻不知道恰當與否，就是表示工程師需要處理項目中各類技術方面的問題），前一類公司培養出來的工程師可能是強化自己現有的技術能力，而另外一類公司的工程師，就是在拓寬自己的技術能力，第二類公司培養的人員，似乎就有點像作者所說的"演奏家滿場奔跑，操作各種樂器"，可是我認為這種方式并非不好，因為現在很多開發模式是前后端工程師分開開發，但是前后端工程師開發的速度可能有差別，所以，最大化時間利用率是前端開發完畢以后，可以支援后端開發，反之亦然，這樣就可以讓項目進度整體加快，而這就需要"演奏家滿場奔跑，操作各種樂器"。其次，作者在第17章17.3.4節中介紹 團隊的 創造階段（Performing）的時候說到一點：團隊成員相互支持，相互依賴，角色和職責能夠根據項目的要求自然轉換，沒有人為此擔心或發牢騷。這里說的自然轉換，是不是就是 "演奏家滿場奔跑，操作各種樂器"？最后，是不是精通某個技術就是要放棄其他技術的學習，這兩者要怎么平衡呢？比如一個工程師，前后端都可以上手做項目，他到底應該怎么去精通某個方面呢，完全放棄前端專心做后端？還是完全放棄后端做前端？
- 技術產品的發展周期（萌芽->成長->成熟->衰退->結束）
體會：這里的技術產品包括編程語言么？很多語言雖然語法不一樣，但是都能實現同樣的功能，可是還是會有火/不火的區別，這樣的話，如何準確判斷一門編程語言的發展階段，從而在學習的過程中不會浪費時間到最后學了一門被淘汰的語言？此外，我在學習過程中，總會存在一種不安全感，總覺得學這個可能會淘汰，然后去追逐一些新出的技術，或者熱門的技術，如何克服這樣的不安全感？
文章列表
留言列表
