敏捷開發技術構想

05-11

在具體的技術層面,我們擁抱敏捷,精益,全棧和DevOps.軟體行業為了探索更高效務實的技術模式已經努力了幾十年,也取得了很多成果,我們沒有必要拒絕那些被驗證過的,對提高開發效率行之有效的技術.

當然,從整個信息產業的歷史來看,軟體技術處於初級階段,從彙編(機器)語言到各種被稱為第三代的高級語言,思維關注的重點仍然是機器,思路和業務邏輯隱藏在機器的執行流程後面,需要曲折的思維轉換才能明白代碼執行的目的.曾經被熱炒的第四代編程語言並沒有真正在實際應用中普及起來.我認為,這種思路和方向是對的,也是軟體發展的的必然趨勢.但是當時在過度炒作的背後,主要存在的問題的理論深度不夠,應用質量不高.

實際上我們有更為源遠流長的技術積澱,即函數式編程思想和UNIX編程哲學,老一輩的軟體工作者為我們留下來了理論和實踐的寶貴財富,卻一直沒有真正被好好挖掘並推廣應用.而在今天,隨著硬體性能的提高,網路的發展,軟體應用範圍的廣泛和深入,市場需求和技術環境都在孕育著一場深刻的變革.表面上來看有炒的很火的大數據,雲計算,人工智慧,實際上深層的根基還是函數理論和UNIX工程哲學.

從各種主流語言紛紛加入lambda表達式,擁抱函數式,到各種函數式編程技術和理論的火熱流行,都顯示了一股潮流和重要的發展方向.代碼應該是聲明式的,關心要做什麼,而底層的技術提供怎麼做,而不是像之前的技術,把業務邏輯和實現混合在一起.這並不是新思想,事實上,不管使用什麼技術,優秀的軟體都是按照這樣的思想去設計和構造的.比如Linux內核的開發,就堅持約定和實現分離的原則.沒有這種清晰的劃分,軟體幾乎總是陷於機器結構和執行流程的泥潭中.一般人搞不清楚程序員所做的工作,程序員自己也是在業務和機器的交織中艱難前行.程序員的高收入和高壓力也是在這樣的環境下也是一種無奈的狀態.

所以業務邏輯和機器執行的交織是問題的癥結,也是軟體行業問題的關鍵.軟體一定是由人所制定的業務邏輯和機器具體的執行流程組成,但是這兩者如果沒有清晰的劃分,混雜在一起,就成為了災難和隱患.

我的意見是,大部分人,或者說大部分程序員(未來社會人人都是程序員),沒有必要關注底層的技術實現,只需要清楚的聲明業務邏輯,而少部分框架級的技術人員負責實現框架,解析業務邏輯,和作一些整合,適配以及優化的工作.

理想很美好,但是現在實現到什麼程度了呢?根據我使用Java和javascript進行實際業務開發的經歷來看,通過使用lambda表達式和filter,map,reduced等高階函數,在代碼中幾乎不會出現需要手動控制的循環.某些業務需要根據條件停止遍歷,也可以使用更為完備的函數式庫來解決.這樣整體代碼邏輯非常清晰易讀.並且在熟悉了函數式思想之後,各種語言間的差別多數也只是lambda的語法細節,思路是一致的.還有一個較大的差別就是類型系統.我的建議是,如果夠用的話,優先使用動態弱類型,在確有必要的情況下,使用強類型實現代碼控制.尤其是在創業初期,需要快速實現功能,使用動態類型可以顯著提高開發效率.等業務擴大之後,再根據情況適時重構.

當然,實際的業務場景可能更加複雜多變.但是根據二八法則,首先我們應該關注最常用的20%,基本涵蓋了80%的業務場景.降低了這部分代碼的複雜度,投入不高但收效顯著.其他場景,如果遇到,多數情況下也可以通過簡單方法的組合和變通解決.隨著對業務的熟悉和經驗的積累,一個零經驗的學習者是可以在完成基本工作的情況下快速學習和成長的.

下面附上一些最近探索的快速開發技術,感謝各位開源作者.

Java: spring boot, spring data(重要的子項目有Jpa,rest), spring roo

Javascript: restSql alasql metetor vue wepy mpvue weweb

語言: kotlin clojure

運維: k8s nginx

版本控制: git

IDE: IntelJ Idea

看起來項數不少,但是每一項只關注基礎操作都不用太長時間,基礎操作熟練之後,通過模仿,練習和指導足以完成一般的開發任務,隨著時間在更多實踐和學習後也會持續獲得更強的技術能力.降低技術的准入門檻,一方面可以減少軟體的開發成本,另一方面減少了軟體人才的培養成本,對於軟體行業的發展來說是必要且可行的道路.

更多關於UNIX編程哲學的內容,請參考:林鵬程財務分析軟體。