作者 | feenk 整理 | 夢依丹
出品 | CSDN（ID：CSDNnews）
面對冷冰冰的機器、代碼、工具，程序員的首要工作是知其然並知其所以然，方能入手去敲打出美妙的代碼。
近日，一篇《Developers spend most of their time figuring the system out》的文章在HacekerNews上引起了不少開發者的共鳴，作者表示，程序員大部分時間都在摸索系統之上，而非構建系統。
對於這一話題，最早可追溯到1979年Zelkowitz、Shaw和Gannon出版的《軟件工程和設計原理》一書，書中描述到，程序員把大部分的時間（67%）都花在了開發維護上。
誠然，這本書並沒有告知這一數字的背後，那麼在40年後的今天，又是怎樣的情形呢？
在CSDN舉辦的2022開發者生態匯上，知名程序員，MegaEase CEO 左耳朵耗子（陳皓）在演講中提到，在國內沒有一家軟件公司有升級部門，經常是老到20年的系統依然在使用。可想而知，對於這樣的系統，程序員入職的第一件事或許就是弄清楚這些老“玩意”後進行着修修補補的工作。
對此，原文作者提到，論文《Measuring Program Comprehension: A Large-Scale Field Study with Professionals》中指出了程序員在一個項目上的時間分配，其中約58%的時間來理解系統，並闡述這一數字是如何得來的。
即使在40年後的今天，花在摸索系統上的時間並沒有變少。儘管這是一個非常大的項目成本，但人們在日常更多的是討論如何構建系統，而不是如何弄清楚一個系統。
開發者是如何搞清楚系統的呢？開發者更多是通過閱讀代碼來摸清系統的架構與分支，這一結論也在論文《Measuring Program Comprehension》得到了驗證。
那有沒有什麼其它更高效的方式呢？程序員爲什麼要閱讀源碼呢？其實對於程序員來說，如果只知其然而不知所以然，是很難進行下一步的代碼搭建，因此摸清系統，最主要的是爲了做出更好的編程決策。
閱讀只是從數據中收集信息的一種手段，也恰好可能是最手動的方式，這就爲優化提供了重要的機會。
在做一件重要的事情之前，人們往往會進行命名，否則就會像伏地魔一樣。在多年以前，把弄清楚系統然後再做下一步稱之爲評估，並且還提出應該圍繞評估來優化開發。
通過閱讀來提取數據是最機械的一種方式，無法規模化，還會帶來信息不完整和不確定性。在還未摸清系統全貌之前，決策不應該建立在信念的基礎之上。數據科學告訴我們，應該以問題爲導向去匹配相應的工具進行推理。
軟件不是一座孤島，而是由無數關聯項組成，因此人們無法預測具體的問題，但可以預測出問題類別。樹立可塑開發思想，在摸清問題之後，構建自定義工具流程，從而快速處理上下文中的重要內容。在未來十年，人們無需通過閱讀源碼來衡量是否“弄清了系統”，取代它的應該是解決實際的問題。
針對這個話題，HackerNews不少人都提到了結對編程，一位gleenn網友則提出了結對編程模式：人們往往會避免或者糾結結對編程，認爲結對編程所花費的時間和成本是非結對的2倍，這完全是錯誤的理解。當他在一個每天輪流做結對編程的地方工作時，在一個熟悉系統並能即時回答你提出的問題人面前寫代碼，一個新開發者的效率可以一飛沖天，比一個人做要快速好幾百萬倍。
ID爲kayodelycaon的用戶表示，在一個100%進行結對編程的地方工作，意味着無法結對的人就會被過濾，而能否進行結對編程，與當事人的方方面面都有着關係，比如自己有多動症、短期記憶方面的問題等。但自己卻能編寫出非常好的代碼，會考慮代碼的可讀性、算法複雜性、副作用、可測試性等多個小細節。
原文鏈接：https://lepiter.io/feenk/developers-spend-most-of-their-time-figuri-9q25taswlbzjc5rsufndeu0py/
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2022最新版)
4.別再寫滿屏的爆爆爆炸類了，試試裝飾器模式，這纔是優雅的方式！！
覺得不錯，別忘了隨手點贊+轉發哦！