* update  ch1

* update ch2

* update

* update ch3

* add design
This commit is contained in:
xiaowuhu 2023-10-12 18:16:57 +08:00 коммит произвёл GitHub
Родитель 0855862c7e
Коммит 5a0e5cfabe
Не найден ключ, соответствующий данной подписи
Идентификатор ключа GPG: 4AEE18F83AFDEB23
517 изменённых файлов: 2577 добавлений и 835 удалений

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 52 KiB

После

Ширина:  |  Высота:  |  Размер: 52 KiB

Просмотреть файл

@ -15,23 +15,24 @@
这些正面的反馈,让笔者产生了自己写一本软件工程书籍的想法。
## 2. 写作经过
于是构思后动笔,先写的是第四步中的“用户与需求”中的第 6、7、8 等三章。后来发生了一件事令写作进度一度停止。偶然的机会认识了某出版社的一位编辑,就把这三章的草稿发给该编辑预览,几天之后得到的反馈是:“这本书没有很大的技术含量,不具备在我社出版的条件”。这令笔者很受打击:还在襁褓中的书稿就得到了负面的评价。
笔者静下心来仔细分析了一下:
1. 先写“用户与需求”部分,是因为笔者亲身经历或目睹过很多软件项目,在没有很明确的用户需求的前提下就盲目上马,违背了软件工程需求当先的基本规律,最后跌落马下。所以,笔者认为这一部分非常重要,而且是大多数传统的软件工程书籍中没有提及的。
2. 软件工程知识其实并不是主要讲技术,而是讲理念与流程。从本书的第一章中,读者可以知道与软件工程的相关学科数量是多么的庞大,那并非哗众取宠,而是实实在在的知识体系。就拿敏捷开发举例,它并没有讲什么技术,而是实践。
3. 在没有看到其它章节的内容甚至标题之前,这位编辑就反馈说“没有技术含量”,并且声明是“经过专家审阅的”,这令笔者很疑惑。
1. 先写“用户与需求”部分,是因为笔者亲身经历或目睹过很多软件项目,在没有很明确的用户需求的前提下就盲目上马,违背了软件工程需求当先的基本规律,最后跌落马下。所以,笔者认为这一部分非常重要,而且是大多数传统的软件工程书籍中没有提及的。
2. 软件工程知识其实并不是主要讲技术,而是讲理念与流程。从本书的第一章中,读者可以知道与软件工程的相关学科数量是多么的庞大,那并非哗众取宠,而是实实在在的知识体系。就拿敏捷开发举例,它并没有讲什么技术,而是实践。
3. 在没有看到其它章节的内容甚至标题之前,这位编辑就反馈说“没有技术含量”,并且声明是“经过专家审阅的”,这令笔者很疑惑。
虽然认为这是那位编辑的一种误判,但是笔者的自信心也受到了一点点打击。而且,对于将要动笔的“设计与实现”部分,还没有什么很好的写作思路,所以就暂时搁置下来,转身去写强化学习书籍的草稿了。
过了大概一年的时间,微软(中国)市场部门的一位朋友韦青先生,请笔者给一个合资公司的员工讲课,话题是“微软的软件工程师文化”。笔者犹豫了一下,但还是答应了。因为这个话题给了笔者一些启示:
1. 既然软件工程不是纯粹讲技术的,那么它可以讲文化呀!
2. 什么是软件工程师文化呢?在微软这个全世界最大的软件工场里工作,它的内部文化、工作流程等等,当然就是软件工程师文化的一个代表,对于行业内的从业人员来说是极具参考价值的。
3. 当初的课件只是给 MSRA 创新班的两届学生(不到 60 人)讲过,不够“本儿”,应该拿出来和更多的人分享。
1. 既然软件工程不是纯粹讲技术的,那么它可以讲文化呀!
2. 什么是软件工程师文化呢?在微软这个全世界最大的软件工场里工作,它的内部文化、工作流程等等,当然就是软件工程师文化的一个代表,对于行业内的从业人员来说是极具参考价值的。
3. 当初的课件只是给 MSRA 创新班的两届学生(不到 60 人)讲过,不够“本儿”,应该拿出来和更多的人分享。
于是,笔者整理了一下以前的课件的 PPT增加了一些内容就去讲了两个小时得到了很好的反馈。紧接着微软中国研发部门的一位朋友李烨女士负责 ATPAI Talent Program培训项目请笔者讲同样的话题但是这次是网络直播。原本预定 40 分钟的直播课程,笔者足足讲了两个小时,受到了热烈欢迎,创下了 ATP 直播课程历史上的最高点赞数量4 万多点赞)记录。这件事给笔者以极大的动力来继续完成本书的写作。在此特别感谢韦青先生与李烨女士。
@ -45,6 +46,7 @@
在此要感谢提供文章、论文的原作者们(按小节顺序):复旦大学 CodeWisdom 软件工程研究团队、彭鑫教授、微软亚洲研究院 DKI 组、王韵研究员、高彦杰研发工程师、昝道广研究员、陈蓓研究员。当然还有微软亚洲研究院的张冬梅大姐以及张海东、楼建光、韩石、林庆维等老师的支持。
## 3. 写作体会
纵观那些当作大学教材的传统的软件工程书籍,大概有几种情况:
@ -71,7 +73,7 @@
如下图所示。
<img src="img/Slide2.SVG" height=300/>
<img src="img/Slide2.SVG">
1. 《构建之法》是一个倒三角形,更多地侧重在上面的部分(道、法)。
2. 《代码中的软件工程》是一个正三角形,更多地侧重在下面的部分(器、术)。
@ -157,3 +159,6 @@
|VSCode|产品名称|Visual Studio Code软件开发工具|
|Web|专有名词|互联网、网页、页面服务器的统称|
|Windows|产品名称|微软视窗操作系统|

Просмотреть файл

@ -1,7 +1,7 @@
## 第一章 基本概念
本章从一个软件工程的故事开始,木头带领大家一起初步领略了软件工程的复杂性。然后讲解了软件工程的基本概念及其相关领域学科。最后介绍了微软公司内的软件工程团队体系。
本章从一个软件工程的故事开始,木头带领大家一起初步领略了软件工程的复杂性。然后讲解了软件工程的基本概念及其相关领域学科。最后介绍了标准的软件工程团队体系。
<img src="img/Slide1.SVG" height=300/>

Просмотреть файл

@ -1,8 +1,6 @@
## 1.1 软件工程的故事
“木头”是一名软件工程师,给自己起了一个网名叫“木头”,为人也是有些木讷,在本书中,“木头”同学将成为所有故事的主角。
该故事的原始情节来源于《构建之法》但是有所修改。
该故事的原始情节来源于《构建之法》$^{[1]}$ 但是有所修改。
木头有个朋友是小学数学老师,在一次聚会闲聊中,这位老师询问能不能用当今热门的 AI 来辅助教育。平时不爱说话的木头一听就来了精气神儿,这个是自己的专业呀!木头借着酒劲儿吹了个牛:“如果是小学数学题的话,根本不需要什么 AI用个小程序就可以解决了。”
@ -17,7 +15,6 @@
### 1.1.1 麻烦一:如何运行
木头把 C# 代码传给了朋友,没想到朋友问了一个很初级的问题:如何运行这个程序?
这对于木头来说,就好比问每天如何刷牙洗脸,但是对于朋友(客户)来说,就需要以下步骤来实现运行程序的目标:
1确认操作系统是不是 Windows 10如果不是需要升级
@ -28,14 +25,16 @@
于是木头又用 Python 实现了那个小程序,然后告诉朋友如何安装 Python 库,如何运行 Python 程序......,反正是花在沟通上的时间比编写程序的时间多很多倍!但是,当朋友磕磕绊绊地运行了程序,得到了第一批 30 道算术题时,双方都认为付出是值得的!
### 1.1.2 麻烦二:如何发布
可是接下来朋友的问题又让木头傻眼了:如何把程序运行的结果发布给学生呢?总不能让学生都安装 Python 后来运行代码吧?这是小学数学课,不是大学计算机课。如果想依赖家长完成安装同样不靠谱,家长的水平也是参差不齐的。
想来想去,想到了微信小程序!于是木头又花了一周的时间学习了如何制作微信小程序,完全是 Mobile 客户端的开发模式很多概念需要熟悉还要熟悉框架、组件、API 等,好多坑要踩!
想来想去,想到了微信小程序!于是木头又花了一周的时间学习了如何制作微信小程序,完全是 Mobile 客户端的开发模式很多概念需要熟悉还要熟悉框架、组件、API 等,好多坑要踩!
一周后,当小程序出现在朋友的手机上时,双方又都觉得付出是值得的!!
### 1.1.3 麻烦三:如何使用
小程序发布给学生家长并运行一周后,老师受不了了:家长们把作业结果截屏后都发送给了老师,让老师判作业。但是,有一个问题没有想到:木头使用了随机种子算法,所以每个同学得到的算术题都不一样,答案自然就不一样。如果全部 50 个学生,相当于老师要自己每天做 $50 \times 20=1000$ 道算数题,基本就没时间干别的了,而且还遭到了校长的批评:某某老师上班时间不工作总看微信!(其实是老师在判作业)

