【技术修养】关于工程素养

引言

我是学软件工程专业的，大学那会，软件工程是我们的必修课，有3个学分。教那门课的老师经常提醒我们，作为软件工程专业的学生，你们得有工程能力。造一架飞机是一个工程，挖一条隧道是一个工程，做一个软件也是一个工程，得有工程师的思维，得有全局意识。

老实说，这些话，我到现在也是一知半解。

写这篇文章仅仅是对自己目前的所学的一个小的总结，仅仅从个人的角度，聊聊一个软件工程师，特别是后端软件工程师，需要具备咋样的工程素养。此篇也是自己对相关知识体系的一个简单梳理，用于后面自查。

计算机基础知识

基础知识是作为一个程序员的内功。基座得搭好，上层建筑才稳当。这些知识自己也都还在不断学习之中，简短称述一下以自勉。

操作系统与计算机组成原理
计算机网络
数据结构与算法
编程语言
软件架构+数据库+中间件+领域知识
实践能力+工具链使用

开发规范

项目结构规范

搭建项目软件开发的第一步，如何划分是个细致活。对于 java 而言，看过的很多项目结构都大差不差，对于 go lang 而言，就有不少分歧。举个简单的例子，比如 golang 的项目中，不少开源的论坛和文章中倡导去掉 dto 层，利用 golang struct 中的 tag 来做扩展，来定义 dto 的返回对象字段(reference: Stop Using DTOs in Go, It’s Not Java)。golang is not java！(😂)

这里简单陈列下网上 java 和 golang 的项目结构（仅做参考）

编程语言规范

一些开源的代码规范。

java
- Google java 风格指南：https://google.github.io/styleguide/
- 阿里巴巴java开发手册：https://github.com/mysterin/alibaba-java-specification/blob/master/alibaba-java-specification.md
- 腾讯 java 安全指南：https://github.com/Tencent/secguide/blob/main/Java%E5%AE%89%E5%85%A8%E6%8C%87%E5%8D%97.md
golang
- Google golang 风格指南：https://google.github.io/styleguide/
- Uber golang 风格指南：https://github.com/uber-go/guide?tab=readme-ov-file
- 腾讯 go 代码规范：https://www.cnblogs.com/xuweiqiang/p/15337132.html
- 腾讯 golang 安全指南：https://github.com/Tencent/secguide/blob/main/Go%E5%AE%89%E5%85%A8%E6%8C%87%E5%8D%97.md

Git 规范

好的代码提交规范是项目的生命线。

【git 分支与代码提交规范】

小批量代码提交，每次代码提交时尽可能<=400行

【git commit log 规范】

通用Commit Message 格式如下。

目前规范使用较多的是 Angular 团队的规范 , 继而衍生了 Conventional Commits specification. 很多工具也是基于此规范, 它的 message 格式如下:

<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>

备注：

git commit 提交时需要换行时，请使用Bash命令行的Git，你可以执行以下操作：
1
2
3
4
>git commit -m "this is
>> a line 
>> with new lines
>> maybe"
-m 后面使用双引号

换行时，直接按回车enter键

log输入完后，输入“ ，再回车就可以commit成功了

简单汇总：

Reference:

CodeReview

当我在CR的时候，我在CR什么？

硅谷的知名互联网公司，都搞merge request/push request合入mainline之前的code review。Google为了保证review质量，还搞了Readability认证。网上有很多资料、报道有讲解到。Google在公开网站上也有说到。

Code Review 的大方向

code review

Reference:

代码坏味道

写一份好的代码，拒绝坏味道。

Reference:

主干开发？大仓小仓之争？开发流程理念的理解

在我人生第一家公司那里，我第一次了解到了大仓的概念。依稀记得当时公司内有很多大仓小仓的讨论，是屠龙术还是前朝宝剑斩今朝的官，大家各说纷云。不管用哪种，都了解一下其中的利弊，也挺好的。

Reference:

项目管理能力

不要只是低头写代码，有时候，也得抬头看看上下游，看看这艘船到哪了。

需求分析要透彻
协调上下流的沟通能力
能合理规划开发流程和进度
及时暴露问题

Reference:

人月神话

文档撰写能力

绝大部分的程序员都讨厌写文档，但又讨厌别人不写文档。

个人的理解上，我们需要掌握以下文档的编写：

需求分析文档：一般产品会写需求文档PRD，但是作为程序员，我们也应该具备撰写需求分析文档的能力。
架构设计文档：对项目的整体架构设计
技术设计文档：仅需要概要设计文档，详细设计就是代码本身
API参考文档（reference doc）一般由代码直接生成。它的量是最大的，变更最频繁的
SDK或者框架使用文档/教程：自己封装的SDK、框架等，写个详细的教程传递出去，让更多人用
技术分享文档：个人的技术输出，当然了，很多时候也用 PPT，我更喜欢用文档。
Readme文档：每个项目的介绍文档，这个还挺重要的，一份好的 readme 就是一个项目最好的”个人简历”
新人文档：帮助团队新同学快速了解团队工作内容，快速融入。我个人认为这个很重要，一份好的新人文档也相当于对自己团队的工作内容总结和工作要求说明。

Reference:

测试能力

作为一个有责任心的程序员，从来不是写完代码就完事了。我们得保证代码的质量，除了依靠测试同学的努力，自身也得投入部分精力。据我所知，现在很多大厂都会要求编程人员写单测，搞测试左移，这也被称之为 TDD，即测试驱动开发。这种做法是否有效，有多大效果我这里不想高谈阔论。但是我个人觉得，自己写的代码，自测的质量是一定要保证的。