作者 | feenk 整理 | 夢依丹
面對冷冰冰的機器、代碼、工具，程式員的首要工作是知其然并知其是以然，方能入手去敲打出美妙的代碼。
近日，一篇《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》得到了驗證。
那有沒有什麼其它更高效的方式呢？程式員為什麼要閱讀源碼呢？其實對于程式員來說，如果隻知其然而不知是以然，是很難進行下一步的代碼搭建，是以摸清系統，最主要的是為了做出更好的程式設計決策。
閱讀隻是從資料中收集資訊的一種手段，也恰好可能是最手動的方式，這就為優化提供了重要的機會。
在做一件重要的事情之前，人們往往會進行命名，否則就會像伏地魔一樣。在多年以前，把弄清楚系統然後再做下一步稱之為評估，并且還提出應該圍繞評估來優化開發。
通過閱讀來提取資料是最機械的一種方式，無法規模化，還會帶來資訊不完整和不确定性。在還未摸清系統全貌之前，決策不應該建立在信念的基礎之上。資料科學告訴我們，應該以問題為導向去比對相應的工具進行推理。
軟體不是一座孤島，而是由無數關聯項組成，是以人們無法預測具體的問題，但可以預測出問題類别。樹立可塑開發思想，在摸清問題之後，建構自定義工具流程，進而快速處理上下文中的重要内容。在未來十年，人們無需通過閱讀源碼來衡量是否“弄清了系統”，取代它的應該是解決實際的問題。