Shengnan的《构建之法》读书笔记

大家好，我是Shengnan，来自西安交通大学自动化专业，正在读大四。目前感觉自己是一个刚转行的技术萌新，希望在MSRA实习的一年里逐渐入门，为读博士打一个好的基础。

由于最近回学校事情比较多，知识抽空大概浏览了《构建之法》这本书，整体的感觉是，这本书能用一些生动的例子去解释一些概念或者技术，即使我这种技术小白读起来也不会觉得枯燥。在读的过程中，我记下了一些比较有意思的点和一些疑问，暂时就先一股脑地列在这里，之后假如有时间再系统的整理一下。

 

疑问：

全局问题：书中讲的内容感觉更偏向工程一些，但是如果是做research的话，有些环节（比如繁重的测试任务）是否可以在实际操作中精简一下？

P92：“主治医师模式”似乎会逐渐变成“抱大腿模式”（就像在学校做小组作业一样）。要如何避免出现“大腿”承担所有工作而其他人只在一旁喊“666”呢？

P105：MVP可以用来征集用户意见，但假如MVP的反馈很差，是否意味着这款产品没有做下去的必要了？

P145：微软提倡Learning By Doing，这确实是上手工作的最好方式。但是，是否会存在“揠苗助长”的问题呢？

P160：谷歌团队争论41中蓝色哪种更好，看上去很荒唐，但到底是什么引发了这种荒唐事？该如何避免？

P185：书中说PM要负责管理项目进度，可是PM该如何管理？

P256：那个学者师承关系树，似乎关心的问题不是“用户会每天都来看这个动画么？”，而是“用户在搜索时会来看这个动画么？”似乎仅仅当做微软学术搜索的小彩蛋，还是挺能吸引人的？（比如谷歌浏览器在没网的时候可以玩的那个小恐龙）

P339：“扁鹊三兄弟”的问题怎么解决？似乎功劳与“锅”分配不均是一个团队内很大的不稳定因素。

P345：让人喜欢的创新是与现有系统兼容的，但是很多好的创新之所以好，不正是因为其颠覆性么？

P359：AI技术是否已进入高科技炒作的迷茫期？

 

个人想法：

P66：用abCd的形式命名变量很有用，但是个人更习惯ab_cd的形式。

P87：“三明治”式的反馈确实更容易让人接受，但假如两个人已经很熟了，也许直接提问题能加快沟通效率。

P128：在不确定沟通效率和沟通范围时，宁可过分沟通，也不要省略沟通。

P141：在执行任务时，全局任务为核心，可以暂时放弃额外的诱人目标。

P155：“秋千图”感觉是全书最真实的图了orz解决这个问题，我认为关键在于有一个思维清晰的全局规划者（比如组里的大老板）。

P165：似乎强调“杀手功能”和新木桶原理的长板效应很类似。

P194：会议结果得到行动后，一定要强调行动的负责人。

P235：在实现整体功能前，局部的小bug是可以容忍的。并且不要过早的优化。

P243：“新员工上手问题”真的很有实际意义。

P250：谷歌的搜索界面感觉很干净，用户体验就很好（对本人用户而言）。但是hao123感觉就很凌乱，体验很差。

P260：有时候，用户体验比产品质量更重要，就像论文里的可视化有时候比数据结论更重要。

P341：灵光的出现需要有两个基础：前人工作的基础与自身积累的基础。

P348：外行人之所以能发现内行忽略的创新点，大概就是因为“只因身在此山中”吧。对住在南方的同学来说，再普通的一片雪花，也能激起极大的探索热情。