Просмотреть файл

@ -8,7 +8,7 @@
软件工程的完整定义是:
**科学技术知识、方法和经验在软件设计、实施、测试和文档编制中的系统应用,在实施过程中,把系统化、规范化、量化的方法应用在开发、运行、维护中。如果说以上都是手段的话,那么软件工程最终想达到的目的是:建立和使用合理的工程原理,以便经济地开发出可靠的软件,并在真实机器上高效地运行。$^{[1]}$**
**科学技术知识、方法和经验在软件设计、实施、测试和文档编制中的系统应用,在实施过程中,把系统化、规范化、量化的方法应用在开发、运行、维护中。如果说以上都是手段的话,那么软件工程最终想达到的目的是:建立和使用合理的工程原理,以便经济地开发出可靠的软件,并在真实机器上高效地运行。$^{[2]}$**
### 1.3.2 特性
@ -116,7 +116,7 @@
我们用一张表简单地说明一下软件工程简史,见表 1-1。
表 1-1 软件工程简史$^{[2]}$
表 1-1 软件工程简史$^{[3]}$
|年代|关键词|事件|
|---|---|---|
@ -132,7 +132,7 @@
发展了 20 多年后,随着项目的大型化和复杂化,软件工程逐渐出现了危机。超出预算是最主要的经济问题,而由于软件的不稳定造成的财产损失甚至带来生命危险(如航空航天领域)则更加严重。于是,人们逐步从关注生产力(快速地发布软件)过渡到更多地关注软件质量,并达成了共识:只有到达质量标准的软件才算作真正的软件产品。
《没有银弹软件工程的本质性与附属性工作》原英文名称No Silver Bullet—Essence and Accidents of Software Engineering是 IBM 大型机之父佛瑞德·布鲁克斯所发表一篇关于软件工程的经典论文原先是在1986年都柏林IFIP研讨会的一篇受邀论文隔年电机电子工程师学会《Computer》也转载了这篇文章他们用了几张《伦敦狼人》之类的电影剧照来当作说明还加上了一段“终结狼人”的附注因为传说要消灭狼人只能用银质的子弹。
《没有银弹软件工程的本质性与附属性工作》原英文名称No Silver Bullet—Essence and Accidents of Software Engineering是 IBM 大型机之父佛瑞德·布鲁克斯所发表一篇关于软件工程的经典论文原先是在1986年都柏林IFIP研讨会的一篇受邀论文隔年电机电子工程师学会《Computer》期刊也转载了这篇文章,他们用了几张《伦敦狼人》之类的电影剧照来当作说明,还加上了一段“终结狼人”的附注,因为传说要消灭狼人只能用银质的子弹。
银弹是人们试图解决软件危机的方法但是最终大家发现根本没有银弹只能逐步地从局部改进软件工程中的各种问题形成严谨的工作流程。到此软件产品还是以传统的产品生态图1-3为主。

Просмотреть файл

@ -3,7 +3,7 @@
### 1.4.1 软件工程与计算机科学
我们先看一下计算机科学所涵盖的学科$^{[3]}$
我们先看一下计算机科学所涵盖的学科$^{[4]}$
- 理论计算科学Theoretical computer science
- 理论计算Theory of computation
@ -37,7 +37,7 @@
“程序猿”和“攻城狮”是业界对于程序员和工程师的昵称,笔者认为它们并非贬义词,而是很形象地说明了这种职业的特点:力大无穷(知识的力量),攻城拔寨(解决各种软硬件问题),勇往直前。
表 1-2 计算机科学与软件工程的比较
表 1-2 计算机科学与软件工程的比较
||计算机科学|软件工程|
|---|---|---|
@ -48,8 +48,7 @@
|策略|效果影响力优先|成本与效果的折中|
|成果|论文|项目、产品|
表 1-2 展示了二者的区别。简单地说,计算机科学是科学家、研究员们发现规律、研究理论,并试图从根本上把规律理论化、公式化,不太在意成本,只在意效果。在图 1-5 中展示了计算机科学与软件工程之间的衔接关系。
表 1-2 展示了二者的区别。简单地说,计算机科学是科学家、研究员们发现规律、研究理论,并试图从根本上把规律理论化、公式化,不太在意成本,只在意效果。而软件工程即在意效果也在意成本,是把理论高效实现的过程。在图 1-5 中展示了计算机科学与软件工程之间的衔接关系。
<img src="img/Slide7.SVG" height=300/>
@ -59,7 +58,7 @@
### 1.4.2 领域知识
在软件工程领域知识Software Engineering Body of KnowledgeSWEBOK$^{[4]}$ V3.0 版本中描述了软件工程的领域知识。
在软件工程领域知识Software Engineering Body of KnowledgeSWEBOK$^{[5]}$ V3.0 版本中描述了软件工程的领域知识。
我们在这一节中并不展开讲解只是罗列一下知识领域Knowledge Area让大家可以粗略地认识到软件工程的复杂性便于做好学习本书的充分准备。具体细节会渗透在后面的每一章节中。

Просмотреть файл

@ -105,7 +105,7 @@ $$
#### 1. 产品
我们以微软为例产品包括Windows、Office、Visual Studio 等,以客户端软件为主。其特点是由微软决定要做什么,给客户提供什么,具有长期规划,不断迭代。比如,微软认为 Windows 要提供给所有使用台式机的用户Office 要提供给白领办公人群Visual Studio 只提供给开发人员。每次更新,都是在现有基础上增加一些小的功能;而大版本号的更新则是提供了原有框架之外的功能,比如 Visual Studio 2019 提供了与微软云集成的众多功能,而这些功能在上一个大版本中并不存在。这些产品都是由微软内部专门的团队负责的,通常在 500~5000 人左右。
我们以微软为例产品包括Windows、Office、Visual Studio 等,以客户端软件为主。其特点是由微软决定要做什么,给客户提供什么,具有长期规划,不断迭代。比如,微软认为 Windows 要提供给所有使用台式机的用户Office 要提供给白领办公人群Visual Studio 只提供给开发人员。每次更新,都是在现有基础上增加一些小的功能;而大版本号的更新则是提供了原有框架之外的功能,比如 Visual Studio 2019 提供了与微软云集成的众多功能,而这些功能在上一个大版本中并不存在。这些产品都是由微软内部专门的团队负责的,通常在 500~5000 人左右。
#### 2. 项目
@ -119,7 +119,7 @@ $$
服务包括必应搜索、云平台Azure Cloud Platform后文简称为 Azure、办公套件Office 365后文简称为 Office等等以云端服务为主具有战略意义。当然要是把服务看作是存在于云端的产品也是可以的。
这种服务的后台通常有超级复杂的架构体系支撑在性能、可用性、可靠性上下足了功夫高并发大容量。由于处于云端没有客户端的升级压力所以一般更新比较快没有需要让用户知晓的版本号其内部还是有版本控制的。在微软内部通常由上千人的团队负责开发和维护。在美国要与谷歌Google搜索、亚马逊Amazon云竞争在中国要与百度搜索、阿里云竞争。
这种服务的后台通常有超级复杂的架构体系支撑,在性能、可用性、可靠性上下足了功夫,高并发大容量。由于处于云端,没有客户端的升级压力,所以云端服务一般更新比较快,没有需要让用户知晓的版本号(其内部还是有版本控制的)。在微软内部通常由上千人的团队负责开发和维护。在美国,Bing 要与谷歌Google搜索、亚马逊Amazon云竞争在中国Bing 要与百度搜索、阿里云竞争。
还有一种规模较小的服务,比如买一个家用的监控摄像头,厂家可以提供云端存储,可以存储 14 天的录像,而摄像头内置的存储卡只能存储两天的录像。这种云端存储可以当作增值服务卖给摄像头用户。
@ -129,6 +129,6 @@ $$
但是对于另外一种论调,即“软件工程独立于计算机科学之外”,是因为近些年软件工程发展非常快,处于不确定性,要学习的知识和技能非常多,而计算机科学的理论基础成熟稳定,研究方向相对固定。
在微软亚洲研究院,最开始建立时都是科学家和研究员;而在微软亚洲软件技术中心,都是工程师和程序员。从组织结构上就可以看出两种学科的“并列”关系。但是到了后来,微软亚洲研究院里也会有 10% 左右的工程师叫做软件研发工程师Research Software Development EngineerRSDE而微软亚洲软件技术中心里也有会 2% 以下的数据科学家Data Scientist实际上和研究员类似也会发表论文但更偏重为本组的工程项目服务。
在微软亚洲研究院,最开始建立时都是科学家和研究员组成;而在微软亚洲软件技术中心,都是工程师和程序员。从组织结构上就可以看出两种学科的“并列”关系。但是到了后来,微软亚洲研究院里也会有 10% 左右的工程师叫做软件研发工程师Research Software Development EngineerRSDE而微软亚洲软件技术中心里也有会 2% 以下的数据科学家Data Scientist实际上和研究员类似也会发表论文但更偏重为本组的工程项目服务。
无论哪个研究院,都会为企业的商业目标服务。如微软亚洲研究院,强调研究成果的产品转化率越高越好,被称为“黑科技”,实际上就是计算机科学与软件工程结合的产物。可以看到软件工程确实属于计算机科学的一部分,是架设在天(理论研究)与地(应用实践)之间的桥梁。
无论哪个研究院,都会为企业的商业目标服务。如微软亚洲研究院,强调研究成果的产品转化率越高越好,这些产品被称为“黑科技”,实际上就是计算机科学与软件工程结合的产物。可以看到软件工程确实属于计算机科学的一部分,是架设在天(理论研究)与地(应用实践)之间的桥梁。

