Current Location: Main Page / Books Reading / Main Content

构建之法 – 学习笔记

因为是自己边读边记录的，会有些乱

章节 1 概论

讨论了什么是软件工程，小项目跟公司级别的大项目的区别。各种工程化和管理化的方法。

纸飞机、莱特兄弟的飞机、波音747客机的飞机例子举的非常好，让人对大型软件项目有了更深的理解。

这些天我在调制SGLang的时候，也遇到了类似的问题。LLM Serving已经进入到了一个非常复杂的问题境界，如同当年Oracle和MS Server一样复杂，每个公司都需要特例化部署。而软件的复杂性让整个系统进入到频繁出bug/issue的阶段。

Serving因此需要特例化，因为工程复杂度会随着支持的config越多，而指数般地变的更复杂。在这个时代，M+N的编译器似乎越来越少，HPC里的MxN事情其实越来越多。

章节2 个人技术和流程

单元测试

软件作业

技术流程

性能分析的两种方法
image.png

image.png

怎么开发
image.png
image.png

image.png

章节3 软件工程师的成长

挺不错的章节。给大学生讲了公司里发生了什么，就像公司前辈。

image.png

image.png

过早的优化啥一切罪恶的根源

image.png

工程师在各个编写代码、需求分析、测试等软件过程方面，比大学生有所不同。工程师会更加的稳健。

大学可能可以分为两种。第一种是学生似乎很难超过老师，第二种是学生一定会超越老师。但我目前感觉这些还不明显，因为是概率叠加的事情。但是有些事情是不一样的。

研究一个问题5年，现在的AI似乎没有这样的耐心。这让我觉得难过，也让我怀疑。我们其实高估了自己并低估了AI。当然，两年后可能也不确定了。

image.png

工程师、学生、科研工作者的区别。

image.png

image.png
image.png
image.png

https://www.teamten.com/lawrence/writings/norris-numbers.html

image.png
https://news.cnblogs.com/n/509554/

第4章 两人合作

讨论了代码规范、审查、反馈。

using namespace std;

int main(){

int arr[4];

arr[0] = 1;
arr[2] = 2;

int b[4] = {4,3,2,3};

}

image.png

我个人认为反馈真的很重要。尤其是如何汇报负面的事件，这个点简直是生存技能。比如汇报为什么会这样，接下来怎么做。最可怕的点是，如果出现了负面事件，然后你还没有搞明白为什么会这样。这是最糟糕的。那此时会怎么办？

如果对方做了糟糕的事情，怎么评价？

行为和后果：你迟到了，我们错过了演出；请不要在用tab了喵
习惯和动机：你平时都这样，故意耍我；你这都第几次了？？
本质和固有属性：你是一个自私的人；你双非的学生水平真差！

问题是，是否自私、故意的真假不重要，重要的是目前手下的项目能不能推进。

两人结对的另一个重点是平等。这是一个有意思的观察。多人组队一定会出现一个队长，队长和组员天生的任务其实是有点不太一样的，甚至在吃饭时都会有所体现。哎，人类。

不好的习惯

深藏不露者：不告诉别人自己在做什么。

但是，这些是软件工程。更多的，在公司里也有人情世故。不过这方面中国和美国感觉不太一样就是。

第5章 团队和流程

团队模式

蜂窝模式：所有人都在抢球
主治医师：首席程序员编写代码，旁边有测试等
明星模式：其中一个人做了大部分的活
社区模式：大家一起做，但是有严格的代码复审和签入质量控制
业余剧团：平时大家平等，关键项目有导演
秘密团队：没有汇报，团队自由非常大
特工团队：一部分人专精棘手紧迫问题
交响乐团：门类齐全、有指挥、练习多次的曲目，出现在大型项目
Jazz：随性发挥
功能团：1-3人一个功能，完成需求
官僚主义：大头目、小头目。如果应用不好，就变成老板驱动

Conway Law：一个机构设计出来的系统，它的体系结构注定会沿用这个机构的内部交流模式

