博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
读《构建之法》阅读与思考
阅读量:6978 次
发布时间:2019-06-27

本文共 2140 字,大约阅读时间需要 7 分钟。

读《构建之法》思考与疑问

1、2与16章

第一章 概论

问题1、2和3

我看了

人类文明要向前发展, 离不开思考、 发现、 构建。 我曾经在微软亚洲研究院技术创新部工作过七年, 我所在的工程团队和很多计算机科学家在不同领域一起做项目……这是我在研究院之外的十余年中做得最多的项目类型, 也是这本书的英文名字。 希望读者看了这一节之后, 不再纠结“科学”和“工程”的问题, 在不同的学习与工作阶段, 投入到最适合的项目类型中去。

我的疑问是:想要从事理论研究一定要参与实践项目吗,我明白有实践带来的经验能一定程度上更好地研究,但是很多,毕竟理论研究是很困难的,如果再做项目,会不会没办法专注一个领域呢?

我查了资料发现,许多著名的计算机科学家一生都是为解决实际问题而驱动着进行思考和设计,如

Edsger Dijkstra ————来自维基百科

What is the shortest way to travel from Rotterdam to Groningen, in general: from given city to given city. It is the algorithm for the shortest path, which I designed in about twenty minutes. One morning I was shopping in Amsterdam with my young fiancée, and tired, we sat down on the café terrace to drink a cup of coffee and I was just thinking about whether I could do this, and I then designed the algorithm for the shortest path.

A year later, he came across another problem from hardware engineers working on the institute's next computer: minimize the amount of wire needed to connect the pins on the back panel of the machine.

……

那么,随之而来的是更多的困惑,因为我想从事与数学有关的理论工作,我平时应该关注什么实际问题,什么才是最适合理论研究的项目类型呢,已及,一般这些项目都由哪些机构负责呢?所以我认为理论到底应该和什么样的实践相结合是非常关键的。

第二章 个人技术和流程

问题1

看完这一章之后,我之前很多理所当然的想法得到了纠正,

如果我们不经分析就盲目优化,也许会事倍功半。

但因为书中许多的概念和方法都是第一次知道,很容易就会让“原来是这样”的心理掩盖对一切书本内容保持怀疑的态度。例如,

回归测试最好要自动化,因为这样就可以对于每一个构建快速运行所有回归测试,以保证尽早发现问题。单元测试是回归测试的基础。

在专注于模块基本功能的单元测试之外,还有功能测试—从用户的角度检查功能完成得怎么样。

初看只会觉得 “噢,原来有两种测试,单元测试是……回归测试是……”,而且我看完这一章有一种感觉,那就是在做项目的过程中,无论干什么之后都是先测试一下,一个小的修改在复杂的项目里都是牵一发而动全身,而且在PSP中一位SDE的花在上测试的时间也远比一位senior student要久,根据我查的资料,

还有 ”极限测试、集成测试、软体测试……" 等等,

回归测试带来的耗费占软件工程生命周期1/3总费用以上。

所以我认为提高测试的效率,以及精简测试的流程是很重要的,但是测试都是为了找出问题,否则不过是为测试而测试罢了,那么我认为呆板的测试流程虽然带来了规范,但也带来了浪费,不是最优的做法,现在是否有一种灵活的测试体系,针对不同的软件类型,不同的需求给出的测试流程呢?而不是统一的测试规范。

第十六章 IT行业的创新

在这一章的开头,列出了很多似是而非的 “创新的迷思”,这是确实提供了新的角度,其中有些我也比较赞同,但始终不能完全赞同。因为在我看来都只在做一件事,那就是否定绝对性(一……就……;……都……),这当然非常简单,因为绝对的大部分都是错的,而且反驳的方式也很简单,只要举出真实的反例就好了。而且提供了很多 “当创新已经/快要出现了,我们可以怎么办/走进小作坊” 的方法论。

但我认为,创新之所以难得,正是因为它的可能性和偶然性,定义什么是创新更困难,因为它无法在事前被定义,毕竟在创新成功之前,没有人能断言这是创新还是空想,很多定义都是:……获得了……/……颠覆了……,这些都是完成时。

所以创新的世界观应该比方法论更重要,毕竟方法只能提供一种可能性,而世界观里有更多可能,而且创新并不是为了创新本身,而是为了改变,所以,关注什么应该被改变,或许是另一种思考。

转载于:https://www.cnblogs.com/librarian1/p/8575868.html

你可能感兴趣的文章
39个超实用jQuery实例应用特效
查看>>
CI报Disallowed Key Characters的解决
查看>>
关于手机已处理里重复单据的处理办法
查看>>
IIS 7.5 + FastCGI + PHP + Drupal 7 + Oracle
查看>>
我的友情链接
查看>>
英文版PDF不能显示中文PDF文件的解决方法
查看>>
linux 内核 出错-HP 方案
查看>>
Linux
查看>>
HashSet的使用
查看>>
WSFC 仲裁模型选择
查看>>
nginx安装 问题 1
查看>>
MST配置详解
查看>>
linux下用phpize给PHP动态添加扩展
查看>>
任意排列、组合终极Shell脚本
查看>>
★核心关注点_《信息系统项目管理师考试考点分析与真题详解》
查看>>
Go处理百万每分钟的请求
查看>>
你以为自己在填验证码,其实你是在给Google义务劳动
查看>>
linux实战考试题:批量创建用户和密码(不能使用循环)
查看>>
一个基于J2EE的web应用程序运行起来需要什么?
查看>>
Docker配置指南系列(二):指令集(二)
查看>>