1 技術發展的一些體會
從2016年開始, 筆者走上了"程序猿"這條路, 至今已經有6年了.
這6年來, 從項目開發所使用的前後端技術不斷變遷, 我深切體會到這一行技術發展的日新月異, 何其迅速.
本文不談具體的技術細節, 只談一談入行這6年來, 筆者對行業和這份工作的一些看法.
1.1 早期(2016年~2017年)技術
剛開始開發項目時(2016年), 筆者所在團隊使用的技術棧是Spring+jdbc+FreeMarker作爲項目的整體框架, 前端沒有太具體的技術, 硬要說的話, jQuery可能算是吧.
最大的特點就是, 許多層次是沒有很明顯的區分的.
後臺還好, 至少有Controller層和dao層的區分, 但有一些需要轉換處理的邏輯時, 有時是放在Controller層進行, 有時是放在dao層進行, 好在項目的大多數邏輯並不複雜, 倒也沒有遇到十分混亂的情況.
前臺就比較糟糕了, 五花八門的寫法比比皆是. 比如當時作爲新人的筆者, 在遇到給前端傳送數據時, 有時使用FreeMarker直接將所有數據放在模板轉換後的<script>中作爲一個js變量, 有時則使用ajax請求發送請求@ResponseBody的數據(這個在當時來看, 算是最合理的). 數據處理尚且如此混亂, 就不必提前臺的分層了.
這並非特例, 那個時代的中小公司開發情況普遍如此.
這帶來的一個問題就是, 後端還好, 前端在處理"新的"複雜頁面邏輯時, 會非常花時間. 而當時沒有什麼複用方案, 項目中充斥着大量複製粘貼代碼.
1.2 此後(2018年~2020年)技術
一次偶然的機會(大約是2017年底), 爲了解決這種複雜頁面開發效率低的問題, 筆者嘗試使用了Vue.
筆者最早用的是最原始的Vue開發模式,就是在每一個html頁面內的<script>標籤內直接new Vue({...}). 儘管使用方法原始, 但這成功的將視圖與數據分離, 使得前端頁面的開發效率大大提升.
後來(大約是2018年), 團隊在開發一個新項目時, 首先將前後端作爲兩個項目完全分離, 其次, 在前端項目使用了Vue2.0技術的完全體.
開始這樣做時, 團隊的大多數人都是比較痛苦的, 因爲雖然大家都知道這是大勢所趨, 但忽然放棄以往寫.html的熟悉的寫法, 而改爲使用.vue文件的寫法, 學習起來並不輕鬆.(儘管Vue在當時的三大前端框架中, 對新手最爲友好).
至於後端, 雖然改變也很多, 從Spring到SpringBoot的分佈式項目, jdk版本從1.7到1.8, 數據庫連接從jdbc到myBatis, 以及其他的一些變化, 只要有模板, 改變並不費力. 因爲後端的核心--實現業務邏輯層面, 變化並不大, 一點一點去掌握, 並不影響繼續開發.
1.3 技術學習不能買櫝還珠
最終大家還是適應了這種寫法, 開發效率當然有所提升.
但就筆者觀察, 很遺憾的是, 很多人的開發思維仍停留在了幾年前開發html頁面上. 遇到了相似邏輯的頁面, 第一想法不是通過自定義組件實現, 而還是複製粘貼, 或者尋求現成的插件(組件). 更不必說一些更復雜的特性, 如mixin,插槽,修飾符等, 或者對vuex和vue-router的深入瞭解了.
這裏提一句, 筆者認爲, 理解Vue的這些較深入的特性, 爲何而設計(解決何種問題), 在何種情景下使用, 比單單會使用要更重要. 尤其重要的是: 不要爲了使用而使用!
再有一點也是很多人(包括以前的我)所忽略的, 即: 現在的前臺技術, 已經能很好的支持, 在前端也實現類似MVC的層次, 即將模型層(model, 負責業務邏輯),視圖層(view),控制層(controller, 負責數據搬運)區分開. 對於Vue, <template>和<style>裏的內容可以稱爲視圖層, <script>裏的內容, 應該只實現控制層的內容, 即只負責數據的搬運, 將處理好的數據傳給視圖層, 而不應將模型層的工作也拿過來幹, 這樣邏輯一旦複雜, 開發和維護的效率又會很低了.
時至今日(2021底開始), 公司又開始使用了新的技術棧, 包括TypeScript,Vue3.0等新技術. 我還沒有完全接觸, 但不出意外會和3年前一樣, 再次經歷陣痛期.
2 工作內容中的重點
筆者以爲, 開發項目最重要的一點, 不是讓項目代碼變得多優雅, 或者結構多麼嚴謹合理, 或者框架多麼緊跟潮流, 開發項目只有一個重點--滿足業務需求.
所有的一切工作, 包括所使用的工具, 框架, 乃至於邏輯結構設計, 全部都應該爲業務需求服務.
因爲業務需求, 纔是真正體現項目價值的核心.
2.1 衝突發生的必然
之所以這麼說, 是因爲筆者遇到過很多種情況, 與提出業務需求的人溝通, 雙方的衝突點在於:
如果要按照++業務需求++完全實現, ++開發所需的時間/精力++, ++代碼的優雅性++, ++保持現有的邏輯架構++, ++系統的使用性能++, 這5個方面方面之間難以保持一個良好的互容, 往往要打破其中一個兩個甚至更多個, 才能很好的滿足客戶需求.
這其中, 業務需求往往是必須實現的, 好在一般可以相互讓步妥協.
2.2 溝通帶來的問題
關於業務需求, 另一點比較重要的是, 開發者自己需要始終對業務需求有着清醒的瞭解.
除了這樣做, 可以使上面所說的衝突發生的更少一些外, 這又有助於另一些涉及溝通的情況的處理:
- 需求方自己並不能很好的理解原需求(比如這個需求可能是來自領導或者其他方的). 這個挺要命的, 尤其是一些比較複雜的需求. 最好的方式是直接越過去, 找到原始需求方直接溝通, 不然就等着返工吧.
- 需求方與開發方在溝通理解上存在偏差, 這常常會出現.
因爲需求方自己往往是沒有軟件開發思維的, 而開發者對需求方的業務領域往往也所知有限, 最後很容易形成雞同鴨講的場面, 甚至雙方各自火氣上升;
沒有別的好辦法, 只能雙方各自剋制, 冷靜下來溝通才能解決.
3 以後該怎麼做
3.1 技術推陳出新帶來的負面影響
縱觀歷史, 科學技術在開始發明創造初期, 即使再能推動社會發展進步, 往往不能得到很好的推廣.
一個重要的原因是, 一項科學技術的進步, 往往意味着會有大量習慣原有技術的人無所適從, 利益受到損失, 進而反對, 有時甚至會有十分激烈的衝突. 譬如蒸汽機作爲動力進入紡織業時, 大量傳統紡織工失業, 這些人將矛頭指向紡紗機, 有些會武裝破壞.
這便是技術進步的負面影響, 它對整個社會而言確實是有利的, 但也實實在在的破壞了一部分人的利益甚至生計.
3.2 程序員的困境
相比於其他行業, 軟件技術的發展更加迅猛, 特別是前端.
這兩天看到一個新聞, 在5年前極爲風靡的一個插件layui, 它的官網已經停止提供下載服務了. 這項技術基於jQuery框架, 但到了如今這個數據視圖分離框架流行的時代, jQuery確實已如冢中枯骨無人問津了, 所以layui的停止服務, 其實也在預期之內.
程序猿, 特別是前端的程序猿, 可能是最容易無所適從的了. 學習的東西非常多, 偏偏這些技術過幾年就要過時, 就要學習心得技術, 這實在不是一件讓人愉快的事情.
筆者自認爲還算是一個比較愛好學習的人, 面對日新月異需要學習的內容, 有時也不免感慨一聲要學的太多了. 更不必提那些不愛學習/沒有時間精力學習/學習效率低的同學了.
筆者一直在想, 這樣下去何時是個頭呢? 5年前的技術放在現在已經過時了, 但如果只掌握了現在的技術, 又無法處理5年前的項目, 但5年前的項目又不一定只會使用5年.
程序猿這個行業就是如此, 不是在學習就是在學習的路上, 再往後5年10年會一直如此. 如果不學習, 那麼被淘汰就是遲早的事. 這也是爲何大齡程序員少的原因.
3.3 大齡程序員的優勢與劣勢與選擇
優勢:
- 對於業務邏輯更加熟練. 如果常年在一個業務內容體系裏開發系統, 這個業務經驗是不會隨着技術的進步而減少消除的.
- 掌握的舊時代的技術也並非完全無益. 其一, 總有一些舊的項目需要維護修改, 這對新人而言幾乎不可能做到; 其二, 舊時代的技術, 也有其可累計的地方.
劣勢:
- 年齡原因, 熬夜加班等能力遠不如年輕人, 在接收新知識層面有時也不如年輕人.
- 資歷與工資正相關, 但如果你在老闆眼裏, 性價比遠不如掌握新技術的新人的話, 離職也是理所當然的事了.
選擇(僅代表個人觀點):
- 學習技術, 要求深入, 不要一味求廣博. 譬如, 不要看着三大前端框架
Vue,React,Regular就都想學, 看準一個學, 並深入掌握其用法. 這些框架的深層思想是互通的. - 技術之外, 注重業務經驗與開發思維的總結. 這些是不會隨着技術的進步變更或者消除的, 是能真正累積下來的.
- 週期性輸出博客更新, 客觀的說, 這對普通程序猿而言是有一些難度的, 特別是輸出高質量的博客. 但堅持下去, 必有所得.
end