文章目录

前言
一、Python入门
二、Python爬虫
三、数据分析
四、数据库与ETL数仓
五、机器学习
六、Python高级进阶
资料领取
好文推荐

前言

在当今社会中，“码农” 似乎已经成为了会写代码的这一群体的统称。但是会写代码，和能写好代码有着完全不同的含义。

汉娜·阿伦特在《人的境况》中将人类的活动分为劳动（Labour）、工作（Work）和行动（Action）。阿伦特认为，“劳动” 的目的是维持生命，其成果是消耗品，因为劳动必须是周而复始的；而 “工作” 的目的是建立世界，其成果是可持续的，因此，“工作” 是一劳永逸的。从事 “工作” 的人，阿伦特称为 “技艺人”。

而 “码农” 与 “软件工程师” 之间的区别，正是阿伦特在《人的境况》中，对 “劳动” 与 “工作” 的最好的诠释。

02、“码农” 与 “软件工程师”的定义与职责

所谓 “码农”，一般指代那些能够编写代码和擅长编写代码的人，他们可以运用各种编程语言，实现特定的功能、修复错误，并进行基本的单元测试。这样的一群人，在项目中扮演着重要的角色，但他们的职责受限于具体的编码工作。

然而，与 “码农” 相比，“软件工程师” 这个称谓需要具备更高级的技巧与责任。软件工程师的基本素质就是，必须具备良好的代码编写规范、风格、正确性、安全性、稳定性、可复用性和可读性。更重要的是，要具备需求分析、系统设计、编写文档、项目管理、代码评审，以及研究的能力。

03、“软件工程师”的特征

在这一节，我们将会看到 “软件工程师” 所具备的一些具体的特征，以及对这些特征的论述。

1.积极主动性与综合能力

“软件工程师”
不仅仅是被动执行任务的人，需要具备积极主动的精神和能力，能够主导和推动软件开发项目的进展。能够独立思考，并提供解决方案，具备良好的问题解决能力和决策能力。此外，“软件工程师”
还具备广泛的知识和技能，不仅了解编程语言和开发工具，还要了解软件开发的各个阶段的相关技术。

在《如何阅读一本书》当中，也给出了被动和主动的论述。一个被动阅读的人，很容易在遇到阅读困难时打瞌睡，而积极主动的人，很少会出现这种情况，并且，这些人是带着问题阅读的，在阅读的过程中，会记录遇到的问题，并在整个阅读过程中，进行自我求证，从而提升理解力。

2.需求分析

在《代码的艺术》中，章淼老师这样描述道：

需求分析：定义系统/软件的黑盒行为，它是从外部看到的，在说明 “是什么（What）”。

下面给出一个简单的需求描述的示例：“匹配服务的设计目的是，基于玩家的排位赛的积分、胜率（当前赛季、过往）、失败率（当前赛季、过往）、常用英雄等因素，尽可能地将竞技水平相近的玩家撮合在一场比赛当中。”

从上面的需求描述中，我们大致可以分析出策划的几个需求要点：

1.玩家匹配的数值参考维度，涉及当前赛季的排位赛积分；当前赛季和历史赛季的胜率及失败率；玩家在当前赛季经常使用的英雄（代表玩家想玩上路、下路、中路，或者打野，游走或辅助）

2.公平性，策划希望尽可能的将竞技水平相近的玩家匹配到同一场比赛当中。

3.长时间匹配不成功时，需要扩大玩家的匹配分数范围么？又或者，需要用机器人来代替玩家来开启一场比赛吗？

从技术的角度，我们也应该得出几个需求要点：

1. 匹配服务的部署方式：

需要分布式部署吗？

需要按照不同的玩法部署吗？（匹配赛、排位赛、火焰山等等）。
需要让不同的匹配服务，负责不同分数的玩家之间的匹配吗？

2. 匹配服务的承载量：

硬件的配置是什么样的？（CPU 型号、内存等等）

同时需要处理的玩家请求并发量是多少

完成一场战斗匹配，消耗的时间单位是什么，以及具体时间

3. 匹配服务宕机

当服务宕机时，受影响的玩家范围，我们的容忍度是什么样的？

如何快速地拉起挂掉的服务，为玩家提供正常的服务和游戏体验。