AI-人类，AI-AI 设计的系统，和人类-人类 系统肯定是不一样的。事实确实如此。而最可怕的是，AI会进化，人类也是。同时，“拯救AI coding过的项目”和“新的AI没看懂老AI的代码”这些问题也会涌现出来。人类的成长不是靠反向传播出来的。人类的文字和代码也会进化的。

开发流程
code and fix：狗屎开发方法
waterfall Model：Managing the Development of Large Software Systems，一步步开发
Rational Unified Process统一流程RUP，不同阶段做什么东西（类似甘特图
老板驱动流程：懂你意思
渐进交付流程：一点点功能实现，然后交付

第6章 敏捷流程

尽可能快的完成开发。这听起来是个废话，然而，很多团队并并没有按照他们预想的那样开发成功。

image.png

因为人本质上是人，人也有老婆孩子生活。有时候组员和mentor的目标才不是完成全部事情，而是早点下班。。。

image.png

image.png
Scrum

尽可能最快开发出来，用几个sprint

image.png
brooks说往错误的项目里加入人手，只会让整个项目更加落后。其实AI也是这样。当时我们加入AI的时候，AI把项目搞的越来越乱。事实是这似乎并非模型的问题，有很大一部分是软件工程项目管理的问题。

我们的开发也是这样，需求在简短的几个meeting中迅速解决了。不过与其说是迅速解决，最大的感谢应该给到AI，不然我们是不可能完成的。

我们可能会花80%的时间在仅仅20%的功能上，这部分功能将成为难点。其实仔细想想也合理。那么这里我们的项目安排就很重要。书里作者给了我们用“测试”为建议。但是，这也在告诉我们，其实很多时候，要做好功能的取舍。这需要经验。

我之前做科研时，一直认为hidden state很重要，后来跟别人讨论，发现hidden state更重要。hidden state是一种，维度很多，平均信息量没有最终层的信息多，但是总信息量大于最终层信息量。这些信息，目前AI还无法学会。比如大型项目管理，与人交流，在代码仓库里踩的坑，行业经验，人生经验，以及人的成长模式。

image.png

把我们的开发成果，展示出来，并且最重要的是，展示为什么某些地方慢。我在做研究时，有时候有的地方没能成功，当时，我会习惯的埋藏一些。但是事实是，很多时候，我们只是需要那个状态，“目前到哪里了”，对项目负责人来说，他们喜欢掌控全局。
image.png很重要。
image.png

测试在一个冲刺中，认为可以担负产品负责人的责任

TDD test driven development
XP 极限编程
FDD Feature Driven Design

为什么敏捷开发在后来才来？因为早期的软件项目都是航天等

Hawthorne效应，人对新东西还是喜欢的

18-24个月，是一个项目需求的生存周期，超过，基本可以不做了，因为需求早就变了。
真是短命啊

第7章 实战中的软件工程

真的，这章节讲的神了！如同在微软的工程师分享经验。

保持高质量是有意义的，方便后续的客户和需求扩张

投资是长期的，短平快的工作叫投机，不叫投资

不过，MSF没有提“质量第一”，而是认为解决用户问题第一

MSF工作机制

image.png
沟通很重要，并且不是文档的沟通，要完成信息的交流，而不是简单的文字说明。

信任与授权。这是我在公司里得到的最快乐的事情。

image.png

一个缺陷从发生到改进，平均实际位12小时，20道工序

事后回顾很重要，这意味着经验的累积和总结。在学习过去的经验时，也要避免让过去的经验妨碍解决现在的问题。在这里，开一个会是很重要的。

image.png
比如我在mem文章上的总结。最大的问题在于，我不知道怎么改进。这也是AI问题里最棘手的，跟系统研究比起来。

image.png

嘉豪：保罗在自己的PDP-10机器上编写了8080模拟器，并在上边完成了自己的解释器。随后，他们飞到了MITS公司，演示了自己的解释器。第一次运行自己的解释器时，测试完全正确。MITS公司从工程师们到总经理都惊呆了。保罗回忆道：我自己也非常惊喜，但是我做出了一副“这没啥了不起“的样子。

高强度学习，面对新的bug修复中学习：在开着消防水龙头喝水！

