写点什么

读《Software Engineering at Google》(07)

作者:术子米德
  • 2022 年 4 月 16 日
  • 本文字数:1242 字

    阅读完需:约 4 分钟

🤔☕️🤔☕️🤔

  • 读《Software Engineering at Google》(07)—— Measuring Engineering Productivity

  • 📖:@Google,搭建一支队伍,有软件工程研究领域的人、有技多不压身的软件工程师、有认知心理学家、有行为经济学家,专门研究和理解所谓的工程生产力。

    🤔:度量工程生产力,按时完工,算是其中一个维度嘛?在建筑类工程,在桥梁类工程,在基础设施类工程,说几个月、说几年,那基本上都是大差不差。可是在软件行业,在 IT 行业,预估几个月就完成,如果真按期完成,甚至提前完成,得到的可能不是喝彩,反而可能是疑惑。这件事情好罕见,莫非故意把工作量估少,再看一眼产物,还真不少,真是稀奇罕见。当然,还有一种按时交付,那就是死命催赶,交付时还带着点不屑,就这么点活还要干这么久至于嘛。为何在其它类工程,按时交付是如此可预期,在 IT 软件类工程,按时交付确实稀奇事。有点模糊的思路和想法。软件要边思考边生产,而其它类工程,一般都是思考和生产分离,即软件是脑和手一起动,而其它却是先动脑、再动手。那软件外包,算不算已经达到脑和手的分离,有点这个意思。也就是说,脑和手一起的软件工程,更可能是工程化的成熟度不够导致。如果老天再给软件行业五十年,是否都会进入脑手分离的工程模式。到那时候如果还在边思考边敲代码,就是在家里自己玩耍,不太可能是在规模型工程,会是如此嘛?不过脑手分离,是否也有必要条件,那就是最终手要做的部分,提前在脑思考阶段就有完整的信息和确定性。而实际上,需要编程解决的问题,并非都能满足这样的条件。这是否会让脑手不分离成为软件的宿命,也让软件工程的工期成为永远的不稳定性。

    🤔:从谷歌搭建队伍的组成来看,这的确是个难题,我那点粗浅的想法,真的就是点想法而已。这么多专家和高手,居然以“可读性(readability)”作为度量工程生产力的抓手,着实让我感到意外。不过回头想,软件工程里,最具有展现力的代表,可不就是代码,代码携带着解决问题的具体方法,代码更是兼具人和机器都能读懂,重点还是在于人能读。也就是说,代码的可读性,同时能代表工程的产量和品质,即所谓的生产力。

  • 📖:GSM(Goal/Signal/Metric),先定目标(Goal),目标要好,再定信号(Signal),信号要明确,表示目标达成的信号,最后再考虑衡量(Metric)。先别考虑怎么验收,能够避免灯下黑。

    🤔:我要做个东西,估计吧,做成那样就算成了,然后咱们再看看,这么成了算不算好。这不是自己做好,然后夸自己好嘛。的确有这个嫌疑。可是,如果我一开始就知道怎么衡量,似乎是个确定的好事。实际上,这是一个认知上的短视。我现在就知道怎么衡量,一个致命的问题在于,未来的东西,在我现在的知识框架内。也就是所谓在路灯下找钥匙,我只会在路灯光线范围内找。可是,没人告诉我,钥匙到底在哪里,而我却用现有的认知认为它在我看得到的光线范围内。做好再说好不好,固然有它的缺陷。但是作为能在黑暗中找到钥匙,跟在路灯下找不到钥匙相比,必须选择勇敢跨入黑暗,去点亮后再看情况到底如何。

    —— By 术子米德 @2022.04.15

发布于: 刚刚阅读数: 2
用户头像

术子米德

关注

遇见每天的自己,莫忘初心,莫丢念头 2020.03.05 加入

喜欢有的没的,喜欢自言自语式笔记

评论

发布
暂无评论
读《Software Engineering at Google》(07)_架构师成长笔记_术子米德_InfoQ写作平台