3.对外接口

我们可以提供哪些接口，以及这些接口为谁提供？比如为游戏服务提供的匹配接口；为运维提供的指标接口。

4.匹配服务的适用范围

我们是为具体的某一款游戏提供匹配服务，还是可以为任何游戏提供匹配服务。

匹配机制的算法，是可以由具体的游戏业务自定义的吗？还是由匹配服务提供内置的匹配算法，或者两者兼具。

软件工程师，必须要掌握需求分析，并且在评审环节提出质疑，比如设计的合理性。而需求的合理性，不应该仅考虑实现的难易程度、时间成本等因素，更应该考虑的是 “回报率”。而就我接触到的很多团队，还停留在难度较大、时间成本较高等问题上，很多需求因为这些原因被认为是不合理的。

3.系统设计

在《代码的艺术》中，章淼老师这样描述道：

系统设计：设计系统/软件的白盒的机制，它是从内部看到的，要说明 “怎么做（How）” 和 “为什么（Why）”。

在维基百科中，系统设计的定义是：系统设计是定义系统的架构、模块、接口和数据以满足特定需求的过程。

因此，我们可以得出这样的一个结论，系统设计的要点包括：架构、模块、接口和数据。

而系统设计，在很大程度上依赖于需求分析。另外，章淼老师也表示，关键算法和系统设计思路也应该包括在其中。因为，他觉得过程要比最终的结果更重要，目的是为了后来者。我对此也非常地赞同。

4.项目管理

在《软件开发的 201 个原则》一书中，第127条原则指出，好的管理比技术更重要。

项目管理，并不是团队领导者，和产品管理者的职责，也是 “软件工程师” 应该具备的能力。

在传统的概念中会明确的区分：“管理者” 和 “执行者”，然而，这种理念已经无法满足现代社会的需求。在《卓有成效的管理者》一书中，明确指出 “每一位知识工作者其实都是管理者”。主要表达的思想就是，我们必须像管理者一样去工作和思考。而这种能力是需要长期培养的，不能是在 “软件工程师” 变成领导之后，立刻就获得的。这也是为什么如今的软件开发团队中的领导能力被认为普遍不足的一个原因。

项目管理需要考虑的维度包括：成本、时间、范围、质量。

在《软件开发的 201 个原则》一书中，同时也指出，人和时间是不可互换的。

在中途通过增加人员来提升开发进度的想法，在很大程度上会导致项目的进一步延期。因为，这些新进来的人与之前项目中的人，他们对项目的理解和熟悉程度是不一致的。这就需要以 “老” 带 “新”，这样的成本会被无限地放大。所以，随着中途加入的人员的数量，时间成本可能会是 “指数” 级别的增长。

最后，关于项目总结，我们要做到如下几点：责任明确、周密策划、实事求是、质量第一、沟通协作、严密跟踪、控制风险、把握节奏、做好总结、不断提高。

5.沟通能力

在沟通的过程当中，我们发现不同部门之间对同一个 “事务” 给出的定义是不同的，甚至在同一个部门内部也经常发生这种情况。基于大家的理解程度和能力的不同，对同一事物的看法和结论自然也不相同。

在项目启动前，我们必须要对相同的 “事务” 给出相同的定义，在需求分析方面也要达成一致。在得不到这样的结果前，一定不要忙于开工，这会给日后的工作带来非常大的困难和挑战。

沟通能力，可以通过编写文档、阅读优秀的文档、文献或读物来提升。经常性地在有条理的条件下，与其他人交流。

6.代码评审

代码评审也是 “软件工程师” 应该具备的一个非常重要的能力。但在很多团队中，代码评审的环节经常是被忽略的，并且没有包括在开发计划当中。即使，个别团队有这样的机制，很多评审人也仅仅是粗略的扫一遍语法、编码风格问题，对架构、设计、模块、数据、质量、逻辑等方面几乎从未考虑，这种评审就是无效评审，毫无意义，评审人也不对最终的评审结果负责。

另外一种情况，更为可怕。评审人因为所谓 “人际关系” 的考虑，不敢正面指出代码存在的问题，最终导致产品质量的下降。代码评审的重中之重就是，在公平、公正的前提下，保证代码的质量第一，不要参杂任何其它因素。