作者 | 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最新版)
2.勁爆！Java 協程要來了，，，
3.Spring Boot 2.x 教程，太全了！
4.別再寫滿屏的爆爆爆炸類了，試試裝飾器模式，這才是優雅的方式！！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/495525.html
標籤：其他
上一篇：java繼承簡介說明