Просмотреть файл

@ -10,7 +10,8 @@
### 参考资料
[1]《软件工程概论》,卫红春 等,清华大学出版社
[2] 软件工程历史Wikipediahttps://en.wikipedia.org/wiki/History_of_software_engineering
[3] 计算机科学Wikipediahttps://en.wikipedia.org/wiki/Computer_science
[4] 软件工程 body of knowledgehttps://ieeecs-media.computer.org/media/education/swebok/swebok-v3.pdf
[1]《构建之法》,邹欣,人民邮电出版社
[2]《软件工程概论》,卫红春 等,清华大学出版社
[3] 软件工程历史Wikipediahttps://en.wikipedia.org/wiki/History_of_software_engineering
[4] 计算机科学Wikipediahttps://en.wikipedia.org/wiki/Computer_science
[5] 软件工程知识体系SWEBOKsoftware body of knowledgehttps://ieeecs-media.computer.org/media/education/swebok/swebok-v3.pdf

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 55 KiB

После

Ширина:  |  Высота:  |  Размер: 55 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 85 KiB

После

Ширина:  |  Высота:  |  Размер: 85 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 58 KiB

После

Ширина:  |  Высота:  |  Размер: 58 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 42 KiB

После

Ширина:  |  Высота:  |  Размер: 42 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 71 KiB

После

Ширина:  |  Высота:  |  Размер: 71 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 253 KiB

После

Ширина:  |  Высота:  |  Размер: 253 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 66 KiB

После

Ширина:  |  Высота:  |  Размер: 66 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 224 KiB

После

Ширина:  |  Высота:  |  Размер: 224 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 77 KiB

После

Ширина:  |  Высота:  |  Размер: 77 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 96 KiB

После

Ширина:  |  Высота:  |  Размер: 96 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 393 KiB

После

Ширина:  |  Высота:  |  Размер: 393 KiB

Просмотреть файл

@ -1,6 +1,7 @@
# 第二步 个人与职业
---
在第二步中包括两章:专业能力,认知能力。其中,专业能力能够让一个软件开发者找到工作并保住饭碗;认知能力能够让一个普通的软件开发者进阶到更高的层次,比如架构师、项目管理、技术管理等等。
---
在第二步中包括两章:专业能力,认知能力。其中,专业能力能够让一个软件开发者找到工作并保住饭碗;而认知能力能够让一个普通的软件开发者进阶到更高的层次,比如架构师、项目管理、技术管理等等。
---

Просмотреть файл