image.png

TFS：

关注文章的hidden state：怎么来的，怎么做的，除了文章文字以外，学到的知识。（关注软件的hidden state）

Cargo Cult：美军的飞机和土著的模仿；小项目团队和大项目的团队

管理学大师认为，我们应该在团队中要消除以数字定义的目标、份额，以及以类目标位基础的管理原则。我们要用管理原则取而代之。

我认为这句话，跟前些天meta的token使用排行可以做例子。纯粹的打榜，背后的hidden state是不知道的。

但是本章节的各种管理经验，对于没有工作经验的学生而言还是太难。单纯依靠书本并不能完全体会到这些经验。

第8章 需求分析

秋千图：类似梯度下降一样慢慢分析推导出需求。

AI-native：人类将有一个”电子副脑“，可以在脑机接口等工程下，实现真正的个人能力拓展。

面谈

人类学调查：在《社交网络》电影里，同学问主角：你知道女生C有没有男朋友？主角思考里一会，回去在自己的网站上实现了“你有朋友了吗”这一功能

image.png

image.png

《中国三线城市数字生活》

A/B测试

image.png

image.png

Need - Approach - Benefit - Competitors - Delivery
NABCD方法
这个blog讲的挺好的
https://www.cnblogs.com/liangzhilin/p/5462486.html

杀手功能 / 外围功能
必要需求/ 辅助需求

有一个4象限。有不同的战略。比如一个闹钟，能显示时间，那就是必要需求，能排版时间+AI规划，可能是杀手功能。我个人测试感觉这个4象限方法不是很好，经常很难快速区分各个需求。

估计项目复杂度和完成天数。

image.png

image.png

Y为实际天数，N为做过类似开发的次数

Y=X+- X/N

McConnell：软件估计的10宗罪
Quora：为什么软件开发周期总是预估的2-3倍

第9章 项目经理

软件项目的管理复杂度与人员数量的平方成正比（图论 nx(n-1)/2）
所以需要经理：带领团队，保持团队的平衡

这里MS把PM类似定义为博士生项目leader，负责日常的汇报，也会写一部分代码，做决议，做方案。从这里也可以思考phd的角色定位。

image.png

从这点上看，想起来大学时有同学说，我自己技术很差，所以我要去做管理。抛开大家服不服你不谈，不懂技术就去管理真的是一个很可怕的事情，大概率会带翻车团队。

image.png

自省能力，随时整理项目中自我的不足

别人布置任务或者我们部署任务的时候，一定要想清楚，这个事情是不是事实，以及我们要怎么应对：
image.png

大表哥的指挥，和项目经理是一样的吗？
image.png

不太一样，项目经理还要完成对上面和外面负责。这听起来真的好难啊

image.png

MP，SP
快速学习能力，分析管理，专业能力

开正确的会议。会议开始时大家可能心情是平静的，但是离去时大部分是失望、愤怒、不安的，这跟会议的目的、交流的内容都有关。理清事实

image.png

这让我想起我带团队的经历。我带时总会放一个错误：我自己属于HPC了解跟深的leader，而队友可能会年级低。此时很多工作我经常就自己包揽了，自己会过的更疲倦。

这其实是我个人的管理成长问题。人不能总是推脱。因为你总有一天会面对能力暂时不如你的人，然后带领一个团队走向更远。比如带新来的硕士生博士生做论文，你不能指望你每次招来的人都直接不用你指导，这样的话你应该在他手底下干活。还有就是lead一个个项目，这需要时间。
我必须面对这个问题。我目前已经完成了结对编程和合作。未来我需要在向这个方向改变。我会遇到越来越多同学的。

这也就是，追求过程创新。

image.png

image.png

典型用户场景

一定要找到动机

image.png

然后典型用户可能画像会不一样：

image.png

use case

用户故事模板

服务质量，长江三峡的例子。非常有互联网时代感！
这个跟设计文档Spec有关

风险管理。没有风险，就是最大的风险

乔布斯的分析：dwz.cn/1Iss5G

软件设计和实现

UML
控制流
形式化方法

封闭开发Leave me alone