怎样才算一个合格的程序猿？

上次更新，还是上次找工作的时候。换工作后实在太忙（其实是借口，主要还是思想上认识不够），就一直没更新。一周前（4月8号），跟汽车行业的一位专家聊了一下，激发了我如下反思：

反思1：只要还在这个行业，今后会持续更新和总结自己，内容不限；写在这里作为自我督促。

反思2：细想起来，过去的东西，还是有很多值得总结的。

今天，说说我眼中怎样才算一个合格的程序猿。简单说，程序猿的工作，就是通过计算机解决现实的问题，即把现实的需求，用程序实现，交给计算机执行。对程序猿的能力要求：一是对现实问题的理解，抽象，分解；二是对计算机工作原理的理解；三是把现实的需求转换为计算机可以执行的东西。可见，这个要求并不低。从两方面具体地来说说，第一方面，面试别人时，我一般怎么来评估？第二方面，在实际工作中，我一般怎么做，或者说，我认为应该怎样做？

在公司里，一直有参与校招、社招的面试。先说校招，公司校招要求较高，笔试和简历等有一个大致筛选；简历中，985/211，奖学金、比赛，成绩都是选择依据，但不绝对。现在很多都参加了各种比赛，含金量和参与程度，仅从简历也不好判断。遇到过本科差一点，硕士期间超级努力的，我个人觉得这种特别好。也遇到过985/211本硕，但实际可能还没做好就业准备的。基本上，我认为，个人水平跟投入的时间和精力是成正比的。IT行业，学习和努力应该是一个持续的过程，活到老，学到老。总之，校招时，通过简历和笔试筛选的，已经很不错了。如果在面试中能进一步证实如下几点，就更好了：

第一点，真正理解笔试中的基础知识（笔试没有作假），对出错的地方能系统地找出原因，查漏补缺；

第二点，逻辑严密，思路清晰，理解、沟通、表达没问题。这时候，应聘者可能就要选择如何表达自己了，复杂或者难以用语言表达，要么不拿出来说，要么用图表等辅助方式。其实，这也跟面试官的知识范围，理解能力有关，甚至跟面试官是否有耐心倾听和引导有关。思路清晰了，逻辑严密了，表达才会清晰。

第三点，性格和善，求真务实，积极主动，热爱学习，其实这很重要。为什么重要呢？工作中，你是否遇到过这样的同事：讨论起来，头头是道，但要他去具体实现，就提各种外部依赖，提各种风险，不具有can-do态度（好像是这个词），能甩给别人做就甩给别人做。反正我最不想与这种人共事，没有担当，简单问题复杂化，无谓消耗太多。或者，遇到下面这种同事没有：比如他负责维护的一份代码，有问题压着时，会深入看看，闲时不去梳理学习理解代码，虽然主动性不够，但比前一种好一点。

第四点，技术方面基础扎实，有良好习惯。其实应聘者技术水平如何，以前的项目参与度如何（不是自己亲自实现，但深刻理解的也算自己的），代码写得多不多，技术面试很容易问出来，需要的话，还可以现场做题写代码。

对于社招，面试难度更大一点，主要难度有：细分领域太多，可能完全不熟悉应聘者的工作；应聘者更善于包装；双方在沟通表达方式和理解上的不同，带来的困难。社招主要看是否有新岗位要求的直接工作经验，或者类似工作经验；也要看上述四点，可以把第一点改成，看简历与真实情况是否符合。

一轮面试，40分钟到1个小时，真的很辛苦，很烧脑，参加过几次集中面试，一天6场+，太累。面试，都会有一定的运气成分，但大体还是能力水平决定了面试结果（面试官整体水平太差除外）。

实际工作中，就更具体了，我一般怎么做的呢？

第一点：我认为程序猿输出的最重要的东西就是代码，最重要的文档也是代码，代码一定要有很强的可读性。有人可能要反驳，写代码最没技术含量，随便找个人培训一下就可以了。我不这么认为，同一个设计方案或者思路，不同人完成的代码有非常大的区别。好的代码，包含合理、优秀的设计，好的编码实现，其实功夫在编码之外，功夫在对于要解决问题的深入准确理解，功夫在于平时的积累。

代码就是最好的文档，命名和注释等细节按定下的编码规范来，注释不能流于形式，对关键的设计和处理逻辑，对关键变量，一定要写出清晰明了的注释，且注释要随代码更新，且一定要是英文（尽量地道的英文表达，中文有可能在不同的编辑器上出现乱码）。

第二点：代码要有基本的质量保证，如C、C++代码至少要保证没有内存等资源泄漏；不能出现栈溢出，不会出现野指针访问等可能导致程序崩溃的问题；清楚哪些要做到线程安全；能做到不包含重复的代码吗（在一个项目中，你是否多次看到完全相同的代码片段）？能保证编译零warning吗（在项目初期就要做到，且不是为了消除warning而强制进行消除，要明白每个warning的意义）？能否通过Coverity等工具的检查（误报除外）？还有安全和隐私方面呢？

第三点：代码一定要可维护可测试，测试驱动开发（TDD）的思想值得拥有。我理解，TDD的精髓是从测试和使用的视角，更准确地定义需求，更准确地界定功能范围。这样，在开发之前，就能明白哪些是支持的场景，哪些是不支持的场景，对好处和局限清清楚楚。采用TDD出来的代码低耦合，高内聚，也更有利于后期维护。

强调一点，TDD是开发人员的一种思维方式，TDD not Unit Test Driven（不要局限在单元测试用例）。尝试TDD，不断加深理解，提高效率。

为什么要强调可维护呢？软件，不是编码就完事，后面还有测试，生产，试用，大规模商用等等，都有可能出现问题。可维护，就能快速定位这些问题（或者甩锅出去哈）。在设计和编码时，都要考虑到可维护性。

第四点：进行持续的优化改进，甚至持续的重构。有人会说，局部的风险可控的优化改进，当然可以做；要进行大范围的重构，很多时候不现实。确实是这样，大的重构对时间精力和能力要求也很高，当然要审慎评估，也可以控制重构的粒度和范围，逐步重构达到目的。

不要过度设计，设计和实现越复杂，就一定越容易出问题；持续的优化和重构，目的是使之越来越简单，而不是越来越复杂，使之越来越便于维护，而不是更难维护；如果发现达不到上述目的，就要转换思路了。10年前，一位外企面试官这样问过我：A software, you wanna it be as good as need or as good as possible? 当然，我的答案是as good as need。我这里说持续改进和重构，也是为了as good as need，也是为了保证输出质量，为了后期维护，甚至为了后续新项目的重用。总之，一切根据实际情况评估。

第五点：凡是可能出问题的地方，大规模量产后一定会出问题。我目前做的是会大规模量产的产品，现实一再证明这一点。所以，开发调试初期遇到的问题，不要轻易放过，要非常重视，因为这时候解决问题花费的代价是最小的。

第六点：逻辑严密，对细节敏感。对细节敏感，应该就是面试考察的数字敏感性。来自工作中的例子，针对非必现问题，特别是低概率问题，我希望测试人员提供发生问题的精确信息（操作的精确步骤，精确时间，看到的精确现象），说实话，目前看来，很少遇到。

写得比较杂乱，以后有时间再把所有文章逐一看看，温故而知新。

[2022年4月19日 成都 创建]

[2022年4月22日  成都 更新]