@ -1,11 +1,10 @@
# 第二章 专业能力
本章仍然以木头在微软的(真实)面试故事开头,讲解微软对软件工程师的要求,进而引入做一名合格的软件工程师所需要的专业技术能力,如:算法(algorithm、代码coding skill、建模design pattern、设计system design、测试testing等。在最后还列出了软件工程师的常见误区。
本章仍然以木头在微软的(真实)面试故事开头,讲解微软对软件工程师的要求,进而引入做一名合格的软件工程师所需要的专业技术能力,如:算法(Algorithm、代码Coding skill、建模Design pattern、设计System design、测试Testing等。在最后还列出了软件工程师的常见误区。
本章将会就这几个专业能力展开讨论。
<img src="img/Slide1.SVG" height=300/>

Просмотреть файл

@ -1,13 +1,11 @@
## 2.1 面试的故事
我们先讲一个木头面试的(真实但有节选)故事,从故事的情节中,大家也许可以发现像微软这样的公司是如何考察个人能力的。
我们先讲一个木头面试的(真实但有节选)故事,从故事的情节中,大家也许可以发现大型软件公司是如何考察个人能力的。另外下面出现的这些面试题目都比较陈旧但是很经典现在面试基本上不用了和力扣LeetCode )上的差不多,主要是考察基本能力的。
木头毕业后在一个国企工作后来想“下海”闯荡于是花了3个月时间复习了 4 本书分别是《C++教程》、《数据结构与算法》、《C#教程》、《高等数学》。恰逢微软启动了当年的扩大招聘计划。于是,修改简历,扔过去,反正也不花钱,要是花钱,就扔 100 块钱的,就当是买彩票了。
木头毕业后在一个国企工作后来想“下海”闯荡于是花了3个月时间复习了 4 本书分别是《C++教程》、《数据结构与算法——C语言描述》、《C#高级编程》、《高等数学》。恰逢微软启动了当年的扩大招聘计划。于是,修改简历,扔过去,反正也不花钱,要是花钱,就扔 100 块钱的,就当是买彩票了。
和很多大公司一样微软有两种招聘渠道校园招聘Campus Hire和社会招聘Industry Hire。一般来说校园招聘要经过三轮面试前两轮是技术面试最后一轮是决策者As AppropriateAA直译为“视情况而定”面试而社会招聘要经过六轮面试前五轮技术面试最后一轮决策者面试。
木头加入微软就是走的社会招聘渠道只要不是刚踏出校门的学生寻找第一份工作就都要走这个渠道。简历能被人力资源Human ResoruceHR看到是一件非常幸运的事如何写简历不在本书的讨论范围之内。木头就很幸运几个关键的技术点正好符合职位描述Job DescriptionJD于是才有了下面的故事......
和很多大公司一样微软有两种招聘渠道校园招聘Campus Hire和社会招聘Industry Hire。一般来说校园招聘要经过三轮面试而社会招聘要经过六轮面试。木头加入微软就是走的社会招聘渠道只要不是刚踏出校门的学生寻找第一份工作就都要走这个渠道。简历能被人力资源Human ResourceHR看到是一件非常幸运的事。木头就很幸运几个关键的技术点正好符合职位描述Job DescriptionJD于是才有了下面的故事......
### 2.1.1 第一轮面试
@ -121,7 +119,7 @@
就能知道这个指针指向的是上级节点。如何设计数据结构?
```
算法!除了算法,还是算法!因为我应聘的是 SDE。
木头心想数据结构的书没白看这次有在黑板上写东西的经验了。3 分钟后,画了一个二叉树的数据结构,每个节点的 key 值都用含有级别信息的值标识,则任意一个节点内的指向其它节点的指针的 key 值与本节点的 key 值比较,就能知道指向的是否是上级节点。
木头心想数据结构的书没白看这次有在黑板上写东西的经验了。3 分钟后,画了一个二叉树的数据结构,每个节点的键值都用含有级别信息的值标识,则任意一个节点内的指向其它节点的指针的键值与本节点的键值比较,就能知道指向的是否是上级节点。
```txt
面试官:还有没有更简单的方法?
木头:不可能有了。
@ -136,9 +134,9 @@
木头:(先做了会议室类,再做了管理类)。
面试官:如果多人预订会议室呢?
木头:(又做了预订动作类)
木头:(又设计了预订会议室动作类)
```
又说了些别的,就带木头去 6 层了。他进去后和人力资源谈了几分钟,再出来时,就和木头握手说再见。人力资源说起下一轮面试的时间,木头才踏实了,知道应该过关了。
面试官和木头又说了些别的,就带木头去 6 层了。他进去后和人力资源谈了几分钟,再出来时,就和木头握手说再见。人力资源说起下一轮面试的时间,木头才踏实了,知道应该过关了。
### 2.1.5 第五轮面试
@ -152,7 +150,7 @@
面试官:话音业务我不了解,说数据业务吧。
```
木头把数据互联网业务的系统设计思路在黑板上画了一遍,考虑到了可用性、可靠性、可扩展性,分 4 层结构,第一层做对内 DNS 轮询;第二层做接入,要用 Load Balance负载均衡第三层用 COM+ 组件,做中间件,做任务分发;第四层做数据库群集......此处省略1000字
木头把互联网业务的系统设计思路在黑板上画了一遍,考虑到了可用性、可靠性、可扩展性,分 4 层结构,第一层做对内 DNS 轮询;第二层做接入,要用 Load Balance负载均衡第三层用 COM+ 组件,做中间件,做任务分发;第四层做数据库群集......此处省略1000字
```txt
面试官:我们再做一个算法题吧。
木头:(天啊,又是算法)没...问题!
@ -176,7 +174,7 @@
木头:哦,好好(其实应该说 me too
```
注:这种情景让笔者想起了有一次在Intel给一个老外和几个同胞讲我们的产品系统结构讲得他们很爽最后老外主动站起来和我握手说"glad to meet you"。当时那些Intel的同胞都很惊讶的叫了一声因为他们知道那个老外很少这样做前面有10个这样的公司给他们讲东西了他从来没有站起来过。于是我才知道如果在刚见面时,人家对你说“glad to meet you”是客套在会谈结束后说“glad to meet you”就表示是欣赏你。
如果在刚见面时人家说“glad to meet you”通常是客套在会谈结束后说“glad to meet you”就表示是欣赏你。
### 2.1.6 第六轮面试
@ -194,7 +192,7 @@
```txt
面试官:当用户在网络上发起请求后,系统服务器故障了,你如何保留这个用户的请求信息。
木头:如果没有造成呼损,那就不管了;如果不牵涉到计费,也不管了;我尽量设计成把请求一次提交。
木头:如果没有造成呼,那就不管了;如果不牵涉到计费,也不管了;我尽量设计成把请求一次提交。
面试官:如果以上条件都不满足呢?
木头:那我只好把 session 存在 DB 里面了。
@ -204,14 +202,14 @@
### 2.1.7 接到通知
11 月6 日10:00某大厦 4 层。
11 月 6 日10:00某大厦 4 层。
木头的手机响了
```txt
对方:我是微软 xxx我们对你的面试很满意我们决定给你这个 offer......
对方:我是 xxx我们对你的面试很满意我们决定给你这个 offer......
木头:(激动啊......)您给我个正式的邮件吧(保持镇定,万一对方是个骗子呢,所以需要书面的东西)。
```
11 月 7 日木头收到了正式的邮件。
故事就写到这里吧,下面总结一下微软这样的公司需要什么样的人做 SDE
故事就写到这里吧,下一节总结一下像微软这样的大型软件公司需要什么样的人做软件开发工程师

Просмотреть файл

@ -8,7 +8,7 @@
### 2.2.1 技能点是否符合要求
第一个面试官是一个 PM他的主要职责是询问木头的技能点是否满足职位描述的要求。比如在这次面试中希望木头有大批量数据的处理经验因为是要做一个后台的数据处理流程。
第一个面试官是一个项目经理Program Manager后简称为PM,他的主要职责是询问木头的技能点是否满足职位描述的要求。比如在这次面试中,希望木头有大批量数据的处理经验,因为是要做一个后台的数据处理流程。
做为一个有多年从业经验的面试者,写简历的基本技巧如下:

Просмотреть файл

@ -39,7 +39,7 @@ def generate_data():
### 2.3.1 求和法
小学生都知道
求和的梯形公式是
$$
\sum_{i=1}^{100} i=\frac{1+100}{2} \times 100=5050
@ -79,7 +79,7 @@ def method_2_dict(data):
dict[x]=1
```
注意,这里不能使用数组的 “_ contains _ ” 函数来判断是否已经存在相同的值,因为该函数是遍历方式搜索,属于 $O(n)$ 的时间复杂度,而字典的 “_ contains _” 函数是 $O(1)$ 速度的,但是计算哈希值需要一些时间。
注意,这里不能使用数组的 _contains_ 函数来判断是否已经存在相同的值,因为该函数是遍历方式搜索,属于 $O(n)$ 的时间复杂度,而字典的 _contains_ 函数是 $O(1)$ 速度的,但是计算哈希值需要一些时间。
### 2.3.3 排序法

Просмотреть файл

@ -196,13 +196,15 @@ class RibukCube():
### 2.4.2 设计
应用场景:
在考察设计能力时,面试官一般要给出应用场景和限制条件,然后让面试者给出自己的设计。
1应用场景
- 甲方每天早晨 8:00 传给乙方前一个交易日的股票大盘数据。
- 乙方收到数据后,立刻验证数据是否齐备,然后使用已有模型做股票价格预测。
- 需要在 9:30 之前把预测结果发送回甲方。
限制条件
2限制条件
- 保存所有的历史大盘及预测记录。
- 全自动化,无人干预。

Просмотреть файл

@ -16,25 +16,24 @@
#### 2. 阶段Stage
微软的软件工程师的阶段划分(级别)如图 2-6 所示
微软的软件工程师的职级如表 2-1 所示(具体名称有所修改,便于理解)
<img src="img/Slide8.SVG" height=300/>
表 2-1 软件工程师的职级
图 2-6 微软软件工程师的级别
|英文代号|中文名称|角色|说明|
|--|--|--|--|
|S2| 初级软件工程师| 小组成员| 具备入门知识,缺乏实践|
|S3| 中级软件工程师| 小组成员| 可以独立工作,有团队合作经验|
|S4| 高级软件工程师| 小组成员/技术领导| 可以带领5-10名员工完成功能|
|P5/P6| 首席软件工程师| 团队技术/行政领导| 可以带领10-30名员工项目决策|
|P7| 产品专家| 部门技术/行政领导| 带领100名以上员工方向决策|
|P8| 领域专家| 组织技术/行政领导| 负责领域问题决策|
|P9| 战略专家| 公司技术/行政领导| 负责战略问题决策,影响业界|
从阶段看,一共有 9 个,所以后面会简称为“几段”(类似围棋选手级别名词)。在有些区域是有“一段”的,比如微软苏州,但是微软北京都是从“二段 (Stage 2)”开始。
职级看,微软的软件工程师的职级一共有 9 级。在以前的官方定义中,软件工程师的英文名称为 Software Development软件开发后来改成了 Software Engineer软件工程师笔者猜测其原因如下
在以前的官方定义中,软件工程师的英文名称为 Software Development软件开发后来改成了 Software Engineer软件工程师笔者猜测其原因如下
1. 在微软取消了测试职位后,软件工程师也要负责测试,所以不能再叫做 Development 了,但是又不能叫做 Software Development-Test所以就叫做 Software Engineer
2. Software Development 只负责开发Software Engineer 在字面上加入了工程的含义,即对软件开发者有更高的要求,需要熟悉产品周期各个环节的所有职责。
还有一个级别Level的概念比如
- 在二段中有 L59L60 两个级别;
- 在三段中有 L61、L62 两个级别;
- 在四段中有 L63、L64 两个级别;
- 在五段中有 L65、L66、L67 三个级别;
......
- 在微软取消了测试职位后,软件工程师也要负责测试,所以不能再叫作 Development 了,但是又不能叫作 Software Development-Test所以就叫作 Software Engineer
- Software Development 只负责开发Software Engineer 在字面上加入了工程的含义,即对软件开发者有更高的要求,需要熟悉产品周期各个环节的所有职责。
#### 3. 职业Discipline
@ -59,11 +58,11 @@ Discipline 原意是知识领域,可以引申为职业。前面也说过,在
### 2.5.2 考核指标
微软对软件工程师的要求有六个大项,如图 2-7 所示。
微软对软件工程师的要求有六个大项,如图 2-6 所示。
<img src="img/Slide9.SVG" height=300/>
图 2-7 微软工程师的考核指标
图 2-6 微软工程师的考核指标
下面以“二段”为例,介绍一下每个大项中包含的具体内容。
@ -71,11 +70,11 @@ Discipline 原意是知识领域,可以引申为职业。前面也说过,在
构建正确的产品和服务,为客户提供其预期的价值,并实现所需的业务目标。根据对客户系统运行数据的观察总结和总体业务目标制定决策。
对于“二段”,有如图 2-8 所示的具体要求:
对于S2级别有如图 2-7 所示的具体要求:
<img src="img/Slide10.SVG" height=300/>
图 2-8 产品和服务设计
图 2-7 产品和服务设计
- 熟悉产品或服务、竞争对手产品或服务的工作知识,以及客户或合作伙伴的知识,为创新功能区产品或服务设计做出贡献。
- 就产品或服务设计提供反馈,具有吸引客户的风格、趣味性和美感,以及功能需求。
@ -95,11 +94,11 @@ Discipline 原意是知识领域,可以引申为职业。前面也说过,在
开发高质量的代码以满足技术要求例如可伸缩、全球交付、分布式、可监控、可维护性、可测试性、调试和维护。构建关联的测试以在单元级别和端到端级别验证代码。开发满足预期投资回报ROI的基础设施。使用软件开发技能来分析解决问题并改进产品或服务的技术设计。
对于“二段”,有如图 2-9 所示的具体要求:
对于S2级别有如图 2-8 所示的具体要求:
<img src="img/Slide11.SVG" height=300/>
图 2-9 技术设计和实现
图 2-8 技术设计和实现
- 针对各类不同的问题,进行层次设计和接口设计,实现组件组之间的集成,提高重用性,并满足业务、客户、工程和运营需求。
- 在适当的时候推动设计评审,定义模块之间的接口,并将成熟技术应用于设计。
@ -118,11 +117,11 @@ Discipline 原意是知识领域,可以引申为职业。前面也说过,在
创建并验证高效(低延迟、高吞吐量)、稳定、安全、可维护、可扩展、性能好、经过良好测试和可重用的代码,以实现产品或服务的客户和业务目标。构建正确的测试和工具,以验证代码是否符合质量目标或服务。分析数据并给出结论,使自己和同事能够理解和解决问题。确保在产品或服务的整个生命周期内保持质量。
对于“二段”,有如图 2-10 所示的具体要求:
对于S2级别有如图 2-9 所示的具体要求:
<img src="img/Slide12.SVG" height=300/>
图 2-10 代码质量和验证
图 2-9 代码质量和验证
- 考虑性能和可维护性,了解代码何时可以分享或交付,可以处理该产品各个方面的问题。
- 解决测试覆盖率问题,组织和实施集成测试,并修复发生问题的代码。
@ -141,11 +140,11 @@ Discipline 原意是知识领域,可以引申为职业。前面也说过,在
使用、定义和改进编码和测试实践、流程、工具、基础架构和标准,以提高效率,为 Microsoft 和客户提供预期的产品或服务成果。
对于“二段”,有如图 2-11 所示的具体要求:
对于S2级别有如图 2-10 所示的具体要求:
<img src="img/Slide13.SVG" height=300/>
图 2-11 工程生命周期
图 2-10 工程生命周期
- 利用对工程生命周期和以往发布产品经验的理解,倡导在每个里程碑上提出改进建议,以及整个过程的改进。
- 在适当的情况下,推动设计和代码审查,并在整个团队中分享最佳实践。
@ -162,11 +161,11 @@ Discipline 原意是知识领域,可以引申为职业。前面也说过,在
在团队环境中积极行动,提高团队整体的效率、影响力和士气。跨团队、产品、服务或平台边界积极工作,以共享信息和技术,并确保同行团队目标一致。酌情组建团队。指导他人并主动寻求他人的指导。
对于“二段”,有如图 2-12 所示的具体要求:
对于“二段”,有如图 2-11 所示的具体要求:
<img src="img/Slide14.SVG" height=300/>
图 2-12 高效的团队合作
图 2-11 高效的团队合作
- 在团队中做出建设性贡献。
- 主动管理依赖关系并展示解决冲突的能力。
@ -186,11 +185,11 @@ Discipline 原意是知识领域,可以引申为职业。前面也说过,在
持续而有力地显示出对整个产品或服务的质量和完整性以及最终用户体验的责任感。保持一种自豪感和工艺感,使我们的产品具有美感和技术价值。
对于“二段”,有如图 2-13 所示的具体要求:
对于“二段”,有如图 2-12 所示的具体要求:
<img src="img/Slide15.SVG" height=300/>
图 2-13 对产品和服务的责任感
图 2-12 对产品和服务的责任感
- 对端到端的产品或服务质量、完整性以及产品或服务生命周期中的最终用户体验具有自豪感、承诺感和个人责任感。
- 定期使用产品/服务,彻底了解产品/服务并找出改进方法。
@ -206,13 +205,13 @@ Discipline 原意是知识领域,可以引申为职业。前面也说过,在
### 2.5.3 技术设计与实现的进阶
在上一小节中描述的都是针对“二段”软件工程师的要求,内容看上去已经比较丰富了,但其实还是入门级别。针对更高级别的软件工程师的级别如图 2-14 所示,这里只用“技术设计与实现”一项来举例。
在上一小节中描述的都是针对“二段”软件工程师的要求,内容看上去已经比较丰富了,但其实还是入门级别。针对更高级别的软件工程师的级别如图 2-13 所示,这里只用“技术设计与实现”一项来举例。
<img src="img/Slide16.SVG" height=300/>
图 2-14 技术设计与实现的进阶
图 2-13 技术设计与实现的进阶
#### 1. SDE - 解决模块级别的简单技术问题
#### 1. S2 - 解决模块级别的简单技术问题
要求:
@ -226,7 +225,7 @@ Discipline 原意是知识领域,可以引申为职业。前面也说过,在
在 SDE 级别,主要是在软件的**模块级别**上工作,只为自己编写的局部功能负责。模块是否能正常工作是重点要关心的。
#### 2. SDE II - 解决组件级别的复杂技术问题
#### 2. S3 - 解决组件级别的复杂技术问题
要求:
@ -240,7 +239,7 @@ Discipline 原意是知识领域,可以引申为职业。前面也说过,在
在 SDE II 级别,主要是在软件的**组件级别**(模块的组合)上工作,对所在的项目负有一定的责任。要关心的组件的对外接口的正确与稳定。
#### 3. Senior SDE - 解决功能级别的端到端技术问题
#### 3. S4 - 解决功能级别的端到端技术问题
要求:
@ -255,7 +254,7 @@ Discipline 原意是知识领域,可以引申为职业。前面也说过,在
在 Senior SDE 级别,主要是在软件的**功能级别**(组件的堆叠)上工作,对某个产品或服务的端到端功能负有责任。功能的完整性、正确性是要关心的事情。
#### 4. Principle SDE - 解决系统级别的综合性技术问题
#### 4. P5/P6 - 解决系统级别的综合性技术问题
要求:
@ -270,7 +269,7 @@ Discipline 原意是知识领域,可以引申为职业。前面也说过,在
在 Principle SDE 级别,主要工作在软件的**系统级别**(功能的组合)上,对某个产品或服务的整体负责。产品是否可以满足各种用户的整体要求、为公司增加商业价值是要关心的事情。
#### 5. Partner SDE - 部门级别的创新设计
#### 5. P7 - 部门级别的创新设计
要求:
@ -283,7 +282,7 @@ Discipline 原意是知识领域,可以引申为职业。前面也说过,在
Partner SDE 级别已经不能再用软件的级别来对标了,而是要负责一个**部门**中的好几个产品或服务。产品发展方向以及在公司产品线中的地位是这个级别最应该关心的事情。
#### 6. Distinguished Engineer - 组织级别的产品方向
#### 6. P8 - 组织级别的产品方向
要求:
- 作为其专业领域/领域的技术权威,为其专业领域的部门、公司或行业制定方向或技术路线图。
@ -299,7 +298,7 @@ Partner SDE 级别已经不能再用软件的级别来对标了,而是要负
杰出工程师代表着对微软的持续技术影响和影响力。个人需要深厚的技术知识、领导力和专业领域的重大创新。在各自的领域,对**组织**的业务成功至关重要,并负有责任,可能会塑造行业。
#### 7. Technical Fellow - 公司级别的重大创新
#### 7. P9 - 公司级别的重大创新
要求:

Просмотреть файл

@ -6,6 +6,8 @@
图 2-15 软件工程师的常见误区
对每一条误区更详细的解释见下文。
### 2.6.1 重新发明轮子,浪费时间
这是个老生常谈的话题“反复造轮子”Reinvent The Wheel。新程序员总是喜欢反复“造轮子”其原因不外乎以下几点
@ -32,7 +34,7 @@
其实不只是我们个人,许多大的工程,也存在这样的规划谬误的问题:
- 悉尼歌剧院的建设就是一个说明这一谬论的著名例子。它最初估计于 1963 年完成,耗资 700 万美元但该项目最终在预期日期后的10年内完成且耗资 1.02 亿美元。
- 埃及博物馆新馆2002 年立项2012 年动工,预计 2015 年竣工。结果由于施工难度大、造价超预算等多方面原因,延迟到 2019 年;但是疫情袭来,再次推迟到 2021 年;然后,政府变动,推迟到 2023 年春天。
- 埃及博物馆新馆2002 年立项2012 年动工,预计 2015 年竣工。结果由于施工难度大、造价超预算等多方面原因,延迟到 2019 年;但国内的一些大环境变动导致再次推迟到 2021 年后,再推迟到 2023 年春天。
所以,我们在估计项目的完成时间的时候,不应该以一种理想的非常顺利的想法来预测项目的进程,应当多考虑能够影响项目进程的因素,并参考历史经验。一般情况下,如果按照最顺利的情况估算出的时间,再乘以 2 或乘以 3 得到的时间,会和实际的花费时间差不多。
@ -107,7 +109,7 @@
所以,完全可以用一种可配置的界面设计来统一这些 Answer 的展示。
Answer 的触发词情况来看,基本上都是“实体+关键字”的形式“实体”就是“汽车”、“生活大爆炸”、“流浪地球”等词关键字可以是“在线观看”、“电视剧”、“电影”、“视频”等等可以有明显搜索意向intent的词汇。
Answer 的触发词基本上都是“实体+关键字”的形式“实体”就是“汽车”、“生活大爆炸”、“流浪地球”等词关键字可以是“在线观看”、“电视剧”、“电影”、“视频”等等可以有明显搜索意向intent的词汇。
在美国的搜索团队中每个领域Domain比如汽车、电视剧、电影的 Answer 都是由一个专门的团队来负责。但是,笔者和一些同事一起研究了一下,觉得完全可以用同一套数据处理流程来生成 Answer包括源数据加工、关键词提取、搜索触发逻辑、用户界面展示等等。而老板也同意我们的看法但是要求我们先做 7 个不同领域的 Answer 后,再回过头来泛化这个数据处理流程。

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 49 KiB

После

Ширина:  |  Высота:  |  Размер: 49 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 53 KiB

После

Ширина:  |  Высота:  |  Размер: 53 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 53 KiB

После

Ширина:  |  Высота:  |  Размер: 53 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 57 KiB

После

Ширина:  |  Высота:  |  Размер: 57 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 58 KiB

После

Ширина:  |  Высота:  |  Размер: 58 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 58 KiB

После

Ширина:  |  Высота:  |  Размер: 58 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 70 KiB

После

Ширина:  |  Высота:  |  Размер: 70 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 75 KiB

После

Ширина:  |  Высота:  |  Размер: 75 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 50 KiB

После

Ширина:  |  Высота:  |  Размер: 50 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 68 KiB

После

Ширина:  |  Высота:  |  Размер: 68 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 221 KiB

После

Ширина:  |  Высота:  |  Размер: 221 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 42 KiB

После

Ширина:  |  Высота:  |  Размер: 42 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 89 KiB

После

Ширина:  |  Высота:  |  Размер: 89 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 103 KiB

После

Ширина:  |  Высота:  |  Размер: 103 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 329 KiB

После

Ширина:  |  Высота:  |  Размер: 329 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 113 KiB

После

Ширина:  |  Высота:  |  Размер: 113 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 664 KiB

После

Ширина:  |  Высота:  |  Размер: 664 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 82 KiB

После

Ширина:  |  Высота:  |  Размер: 82 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 35 KiB

После

Ширина:  |  Высота:  |  Размер: 35 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 66 KiB

После

Ширина:  |  Высота:  |  Размер: 66 KiB

Просмотреть файл

@ -1,7 +1,7 @@
# 第三章 认知能力
上一章我们讲的是专业能力,具备了那些专业能力就可以成为一个合格的软件工程师。但是,如果想往更高的地方走,就需要本章中所讲的认知能力的辅助。在笔者看来,认知能力包括:沟通能力、学习能力、解决问题的能力、系统化思维能力等,这些都可以通过读者对自己的认知能力的培养来获得,基本上就是马克思理论中的实践-理论的循环,在中国古代叫做知行合一,也可以细化为:学习、思考、实践、抽象。
上一章我们讲的是专业能力,具备了那些专业能力就可以成为一个合格的软件工程师。但是,如果想往更高的地方走,就需要本章中所讲的认知能力的辅助。在笔者看来,认知能力包括:沟通能力、学习能力、解决问题的能力、系统化思维能力等,这些都可以通过读者对自己的认知能力的培养来获得,基本上就是马克思主义哲学中的理论与实践结合的原理,在中国古代叫做知行合一,也可以细化为:学习、思考、实践、抽象。
<img src="img/Slide1.SVG" height=300/>

Просмотреть файл

@ -43,9 +43,7 @@
表达观点时,要有理有据(虽然不能保证合情合理),不能道听途说地只说个结论,没有推理过程或者解释说明。
比如你想说服其它人采用你的技术建议,粗糙的沟通方式是:“这种技术很多大公司都采用了,我们也应该采用。” 这种观点拿出来很容易被他人 challenge挑战、挑毛病
可以找到两三条理由来支持观点,比如:
比如你想说服其它人采用你的技术建议,粗糙的沟通方式是:“这种技术很多大公司都采用了,我们也应该采用。” 这种观点拿出来很容易被他人挑战,可以找到两三条理由来支持观点,比如:
*“我建议采用一个消息队列接在 Web 服务器后面,这样的好处是:*
@ -163,7 +161,7 @@
木头的乐队里还有个例子:某个小乐队的某个成员想在元旦时出去玩儿,但是新年音乐会定在了 1 月 6 日他又怕到时候不能赶回来所以这个小乐队的队长就来找我说“1 月 6 日估计很多微软员工休假的还没回来,影响观众的上座率,不如我们延期举办音乐会吧?”
这听上去就是很为演出效果考虑的感觉,但是春节后再开音乐会的话,排练不好安排,大家过完春节刚刚来上班,不论是观众和乐手,心气儿都差远了。木头看出来了是因为他们的乐手凑不齐才会提这个要求,所以拒绝了这个小队长的请求,说:“你如果缺乐手可以向别的乐队借,没必要把自己小乐队的困难绕个弯子转嫁到整个演出上。”
这听上去是在为演出效果考虑,但是春节后再开音乐会的话,排练不好安排,大家过完春节刚刚来上班,不论是观众和乐手,心气儿都差远了。木头看出来了是因为他们的乐手凑不齐才会提这个要求,把自己小乐队的困难绕个弯子转嫁到整个演出上,所以拒绝了这个小队长的请求,说:“你如果缺乐手可以向别的乐队借。”
#### 2. 相同的话不要重复说
@ -225,7 +223,7 @@
- 主动帮助他人,分享你的经验。
- 开会时主动发言,表达自己的观点。
- 主动承担任务池中的工作项,并努力完成,及时交付。
- 和 PM 搞好关系,耐心解答技术问题。
- 和 PM 建立良好的工作关系,耐心解答技术问题。
- 与外部团队合作时,态度要谦虚谨慎,以项目成功为主要目标,其它为次要目标。
- 及时反馈。无论是答应了谁做什么事,都要及时反馈,不能等着别人来问你进度。

Просмотреть файл

@ -112,12 +112,12 @@ $$
把知识分解成各个组成要素,从而使各概念间的相互关系更加明确,组织结构更为清晰,详细地阐明基础理论和基本原理。包括:元素分析、关系分析、组织分析。
一名有经验的软件工程师经常要给新手以必要的帮助和指导。有经验的 mentor 会这样做:
一名有经验的软件工程师经常要给新手以必要的帮助和指导。有经验的导师mentor会这样做:
- 现在咱们做的这个模块要求性能好、速度快,因为它是个核心模块,从系统架构图中,你们应该也能看到它所处的地位。
- 核心算法如果用哈希表支持查询的话,当然是速度很快了,可以快速搭建原型,演奏 e2e 的效果。
- 核心算法如果用哈希表支持查询的话,当然是速度很快了,可以快速搭建原型,演示端到端( End to ende2e的效果。
- 但是,在实际应用中,由于数据量很大,哈希表占用的内存空间太大,对机器的内存配置要求较高,所以我们不能使用这种技术。
- 所以,我们要是用 Trie-Tree 来完成信息检索部分的核心算法,它实际上就是一个多层哈希表,但是索引数量会成几何级别减少。
- 所以,我们要是用字典树Trie-Tree来完成信息检索部分的核心算法,它实际上就是一个多层哈希表,但是索引数量会成几何级别减少。
- 在 C++ 中没有这种数据结构的实现,所以需要我们参考一下其它语言的实现,用一个小的数据集在 Java 的实现上做一个 Debug就很容易理解了。
- 你们两个人分工,一个人找 Java 实现,另一个人准备数据集,然后一起 Debug。搞清楚原理后一个人写代码另一个写测试用例。争取一周内搞定这件事。
@ -133,7 +133,7 @@ $$
- 通过对甲和乙两名毕业生的面试,我发现:甲是研究生学历,计算机基础知识扎实,参与的校外公司的实习项目较多,沟通顺畅;乙是博士生学历,偏理论方向,在校时间较长,大多数时间是跟着导师做项目,自我意识较强。如果咱们想物色一名可以很快融入团队并做出贡献的人,那么甲比较合适。
- 如果比较阿里云与微软云的话:前者比较接地气,后期服务好,在国内数据中心多,而且便宜;微软云技术先进可靠,安全性很高,同类服务的可选择性多,但是比较贵。如果我们想扬帆出海面向全球用户的话,建议使用微软云
- 如果比较A云服务与B云服务的话前者比较接地气后期服务好在国内数据中心多而且便宜后者技术先进可靠,安全性很高,同类服务的可选择性多,但是比较贵。如果我们想扬帆出海面向全球用户的话,建议使用B云服务
- 这个架构设计方案比较全面,在可用性、可靠性、可维护性、安全性等几个方面都有考虑,并且使用可一些成熟可靠的框架,性能和可扩展性上也应该不是问题,只是在一些细节上还需要后续做具体实现之前,再和相关的小组讨论并完成详细设计。
@ -151,7 +151,7 @@ $$
- 写一篇关于解决物流效率的问题的强化学习方面的论文。
- 设计一个系统来满足在特定时刻对网站的大规模突发访问,比如双十一购物节。
- 制定一个新的工作手册,来适应疫情期间很多员工需要在家远程办公的情况。
- 制定一个新的工作手册,来适应很多员工需要在家远程办公的情况。
- 把已有的一些传统的机器学习算法创新性地用于脏数据处理,然后再在干净的数据上做回归或分类的学习,将会得到更好的混淆矩阵评估值。
- 在已有的缓冲区的基础上,再设计一个二级缓冲区,可以容纳更多的数据,会成倍地提高查询的效率,但只付出很小的设备代价。
@ -173,9 +173,7 @@ $$
- 术语知识。
- 具体细节和组成元素。
任何领域中的术语、具体细节和基本元素都可以定义为事实知识。比如软件和软件工程领域中的编程语言的语法知识、关于算法的名词知识KNN、DNN、RNN、CNN......)、关于测试的各种名词知识(单元测试、集成测试......)等等。
是一种非常具像的知识形式,属于纯静态的问题。如图 3-5 中的子图 1有 A、B、C 三个看上去独立的点,表示三个基本的事实知识。
任何领域中的术语、具体细节和基本元素都可以定义为事实知识。是一种非常具像的知识形式,属于纯静态的问题。如图 3-5 中的子图 1有 A、B、C 三个看上去独立的点,表示三个基本的事实知识。
学习这些静态知识最好的办法就是翻阅教科书,一般的书的作者都会比较严谨,在书中列出的名词及其解释会比较的准确和全面。然后再从其它渠道(比如互联网)获得更多的关于这些名词的实际应用的介绍,而不是机械地背诵它们的定义。
@ -194,7 +192,7 @@ $$
如图 3-5 中的子图 2A、B、C 三个点扩展了其外延,使得本来独立的点连接到了一起,形成多个概念知识。
概念知识与低级别的事实知识相关,可以理解为是一种上下文相关的知识,而不是局限在某一个点(事实)上。比如我们知道了软件测试包括单元测试和集成测试这个事实(包含两个元素),但是还应该进一步知道它们分别侧重于哪个方面,区别和联系是什么。再比如算法名词,应该知道 KNN 是一种聚类算法,而 DNN、RNN、CNN 其实是深度神经网络中的一些名词,把它们结合起来可以形成强大的深度学习模型。
概念知识与低级别的事实知识相关,可以理解为是一种上下文相关的知识,而不是局限在某一个点(事实)上。比如我们知道了软件测试包括单元测试和集成测试这个事实(包含两个元素),但是还应该进一步知道它们分别侧重于哪个方面,区别和联系是什么。再比如算法名词,应该知道K-邻近算法( KNN 是一种聚类算法,而 深度神经网络(DNN循环神经网络(RNN卷积神经网络(CNN 其实是神经网络中的一些名词,把它们结合起来可以形成强大的深度学习模型。
#### 3. 过程知识Procedural Knowledge

Просмотреть файл

@ -139,7 +139,7 @@ np.allclose(x, y, rtol=1e-2, atol=1e-3)
是不是因为在模型中有一些随机因素造成了推理结果不准确呢?于是,木头检查了一遍模型,并没有返现有 dropout 等算子(操作符)出现,所以排除了这种情况。
【最佳实践】产生一个问题的原因有很多种,可以认为是星形结构(如图 3.3.3把这些原因罗列出来一个个地去试验即可找到根本原因root cause
【最佳实践】产生一个问题的原因有很多种可以认为是星形结构把这些原因罗列出来一个个地去试验即可找到根本原因root cause
#### 3. 定位原因
@ -150,8 +150,7 @@ np.allclose(x, y, rtol=1e-1, atol=1e-2)
```
就可以轻松通过验证。由此可以得知就是精度问题导致验证失败。但是如果就此得出结论“16 位的模型精度有问题”,那就为时过早了。
如图 3.3.4 所示,我们一直把怀疑集中到转换的过程,在 16 位精度的模型中,一个样本 S 做两次推理得到的结果 $Y$ 和 $Y'$,它们有时候和 $X$ 非常接近,有时候又不是很接近,而 $Y$ 和 $Y'$ 两者之间也会有精度差。
如图 3-10 所示,我们一直把怀疑集中到转换的过程,在 16 位精度的模型中,一个样本 S 做两次推理得到的结果 $Y$ 和 $Y'$,它们有时候和 $X$ 非常接近,有时候又不是很接近,而 $Y$ 和 $Y'$ 两者之间也会有精度差。
木头忽然想到:如果用 32 位模型做两次推理,得到的结果 $X$ 和 $X'$ 一样吗?于是得到试验结果如下:
@ -178,19 +177,19 @@ np.allclose(x, y, rtol=1e-1, atol=1e-2)
这就说明确实是 GPU 在做推理运算时不稳定,每次的结果都会有一些精度上的误差。当使用一个样本做多次验证时,总会有一次和 32 位模型的数值精度相差不大,所以很容易通过;但是当使用 32 个样本时,虽然偏差较小,但是方差就比较大,很难同时满足 32 个样本的精度差都很小的情况,所以就不能通过验证。
【最佳实践】这一步很关键,要把我们认为的 root cause根本原因)和该 Bug 所产生的现象联系起来,看看是否有因果关系。
【最佳实践】这一步很关键,要把我们认为的根本原因root cause)和该 Bug 所产生的现象联系起来,看看是否有因果关系。
#### 5. 解决问题
最后如何解决这个 bug代码或设计缺陷后文统称为 bug并不是木头所在的小组的职责而是由其它小组专门负责所以木头就在 GitHub Issues 里给那个小组开了一个 bug并告知了相关的 PM。
最后如何解决这个 bug代码或设计缺陷后文统称为 bug并不是木头所在的小组的职责而是由其它小组专门负责所以木头就在 GitHub Issues 里给那个小组开了一个 Bug并告知了相关的 PM。
【最佳实践】如果是读者自己需要解决这个 bug那么还需要增加相应的单月测试代码避免再次发生。
【最佳实践】如果是读者自己需要解决这个 Bug那么还需要增加相应的单月测试代码避免再次发生。
#### 6. 小结
【最佳实践】
在上面的过程中,木头经过了以下步骤来复现与理解问题,如图 3.3.5 所示:
在上面的过程中,木头经过了以下步骤来复现与理解问题,如图 3-11 所示:
1熟悉环境这是对一些来到新环境的陌生读者开说的。
2复现问题可以联系用户让他们提供实测环境。
@ -242,17 +241,21 @@ np.allclose(x, y, rtol=1e-1, atol=1e-2)
这里有两个关于做饭的有趣的故事。
第一个是关于烙饼的故事:有一位中年妇女,很擅长烙饼,她每次把生面饼擀成圆形后,都要把生面饼的外缘切掉一厘米左右的宽度,在把缩小了直径的生面饼放入锅中。别人就问她:为什么要切掉一圈?她回答说:我母亲就是这么教我的。别人就去问她母亲,她母亲答道:因为以前家里的案板大但是锅小,所以要把生面饼切掉一圈再下锅烙
第一个是关于烙饼的故事。
第二个关于煮饺子的故事:木头从小就爱吃饺子,妈妈总会在周末的时候包饺子吃。木头不会包饺子,就事先在锅里放上水,放在煤气炉子上烧开水。在煮饺子的时候,木头在旁边等着饺子出锅。在煮到一半的时候,沸水会成泡沫状溢出锅外,妈妈总会用一个大勺子盛满凉水兑入锅中,水就不会溢出了。这样反复三次,饺子就熟了,俗称“蜻蜓点水”。问妈妈为什么要点水?妈妈说以前姥姥就是这么教的。
*有一位中年妇女,很擅长烙饼,她每次把生面饼擀成圆形后,都要把生面饼的外缘切掉一厘米左右的宽度,在把缩小了直径的生面饼放入锅中。别人就问她:为什么要切掉一圈?她回答说:我母亲就是这么教我的。别人就去问她母亲,她母亲答道:因为以前家里的案板大但是锅小,所以要把生面饼切掉一圈再下锅烙。*
木头觉得很奇怪,因为煤气开关明明可以关小,就可以不让水溢出。偶然看到电影里的情节,木头才想通:以前都是用煤球烧火,没有开关,煤球炉子产生的热量是无法控制的,所以只能用点水的办法控制锅内水温。之所以要点三次水,是因为祖辈的历史经验积累,点三次水后的时间大概就是 5 分钟左右,饺子刚好可以熟透。
第二个关于煮饺子的故事。
*木头从小就爱吃饺子,妈妈总会在周末的时候包饺子吃。木头不会包饺子,就事先在锅里放上水,放在煤气炉子上烧开水。在煮饺子的时候,木头在旁边等着饺子出锅。在煮到一半的时候,沸水会成泡沫状溢出锅外,妈妈总会用一个大勺子盛满凉水兑入锅中,水就不会溢出了。这样反复三次,饺子就熟了,俗称“蜻蜓点水”。问妈妈为什么要点水?妈妈说以前姥姥就是这么教的。*
*木头觉得很奇怪,因为煤气开关明明可以关小,就可以不让水溢出。偶然看到电影里的情节,木头才想通:以前都是用煤球烧火,没有开关,煤球炉子产生的热量是无法控制的,所以只能用点水的办法控制锅内水温。之所以要点三次水,是因为祖辈的历史经验积累,点三次水后的时间大概就是 5 分钟左右,饺子刚好可以熟透。*
点水据说还有其它的好处:
- 煮了一段时间后,水变成蒸汽,锅内的水量减少,面粉会导致粘稠,加水后会稀释;
- 水温保持太高的话,面皮会发软粘连,容易破皮;
- 面皮容易熟,里面的馅儿不容易熟,加凉水可以降低水温,同时保持馅儿的温度持续
- 面皮容易熟,里面的馅儿不容易熟,加凉水可以降低水温,里外受热均匀
但其实上面这些好处都是可以通过用“关小火 + 盖锅盖”的方式来实现的。

Просмотреть файл

@ -105,9 +105,9 @@
#### 4. 工作内容
在一个团队中,有些人工作在项目 A而另外一些人为项目 B 工作。A 项目是一个新生的领域,发展很快,影响力大。但是 B 项目是一个维护已有系统的工作,不出错就可以了。显然 A 项目中的成员会有更多的晋升机会,大老板们也会偏向给 A 项目更多的 budget
在一个团队中,有些人工作在项目 A而另外一些人为项目 B 工作。A 项目是一个新生的领域,发展很快,影响力大。但是 B 项目是一个维护已有系统的工作,不出错就可以了。显然 A 项目中的成员会有更多的晋升机会,大老板们也会偏向给 A 项目更多的资源
比如微软小冰在脱离微软以前,成员们像坐着火箭一样地晋升,当然 ta 们经常加班也是不争的事实。但是在脱离微软单独成立一个公司时,每个成员都被告知会降薪(因为成员们的级别普遍太高了)。
比如微软小冰在脱离微软以前,成员们像坐着火箭一样地晋升,当然们经常加班也是不争的事实。但是在脱离微软单独成立一个公司时,每个成员都被告知会降薪(因为成员们的级别普遍太高了)。
#### 5. 积累效应
@ -124,11 +124,11 @@
不只是老板觉得你不错,其它同事也都觉得你不错,这样老板晋升你的决定才会服众。
还有就是你的工作成绩要有 Visibility可见性被大家知道否则你的老板一说起要晋升你时其它同级别或上级老板会有疑问ta 都做过什么项目,我怎么一直不知道这个人呀?这就比较尴尬了。
还有就是你的工作成绩要有 Visibility可见性被大家知道否则你的老板一说起要晋升你时其它同级别或上级老板会有疑问都做过什么项目,我怎么一直不知道这个人呀?这就比较尴尬了。
#### 7. 公司业绩
公司的盈利情况,以及所在领域的大环境是否好,都决定了公司是否有更多的 budget 来支持员工的升职。如果利润微薄,那么晋升的概率就小;满钵满,晋升的概率就大。
公司的盈利情况,以及所在领域的大环境是否好,都决定了公司是否有更多的 budget 来支持员工的升职。如果利润微薄,那么晋升的概率就小;满钵满,晋升的概率就大。
OK如果你能够从以上几个方面分析好自己当前的境遇判断出哪一个因素才是“四年没有得到晋升”的关键抓住重点就能够“解决”这个问题提高自己的晋升概率。
@ -150,7 +150,7 @@ OK如果你能够从以上几个方面分析好自己当前的境遇判断
#### 1. 北京有多少人口?
可以从官方的数据上得知,北京的常驻人口为 2100 万。
从北京市政府2021年5月的第七次人口普查数据上得知北京的常驻人口约为 2100 万。
#### 2. 汽车保有量

Просмотреть файл

@ -15,7 +15,7 @@
我们把应聘者分为两类:一类是真正的人才(应该给 Hire一类是真正的庸才应该给 No Hire。而面试结果也有两种Hire/No Hire。交叉后得到下表
|应聘者$\downarrow \backslash$ 面试结果$\rightarrow$|Hire|No Hire|
|应聘者$\downarrow \backslash$ 面试结果$\rightarrow$|录用(Hire|不录用(No Hire|
|--|--|--|
|真正的人才|A|B|
|真正的庸才|C|D|
@ -24,9 +24,9 @@
- 查准率 $Precision = \frac{A}{A+C}$,如果得到 100% 表示极好,意思是没有放过任何庸才,有“宁可错杀一千也不放过一个”的意思,面试标准较严,有可能误伤人才。
- 查全率 $Recall = \frac{A}{A+B}$,如果得到 100% 表示极好,意思是没有错过任何人才,面试标准较松,当然有可能把庸才也 Hire 了。
- 查全率 $Recall = \frac{A}{A+B}$,如果得到 100% 表示极好,意思是没有错过任何人才,面试标准较松,当然有可能把庸才也录用了。
从目前面试的结果来看,由于有 Smart Interview 的指导,我们很少雇佣不合格的人,也就是 C 值很小,意味着我们面试的准确度很高,可以达到 99%。但同时,由于我们本着宁缺勿滥的原则,所以有一些合格的人才被某些环节过滤掉了,造成 B 值较大,但是由于不能证明这件事,所以也不敢信口开河的说一个数字,但希望它不低于 90%。
从目前面试的结果来看,由于有 Smart Interview(直译为聪明地面试,是公司内的一门面试培训课程)的指导,我们很少录用不合格的人,也就是 C 值很小,意味着我们面试的准确度很高,可以达到 99%。但同时,由于我们本着宁缺勿滥的原则,所以有一些合格的人才被某些环节过滤掉了,造成 B 值较大,但是由于不能证明这件事,所以也不敢信口开河的说一个数字,但希望它不低于 90%。
面试一共 6 轮,由于在后面的 5 轮面试中,误判出现的情况较少,所以第一轮电话面试的准确程度就是决定我们的 Recall 值的关键,这就决定了做为电话面试的面试官的重要性。鉴于我们此次招聘任务的繁重性,第一轮的面试官的选择,同时也决定了我们此次招聘行动的效率。
@ -44,7 +44,7 @@
与对方聊天,以聊天的形式开始你的面试工作,而不是冷冰冰地一问一答,甚至可以在面试过程中很简短地说一个小笑话。不要以考官的身份出现,尽管你现在是一个考官。
以我自己为例我的情况很特殊是经过了两次面试共12轮才成为微软的一员的第一次是在必应地图项目组由于暂时没有 headcount所以以 vendor 身份进入微软,应该在一年后就会自动转为 FTE但是一年后柳虽暗但花未明项目组被 re-org 进入 STC,于是又经历了第二次面试。
以我自己为例我的情况很特殊是经过了两次面试共12轮才成为微软的一员的第一次是在必应地图项目组由于暂时没有正式员工名额,所以以合同工身份进入微软,应该在一年后就会自动转为正式员工;但是一年后,柳虽暗但花未明,项目组被重组入另一个大部门,于是又经历了第二次面试。
回想起那近乎“残酷”的过程,无形的心理压力,失败与成功相隔一线的艰险,实在是冷汗直流。于是乎,有过我这样类似经历的人会分化成两种不好的心理状态:

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 45 KiB

После

Ширина:  |  Высота:  |  Размер: 45 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 54 KiB

После

Ширина:  |  Высота:  |  Размер: 54 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 79 KiB

После

Ширина:  |  Высота:  |  Размер: 79 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 109 KiB

После

Ширина:  |  Высота:  |  Размер: 109 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 66 KiB

После

Ширина:  |  Высота:  |  Размер: 66 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 86 KiB

После

Ширина:  |  Высота:  |  Размер: 86 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 78 KiB

После

Ширина:  |  Высота:  |  Размер: 78 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 151 KiB

После

Ширина:  |  Высота:  |  Размер: 151 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 453 KiB

После

Ширина:  |  Высота:  |  Размер: 453 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 118 KiB

После

Ширина:  |  Высота:  |  Размер: 118 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 78 KiB

После

Ширина:  |  Высота:  |  Размер: 78 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 43 KiB

После

Ширина:  |  Высота:  |  Размер: 43 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 114 KiB

После

Ширина:  |  Высота:  |  Размер: 114 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 82 KiB

После

Ширина:  |  Высота:  |  Размер: 82 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 112 KiB

После

Ширина:  |  Высота:  |  Размер: 112 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 36 KiB

После

Ширина:  |  Высота:  |  Размер: 36 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 114 KiB

После

Ширина:  |  Высота:  |  Размер: 114 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 59 KiB

После

Ширина:  |  Высота:  |  Размер: 59 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 200 KiB

После

Ширина:  |  Высота:  |  Размер: 200 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 68 KiB

После

Ширина:  |  Высота:  |  Размер: 68 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 65 KiB

После

Ширина:  |  Высота:  |  Размер: 65 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 462 KiB

После

Ширина:  |  Высота:  |  Размер: 462 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 105 KiB

После

Ширина:  |  Высота:  |  Размер: 105 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 60 KiB

После

Ширина:  |  Высота:  |  Размер: 60 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 72 KiB

После

Ширина:  |  Высота:  |  Размер: 72 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 45 KiB

После

Ширина:  |  Высота:  |  Размер: 45 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 86 KiB

После

Ширина:  |  Высота:  |  Размер: 86 KiB

Просмотреть файл

До

Ширина:  |  Высота:  |  Размер: 41 KiB

После

Ширина:  |  Высота:  |  Размер: 41 KiB

Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше