前言
在当今社会中，'码农'似乎已经成为了会写代码这一群体的统称。但是会写代码，和能写好代码有着完全不同的含义。
汉娜·阿伦特在《人的境况》中将人类的活动分为劳动（Labour）、工作（Work）和行动（Action）。阿伦特认为，'劳动'的目的是维持生命，其成果是消耗品，因为劳动必须是周而复始的；而'工作'的目的是建立世界，其成果是可持续的，因此，'工作'是一劳永逸的。从事'工作'的人，阿伦特称为'技艺人'。
而'码农'与'软件工程师'之间的区别，正是阿伦特在《人的境况》中，对'劳动'与'工作'的最好诠释。
'码农'与'软件工程师'的定义与职责
所谓'码农'，一般指代那些能够编写代码和擅长编写代码的人。他们可以运用各种编程语言，实现特定的功能、修复错误，并进行基本的单元测试。这样的一群人，在项目中扮演着重要的角色，但他们的职责受限于具体的编码工作，往往关注于如何完成分配的任务，而非任务背后的业务价值或系统长远影响。
然而，与'码农'相比，'软件工程师'这个称谓需要具备更高级的技巧与责任。软件工程师的基本素质就是，必须具备良好的代码编写规范、风格、正确性、安全性、稳定性、可复用性和可读性。更重要的是，要具备需求分析、系统设计、编写文档、项目管理、代码评审，以及研究的能力。软件工程师不仅关注代码的实现，更关注系统的整体架构、可维护性以及技术决策对业务的长期支撑。
'软件工程师'的特征
在这一节，我们将会看到'软件工程师'所具备的一些具体的特征，以及对这些特征的论述。
1. 积极主动性与综合能力
'软件工程师'不仅仅是被动执行任务的人，需要具备积极主动的精神和能力，能够主导和推动软件开发项目的进展。能够独立思考，并提供解决方案，具备良好的问题解决能力和决策能力。此外，'软件工程师'还具备广泛的知识和技能，不仅了解编程语言和开发工具，还要了解软件开发的各个阶段的相关技术。
在《如何阅读一本书》当中，也给出了被动和主动的论述。一个被动阅读的人，很容易在遇到阅读困难时打瞌睡，而积极主动的人，很少会出现这种情况，并且，这些人是带着问题阅读的，在阅读的过程中，会记录遇到的问题，并在整个阅读过程中，进行自我求证，从而提升理解力。在工程实践中，这意味着工程师不应等待指令，而应主动发现潜在风险，提出优化建议，并推动技术方案的落地。
2. 需求分析
在《代码的艺术》中，章淼老师这样描述道：需求分析定义系统/软件的黑盒行为，它是从外部看到的，在说明'是什么（What）'。
下面给出一个简单的需求描述的示例：'匹配服务的设计目的是，基于玩家的排位赛的积分、胜率（当前赛季、过往）、失败率（当前赛季、过往）、常用英雄等因素，尽可能地将竞技水平相近的玩家撮合在一场比赛当中。'
从上面的需求描述中，我们大致可以分析出策划的几个需求要点：
- 玩家匹配的数值参考维度，涉及当前赛季的排位赛积分；当前赛季和历史赛季的胜率及失败率；玩家在当前赛季经常使用的英雄（代表玩家想玩上路、下路、中路，或者打野，游走或辅助）。
- 公平性，策划希望尽可能的将竞技水平相近的玩家匹配到同一场比赛当中。
- 长时间匹配不成功时，需要扩大玩家的匹配分数范围么？又或者，需要用机器人来代替玩家来开启一场比赛吗？
从技术的角度，我们也应该得出几个需求要点：
- 匹配服务的部署方式：需要分布式部署吗？需要按照不同的玩法部署吗？（匹配赛、排位赛、火焰山等等）。需要让不同的匹配服务，负责不同分数的玩家之间的匹配吗？
- 匹配服务的承载量：硬件的配置是什么样的？（CPU 型号、内存等等）。同时需要处理的玩家请求并发量是多少？完成一场战斗匹配，消耗的时间单位是什么，以及具体时间。
- 匹配服务宕机：当服务宕机时，受影响的玩家范围，我们的容忍度是什么样的？如何快速地拉起挂掉的服务，为玩家提供正常的服务和游戏体验。
- 对外接口：我们可以提供哪些接口，以及这些接口为谁提供？比如为游戏服务提供的匹配接口；为运维提供的指标接口。
- 匹配服务的适用范围：我们是为具体的某一款游戏提供匹配服务，还是可以为任何游戏提供匹配服务。匹配机制的算法，是可以由具体的游戏业务自定义的吗？还是由匹配服务提供内置的匹配算法，或者两者兼具。
软件工程师，必须要掌握需求分析，并且在评审环节提出质疑，比如设计的合理性。而需求的合理性，不应该仅考虑实现的难易程度、时间成本等因素，更应该考虑的是'回报率'。而就我接触到的很多团队，还停留在难度较大、时间成本较高等问题上，很多需求因为这些原因被认为是不合理的。优秀的工程师会评估技术债务，权衡短期交付与长期维护的成本。
3. 系统设计
在《代码的艺术》中，章淼老师这样描述道：系统设计设计系统/软件的白盒的机制，它是从内部看到的，要说明'怎么做（How）'和'为什么（Why）'。
在维基百科中，系统设计的定义是：系统设计是定义系统的架构、模块、接口和数据以满足特定需求的过程。
