程序员之与代码，就好比鱼离不开水，但你知道吗？程序员每天花在写代码上的时间却不是最多的。
近日，一篇《Developersspendmostoftheirtimefiguringthesystemout》的文章在HacekerNews上引起了不少开发者的共鸣，作者表示，程序员大部分时间都在摸索系统之上，而非构建系统。
对于这一话题，最早可追溯到年Zelkowitz、Shaw和Gannon出版的《软件工程和设计原理》一书，书中描述到，程序员把大部分的时间（67%）都花在了开发维护上。
诚然，这本书并没有告知这一数字是如何获得的，那么在40年后的今天，又是怎样的情形呢？
知名程序员，MegaEaseCEO左耳朵耗子（陈皓）在演讲中提到，在国内没有一家软件公司有升级部门，经常是老到20年的系统依然在使用。可想而知，对于这样的系统，程序员入职后的第一件事或许就是弄清楚这些老“玩意”后进行着修修补补地工作。
对此，原文作者提到，在一篇《MeasuringProgramComprehension:ALarge-ScaleFieldStudywithProfessionals》的论文中指出程序员在一个项目上的时间分配，其中约58%的时间来理解系统，并阐述这一数字是如何得来的。
由上图可以得知，即使在40年后的今天，花在摸索系统上的时间并没有变少。尽管这是一个非常大的项目成本，但人们在日常更多地是讨论如何构建系统，而不是如何弄清楚一个系统。
那么开发者是如何搞清楚系统的呢？开发者更多是通过阅读代码来摸清系统的架构与分支，这一结论也在《MeasuringProgramComprehension》得到了验证，理解力基本都是用阅读来衡量。
那有没有什么其它更高效的方式呢？程序员为什么要阅读源码呢？其实对于程序员来说，如果只知其然而不知所以然，是很难进行下一步的代码搭建，因此摸清系统，最主要的是为了做出更好地编程决策。
从上图角度来看，阅读只是从数据中收集信息的一种手段，也恰好可能是最手动的方式，所以这就为优化提供了重要的机会。
在做一件重要的事情之前，人们往往会进行命名，否则就会像伏地魔一样。在多年以前，把弄清楚系统然后再做下一步称之为评估，并且还提出应该围绕评估来优化开发。
通过阅读来提取数据是最机械的一种方式，无法规模化，还会带来信息不完整和不确定性。在还未摸清系统全貌之前，决策不应该建立在信念的基础之上。数据科学告诉我们，应该以问题为导向去匹配相应地工具进行推理。
软件不是一座孤岛，而是由无数关联项组成，因此人们无法预测具体的问题，但可以预测出问题类别。树立可塑开发思想，在摸清问题之后，构建自定义工具流程，从而快速处理上下文中的重要内容。在未来十年，人们无需通过阅读来衡量“弄清系统”，取代它的应该是解决实际问题所花费的精力。
针对这个话题，不少人提到了结对编程，一位gleenn网友表示，人们往往会避免或者纠结结对编程，认为结对编程所花费的时间和成本是非结对的2倍，这完全是错误的理解。当他在一个每天轮流做结对编程的地方工作时，在一个熟悉系统并能即时回答你提出的问题人面前写代码，一个新开发者的效率可以一飞冲天，比一个人做要快速好几百万倍。
ID为kayodelycaon的用户表示，在一个%进行结对编程的地方工作，意味着无法结对的人就会被过滤，而能否进行结对编程，与当事人的方方面面都有着关系，比如自己有多动症、短期记忆方面的问题等。但自己却能编写出非常好的代码，会考虑代码的可读性、算法复杂性、副作用、可测试性等多个小细节。
总结
在成本时间的花费上，程序员之间也存在着不小的差距。高级程序员之所以工作效率高，与其拥有扎实的基础和更高效的工作方式有着直接的关系。
提升编程能力永远是一名技术工作者的“主旋律”，不仅要在工作之中学会主动发现问题、解决问题，更要在工作之余拓展学习，提升竞争力。
往期推荐
●
“狗系”同事最迷人？测测你是哪种职场动物
●
盘点程序员那些一看就暴露职业的行为
●
程序员的愚人节正确打开方式
预览时标签不可点收录于话题#个上一篇下一篇