工作内容

上篇博客提到了我工作的内容，这篇会比较详细的写一下工作内容以及我在这一年多工作过程中的感悟。

面试

团队中，有人来有人走，所以我们也经常面试候选人。起初，我问的问题是比较具体和细节的，说实话，很多是我从Google里搜到的一些面试题，这种一般是有确定性答案的问题。有些人回答的并不好，但是他却是perfect match，有些人回答的很好，甚至一字不漏，但他并不是一个很合适的人。

参加了几场面试过后，我发现两位tech lead喜欢问的是比较开放性的问题，更倾向于规范和实际场景。比如，其中一个人经常问的问题是，「如果现在的代码库里，有一个1000行以上的dart文件，里面穿插着很多UI相关代码，你如何优化代码结构？」 这个问题，就可以很好的区分出初级工程师和中高级工程师。

面试者群像

后来除了一些关键性的Flutter特定问题和dart特性，我也开始加入一些开放性的问题，来考察应聘者。考虑到很多应聘者是从原生开发、前端开发甚至UI设计师转Flutter的，并没有实战经验和机会，所以我最经常问的一个问题是：「Flutter有很多issue甚至bug，在你开发过程中，遇到了哪些SDK层面的bug呢？你是怎么解决或绕开它的。」 这个问题，确实是一块试金石，能很好的区分出应聘者到底有没有真正在实战中使用过Flutter。另一个我经常面试的问题是，「在过去的工作中，你解决的比较困难的问题是什么？」有人的回答确实惊艳到了我，但大部分人都说没遇到什么困难，或者都是Google能搜出答案的那种。惊艳到我的答案是，他想给他建筑师的父亲写一个3D建模软件，但是没找到好用的渲染引擎，于是他自己写了一个，现在github有2000多个star了。

面试中，记忆最深刻的内容其实上一篇已经写了，那就是一个十多年的Senior Programmer but Junior engineer，他说过去十多年里面没遇到很困难的问题，再谈到开放性问题的时候，也是没太多可讲的。这对一个拥有十多年开发经验的老手来说，肯定是不可接受的。

Engineer(工程师) VS Programmer(码工)

另一个印象比较深刻的是一个以色列小伙，才20岁出头，没有在大学接受教育，自学成才，技术方面的问题跟他沟通很顺畅，对不少问题也都有很深刻的见解，所有人都对他很满意。技术之外，我们也喜欢他积极主动的态度，据他说，受其工程师父亲的影响，他每天6点就起来开始学习和工作了，十年来从未停止过。很可惜，最后他没有加入我们team。

面试中学到的大概是第一要技术过硬，有良好的解决问题的能力；第二是态度积极主动，对做过的项目要非常熟悉；第三是要尽量将自己定位成一个Engineer(工程师)，而不是Programmer(码工)。

在国外，工程师和科学家是类似的名词；在国内，码工似乎和工人成了类似的名词。

工程方面

面试是工作的插曲，最主要的还是做工程。在这个项目从0到1的过程中，经历了完整的项目过程；设计，架构，编码，测试，上线，fastlane CI/CD。

写文档

写文档是极容易被忽略的一个环节，但是不可否认是很重要的。好的文档可以让别人知道你想怎么做一件事，而且也可以让你在动手之前想清楚准备怎么做，也可以让后面加入的成员快速熟悉你所写的模块。

我最满意的文档截图，清楚的解释了Janus的步骤

Tech talk

Tech talk是每个组员做PPT来讲解自己某个方面的心得或者某个我们组准备新引入的设计模式，大家充分交流，留够Q&A时间。每次都会有录屏，我都会回看3遍左右。

编码和Review代码

关于编码，Tech lead的要求是让这个项目看起来就像是一个人写的。我们尽量遵循相同的代码风格、命名规则等，使用了Dart format这个工具来规范code style。

将代码提交为Pull Request供其他人review，至少2个Agree的PR才会被merge到QA Branch上。关于PR，要求一个PR代码不要太多，且只涉及单个模块，否则其他人很难做代码评审，遇到这种情况，应该将功能拆分为多个小的PR。

高手Review我的代码，是让我感觉我这一年进步很大的最关键途径。开始的时候，我总是针对某个任务进行编码来解决某个问题，其他人就会提醒我，从更全局的层面去考虑问题，解决某类问题。

除了自己编码，也有需要pair programming的时候，比如某个新特性，涉及你和他之前写的模块，就需要跟同事约好时间，分享自己的屏幕给对方，直播写代码，遇到他有疑问的时候，会打断你，总体还挺有意思的。

这一年，我从其他开发者身上学到的主要有以下几点：

1. 对整体项目结构必须了如指掌，把代码放在正确的地方
2. 让你的代码简洁而优雅，使得其他团队成员可以读懂代码并理解它打算做什么，必要的时候多写注释
3. 实现某个功能过程中，多考虑考虑里面有没有可复用的代码，抽出来成为其他模块可用的组件或方法
4. 每个工厂日都要有Commit，不要积攒到一起让别人不知所措，产生大量冲突
5. 礼貌地对待别人的review意见，不卑不亢。tech lead也不一定全对，因为他很可能并没有你了解你PR这块业务这么深刻。出现分歧后，在你发表意见时，不管对方是谁，都要尊重对方，耐心说服对方或被对方说服。
6. 从错误中学习，以免下次再犯类似错误。

经过小半年的磨合，我的代码规范了很多，PR一次性通过率提升了不少，解决问题的能力也得到了提升，也得到了Tech lead的肯定。记忆最深刻的是一个目前没有很好的方案，Tech Lead也不知道怎么办的问题被我比较好的解决之后，他对我大加赞赏。

世界上最美好的事情除了你喜欢的人也喜欢你，还有你认为牛B的人也认为你牛

中篇总结

本文介绍了我过去一年在具体工作中的一些总结与思考，不涉及技术细节，比较宏观和主观，不一定正确，请一定要辩证地来看。

———————————中篇完结，未完待续———————————