浅谈工程师思维、工程师素养

我平时会关注一些技术相关的公众号，这些公众号有的时候会推一些课程，这些课程总是那么前篇一律，许诺高薪，贩卖焦虑。你知道对于年轻人来说，贩卖焦虑是好用的，因为很少有年轻人不迷茫。之前在掘金看沸点的时候，看到过一张图，要找现在也找不到了，说是JS工程师现在什么都得学，node.js学后端，Tensorflow.js人工智能等等，底下的评论倒是很有意思，有个人这么评论道: 都是同行，就不必在贩卖焦虑了吧。毕竟很少有人能够全面开花，专精一个领域，尚且很少有人做到。本篇文章你也可以理解是杂感。

工程师思维与工程师素养

毕业之后的编码常让我想起大学期间的《软件工程导论》, 老实说当时由于编码经验比较少或者说代码量比较少，在学这门课的时候，我觉得书里面写的都是些什么啊？ 理解不动啊! 但也认识了一些名词敏捷开发、耦合、内聚、职责单一，但对于这些词，我总是似懂非懂。我想不懂的原因大概是自己没有构建系统的经历吧，平时写的程序也就是算法级别的，代码量很少。当你真正的参与构建一个系统，你才会发现这些东西无所不在，事实上这也是我司架构师经常对我讲的事情。所以我觉得学习《软件工程导论》这门课之前，学生必须参与构建一个小型的软件工程，学习这门课会更顺利。

什么是工程师思维？什么是工程师素养?如何构建一个良好的系统？ 这是我在看过形形色色的工程之后，自己问自己的一个问题？我看过许多课程，这些大致都是讲技术本身的，而不是讲如何用技术如何去构建工程？这也是目前开发中不知道怎么兴起的风气？ 上来就是高并发，别问，问就是多线程，好的我给你讲讲微服务，来吧，我们看看HashMap的源码。这些东西在java程序员的面试中相当常见，不少刚入门的人不明所以就会讲这些视为方向，我觉得这个倒是程序员中的浮夸风，我之前因为找一些资料的缘故，加了一些QQ群，那么QQ群中求什么资料最多呢? 我印象里应该就是多线程和高并发的。很多资料会教你如何使用，但是很少有资料教你如何合适的使用。这也就是我想谈的软件工程师思维与软件工程师素养，悄悄的说一句，我讲的不会考，只讲体会。

宏观与微观 整体与局部

微观就是技术实现，这个讲倒是很多，这里我想说的是宏观，也就是从项目的总体结构上去考虑问题，这也是初级程序员很少会去思考过的。因为很少有人用自己的闲暇时间去自己打造一个项目，可能平时会去买一些课程看看源码，看看新技术，看看面试题，但是很少会有人用自己的闲暇时间去打造一个开源项目。这里可能讲的有些抽象，其实就是想说当你自己用心打造一个项目的话，收获是巨大的，此时你是设计者，这个过程你就会碰到很多问题，比如确定系统的工程结构和业务结构，根据业务拆分模块，这可能是平时架构师思考的问题。如果你做过这种设计，那么你考虑问题的时候可能就不仅仅是从所属模块上考虑问题，而是从整个项目的结构上去思考，去设计。因为局部最优，未必整体最优。此时你再去看《软件工程导论》时也许会有新的认知。

这也就是一个维度的问题，初级程序员相对于高级的程序员有的时候差的可能就是一个维度，高级程序员可能考虑功能的时候就是从整体和局部两个维度出发，眼光不仅仅在功能实现上，还考虑此功能对所属模块的影响，对整个项目的影响。

对架构的认知

我们知道一般情况下是根据业务来确定工程结构，有的人可能更喜欢架构这个词，可能这个词更高端。这一点我在《且谈软件架构》已经阐释过了，架构和结构事实上是同义语，我个人更喜欢结构一词，我觉得更清晰。当你面前摆放形形色色的框架、组件、中间件，你该如何去选择，如何去设计？如何选用合适的架构去降低代码的复杂度，是不是都要上微服务架构? 可能对不少新手来说，软件架构目前就只有微服务，可能有人还会讲SOA，就我个人认为，SOA和微服务区别不大，软件届对某一种架构是什么形成共识。

其实不仅仅是代码结构，还有业务结构，这两者都很重要，两者越是契合，那么这么这个软件就越是生机勃勃。

对耦合与内聚的认知

什么是耦合呢？我记得在学Spring框架的时候，老师首先从解耦合史开始说，事实上说来惭愧，我当时对耦合的肤浅认知就是，改动了一个模块，会影响到一个模块，可是我当时想这不是理所当然的吗？但是后来慢慢认知到，高耦合不利于维护，假如一个软件由A、B、C、D三个模块组成，那么假设此时A模块改动了一下，连带着B、C、D这三个模块都要改动，这显然是不利于协作和维护，这些模块不够职责单一。改动了A模块，B、C、D模块也要顺着改，那么显然这些的模块都负责了多项事情，除了那些A模块专门用来和B、C、D协作的功能，A模块的功能要尽可能的职责单一，说到这里让我想起了设计模式，设计模式大多也是用来松耦合的，但是切记不要为了松耦合而松耦合，还是要从业务需求以及系统定位触发，满足一段时间内系统的发展需要即可。

好好考虑变动

不应该以聪明才智和逻辑分析能力来评判程序员，而是要看其分析问题的全面性。--《C语言程序设计现代方法》

建筑商从来不会像给一栋已建好的100层高的楼房底下新修一个小地下室——这样做花费极大而且注定要失败。然而令人惊奇的是，软件系统的用户在要求作出类似改变时却不会仔细考虑，而且他们认为这只是需要简单编程的事——《面向对象分析与设计》 Grady Booch著

各位，在软件开发领域，变更需求是常有的事，不是所有的变更需求都是合理的，也不是所有的的变更需求都是不合理的。对于实现者来说，你就需要评估变动对整体的影响，有的看起来是一个很小的变动，就会在整个系统掀起一场龙卷风。

良好的编码素养

现代的IDE已经能够良好的支持代码扫描插件的，我建议各位装一下，约束一下自己的行为。《软件工程导论》中有不少关于编码的经验，不过比较杂，可以去看看《代码大全》和《代码的整洁之道》，我看的时候比较有针对性，直接看编码建议和面向对象设计原则。我目前感受比较深的一条就是职责单一，为什么我单独提这一条呢？因为我就是心里清楚，但是没有去落实，没有贯彻到底，导致后续维护的时候有些小头疼，可能我装了南墙才会回头吧。

定位问题

开发过程中会遇到许多形形色色的问题，其实不碰见问题才是不正常的事情，但是遇到了问题不要慌，拍个照，发个朋友圈。
首先你要定位问题在哪里，然后定义清楚这个问题，然后开始思考解决这个问题。多数人可能就卡在定位问题和定义清楚问题这里，我平常写代码是很稳的，我记得是哪一次项目比较急，一串很长的SQL报语法问题，我定位了很久都没有找到，我就去问我司的架构师去了，架构师先跟我讲: 小伙子不要着急，碰到急事，拍个照发个朋友圈。然后还是一点点的定位问题，这里充分的让我认识到了一点就是写代码不要慌。

总结一下

这也是我这段时间编码的认知，我从刚开始的只关注业务实现，开始从系统的整体结构上考虑问题，开始去认知业务结构与代码结构，仔细思考引入变动的影响，开始审视自己的代码，开始试着帮别人去解决问题。这是我认为的工程师思维与工程师素养，也算是杂感吧。其实这个题目有些大了，不过我想我讨论应该是通用的，比如说系统的结构性，我想这并不仅仅是软件领域所独有的。