恕我直言：程序員大部分時(shí)間不是在寫代碼，而是。。。
面對(duì)冷冰冰的機(jī)器、代碼、工具，程序員的首要工作是知其然并知其所以然，方能入手去敲打出美妙的代碼。
近日，一篇《Developers spend most of their time figuring the system out》的文章在HacekerNews上引起了不少開發(fā)者的共鳴，作者表示，程序員大部分時(shí)間都在摸索系統(tǒng)之上，而非構(gòu)建系統(tǒng)。
對(duì)于這一話題，最早可追溯到1979年Zelkowitz、Shaw和Gannon出版的《軟件工程和設(shè)計(jì)原理》一書，書中描述到，程序員把大部分的時(shí)間（67%）都花在了開發(fā)維護(hù)上。
誠然，這本書并沒有告知這一數(shù)字的背后，那么在40年后的今天，又是怎樣的情形呢？
在CSDN舉辦的2022開發(fā)者生態(tài)匯上，知名程序員，MegaEase CEO 左耳朵耗子（陳皓）在演講中提到，在國內(nèi)沒有一家軟件公司有升級(jí)部門，經(jīng)常是老到20年的系統(tǒng)依然在使用?？上攵?，對(duì)于這樣的系統(tǒng)，程序員入職的第一件事或許就是弄清楚這些老“玩意”后進(jìn)行著修修補(bǔ)補(bǔ)的工作。
對(duì)此，原文作者提到，論文《Measuring Program Comprehension: A Large-Scale Field Study with Professionals》中指出了程序員在一個(gè)項(xiàng)目上的時(shí)間分配，其中約58%的時(shí)間來理解系統(tǒng)，并闡述這一數(shù)字是如何得來的。
即使在40年后的今天，花在摸索系統(tǒng)上的時(shí)間并沒有變少。盡管這是一個(gè)非常大的項(xiàng)目成本，但人們?cè)谌粘８嗟氖怯懻撊绾螛?gòu)建系統(tǒng)，而不是如何弄清楚一個(gè)系統(tǒng)。
閱讀只是從數(shù)據(jù)中收集信息的一種手段，也恰好可能是最手動(dòng)的方式，這就為優(yōu)化提供了重要的機(jī)會(huì)。
在做一件重要的事情之前，人們往往會(huì)進(jìn)行命名，否則就會(huì)像伏地魔一樣。在多年以前，把弄清楚系統(tǒng)然后再做下一步稱之為評(píng)估，并且還提出應(yīng)該圍繞評(píng)估來優(yōu)化開發(fā)。
通過閱讀來提取數(shù)據(jù)是最機(jī)械的一種方式，無法規(guī)?；?，還會(huì)帶來信息不完整和不確定性。在還未摸清系統(tǒng)全貌之前，決策不應(yīng)該建立在信念的基礎(chǔ)之上。數(shù)據(jù)科學(xué)告訴我們，應(yīng)該以問題為導(dǎo)向去匹配相應(yīng)的工具進(jìn)行推理。
軟件不是一座孤島，而是由無數(shù)關(guān)聯(lián)項(xiàng)組成，因此人們無法預(yù)測具體的問題，但可以預(yù)測出問題類別。樹立可塑開發(fā)思想，在摸清問題之后，構(gòu)建自定義工具流程，從而快速處理上下文中的重要內(nèi)容。在未來十年，人們無需通過閱讀源碼來衡量是否“弄清了系統(tǒng)”，取代它的應(yīng)該是解決實(shí)際的問題。
針對(duì)這個(gè)話題，HackerNews不少人都提到了結(jié)對(duì)編程，一位gleenn網(wǎng)友則提出了結(jié)對(duì)編程模式：人們往往會(huì)避免或者糾結(jié)結(jié)對(duì)編程，認(rèn)為結(jié)對(duì)編程所花費(fèi)的時(shí)間和成本是非結(jié)對(duì)的2倍，這完全是錯(cuò)誤的理解。
當(dāng)他在一個(gè)每天輪流做結(jié)對(duì)編程的地方工作時(shí)，在一個(gè)熟悉系統(tǒng)并能即時(shí)回答你提出的問題人面前寫代碼，一個(gè)新開發(fā)者的效率可以一飛沖天，比一個(gè)人做要快速好幾百萬倍。
ID為kayodelycaon的用戶表示，在一個(gè)100%進(jìn)行結(jié)對(duì)編程的地方工作，意味著無法結(jié)對(duì)的人就會(huì)被過濾，而能否進(jìn)行結(jié)對(duì)編程，與當(dāng)事人的方方面面都有著關(guān)系，比如自己有多動(dòng)癥、短期記憶方面的問題等。但自己卻能編寫出非常好的代碼，會(huì)考慮代碼的可讀性、算法復(fù)雜性、副作用、可測試性等多個(gè)小細(xì)節(jié)。