我对@rana_kualu在2018年成为顶级后端工程师的翻译文章非常感兴趣，但在文章中提供的路线图中，我也感到有些微妙的不适之处。

• 記事に記載されているスキルは現場でどの程度必要なのか

 

記事に記載されていないが現場において重要なスキルは何か

我尝试写下了关于这个话题的一些观点，并夹杂了一些我自己的意见。

我不觉得自己是最先进的工程师，但我觉得自己至少稍微跟上了最近后端的趋势，希望对年轻人或经验尚浅的工程师们有所帮助。

话语

只需要一个选项。但是，作为助手我在下面提供了两个不同的例子。

1. 在路线图中提到的语言中，我基本上是一个。
2. 在路线图上列出的语言中，我归属其中的一种。

• Elixir

 

• Scala

 

• Java

 

• .NET (C#とVB.NET)

 

• Python

 

• Ruby

 

• PHP

 

• TypeScript

 

• Golang

 

Rust

就这方面而言，我在“工作”方面有数个月以上的使用经验，而不是在“私人”方面。（除此之外，我还有服务器端Kotlin的经验）
在这个范围内，我没有“私人”使用的经验，但是我在“工作”方面使用时间已经是数个月以上了。（除非另有说明，我还有服务器端Kotlin的经验）

虽然有一些用例与其他语言相似，但也有一些用例与之不同。根据我的个人观点，

• 動的型付けのスクリプト言語(Python/Ruby/PHP等)

 

• 静的型付けのコンパイル言語(Golang/Rust/Java等)

 

静的型付けの関数型コンパイル言語(Scala/Haskell等)

我认为，对于上述的三种编程语言，只需要至少掌握其中一种（例如Python/Golang/Scala等），就足以满足需求了。

反过来说，例如“只有脚本语言的经验”或“只有编译型语言的经验”，又或者“只想做这种语言”的话，那将相当不平衡，或者说在掌握各种新技术的过程中，语言可能成为一种“瓶颈”或“束缚”，所以对于语言而言，一方面要“认真学习必要的知识”，另一方面要保持“不过分固执”的态度，这样可以拓宽自己的发展空间。

假设将来有一个非常有吸引力的项目，你想参与进去，但这个项目的要求是必须有“编译型语言”的经验，那些只有脚本语言经验的工程师可能会被排除在外。如果你有“除函数型语言之外就不想做”的坚持，那么即使项目的其他方面非常吸引人，你也可能错失参与的机会，有点可惜的感觉。

顺便提一下，对于Web行业的后端工程师来说，.NET（C# / VB.NET）语言几乎没有太多的用途，因此我认为可以忽略它而没有问题。（尽管我认为对于对应用程序开发也感兴趣并希望尝试使用Xamarin或Unity的人来说是另一回事）

软件包管理器

目前为止，相当多的编程语言都采用了以◯◯File和◯◯File.lock的组合方式进行包管理。因此，如果对这种方式有所熟悉的话，就足够了。最近，Python也逐渐流行起了一种名为Pipenv的包管理器，也是采用了上述方式。

只是，考虑到 JavaScript（TypeScript）在 Web 行业中的重要性（无论是在服务器端、前端还是应用程序开发中都会使用），我认为了解npm会给自己带来很多好处，所以即使在工作中没有使用的机会，个人还是应该花时间学习。

如果对Scala的sbt或者Java（Kotlin）的gradle等不感兴趣的话，我认为没有必要在个人时间内去学习它们。

安全性

我认为对于这个问题，由于它非常深入，所以不可能完全理解，但至少在掌握SQL注入、XSS、CSRF等基本脆弱性攻击的防范方法后，

• 重要な情報はデータベース等に平文で保持しない(必ず暗号化する)

 

• 秘匿情報をGithub等のソース管理サービスにアップしない(.envや環境変数を活用する)

 

• クラウド(AWSやGCP)上ではIAM等を使用したアクセス制御をなるべく細かく行っておく

 

常時SSL化

我认为也需要理解这些相关的方法。

当然的是，如果不正确设置安全性，就会导致服务或公司的破产。但是，如果安全要求过于严格，会导致开发效率非常低（也可能导致工程师离职），所以需要根据服务的重要性进行相应的安全设置，并且在这方面要有一些妥协措施是很重要的。

考试

• Rspec(Ruby)

 

• unittest(Python)

 

• testing(Golang)

 

• ExUnit(Elixir)

 

ScalaTest(Scala)

在所负责的项目中使用的各种语言的标准测试框架的使用方法，需要尽可能详细地了解各个细节（例如夹具设置方法、setup和teardown的适用范围等），但是由于各种测试框架基本上有相似之处，如果熟悉一个测试框架，应该能比较容易地理解其他语言的测试框架。

除了了解单元测试和集成测试的区别外，了解依赖注入（DI）的概念以及使用依赖注入进行测试的方式也是工程师必备的知识，同时对于Test Double、Mock、Stub、以及状态驱动测试和交互驱动测试的使用情况也应当有一定的理解。

DI・DI容器，你真的能理解吗？- Qiita
测试替身- 维基百科
模拟对象和存根的区别- 状态驱动的测试 – [lib]
模拟对象和存根的区别- 相互作用驱动的测试 – [lib]

个人的观点是，关于依赖于数据库、外部存储等功能的单元测试，我认为有两种方式可以处理：一是使用模拟（Mocking）来应对，二是使用在本地环境中搭建的虚拟外部服务。然而，由于 Docker 等技术的出现，使用外部服务的工作和速度方面的成本变得非常低，因此我认为相比于使用模拟来应对，直接访问本地外部服务的方式在单元测试方面具有更多的优势。在 AWS 的情况下，存在着一个名为 localstack 的 Docker 镜像，它可以模拟各种服务，并且 CircleCI 等 CI 服务也支持 Docker，因此在本地环境和 CI 环境中都可以以相同的方式进行单元测试。

顺便说一下，关于TDD（测试驱动开发），尽管我也想尝试一次，但由于我还没有在这样的工作环境中受过帮助，所以很难说清楚。

• 開発の初期段階からエンジニア全員がその言語およびフレームワークにある程度習熟している必要がある

 

ヒットするかどうかも分からないサービスにTDD分の開発コストの増大を許容出来る会社さんは多くはない

考虑到这些方面，可以说使用情况或效果能够发挥的条件相当有限，或者说在未来Web行业中扩展的可能性很低（自从TDD出现以来已经过了这么多年，但仍未普及）。因此，我认为（尽管测试本身非常重要且写测试是理所应当的），目前情况下专注于学习TDD并没有太多的好处。

关系数据库管理系统 (RDBMS)

我觉得不需要再多言，但在当前已经出现了许多NoSQL服务的情况下，关系数据库仍然是非常重要的存在，并且特别是对于MySQL而言，我认为它将继续是一个重要的关系型数据库，所以必须了解MySQL的基本管理方法和命令。

在SQL方面，至少需要以下要求。

• 基本的なDDL(CREATE TABLE等)

 

• 基本的なDML(SELECT/INSERT/UPDATE/DELETE)

 

基本的なDCL(GRANT等)

我认为你需要理解这些概念，比如字符编码、索引、事务、死锁以及主从关系等。

最近大部分都使用RDS等全托管的关系数据库，所以我认为不需要深入理解RDB的细节，也很少有机会需要使用这些知识。然而，与以前相比，我觉得年轻工程师对于RDB和SQL的知识水平明显降低了，我看到越来越多的案例浪费了RDB的使用方式，或者在遇到问题时可能会心存疑虑。我希望他们能多学习一些关于RDB基础的知识。

网络框架

• Rails(Ruby)

 

• Django, Flask(Python)

 

• Revel(Golang)

 

• Phoenix(Elixir)

 

• Finch(Scala)

 

• Iron(Rust)

 

Vert.x(Kotlin)

我过去几年在实践中使用的Web框架如上所述，然而，不仅限于这些，只要熟悉任何一种语言中的标准Web框架，就能更容易地理解和应用其他语言的Web框架知识。

就像言语一样，对于这个问题，我认为过于固执于一个框架有更大的弊端，所以我们应该避免像”只想做Rails”这样固执的态度，而是应该采取一种灵活的态度，如”只要是现代化的框架就试试看”，去尝试不同的框架，这样可以增加知识的储备。

最近的趨勢是，開發應用程序或單頁應用程序（SPA）的後端，而不是返回HTML，而是返回JSON的API服務器，這種情況下需要更簡單和輕量的Web框架（如Python的Flask等），在這樣的選擇中，TechEmpower網站的Web框架基準測試結果非常有參考價值，如果大家被分派到這樣的角色，可以嘗試檢查一下，可能會有好處。

非关系型数据库/缓存

• memcached

 

• Redis

 

• DynamoDB

 

Cassandra

我认为在过去几年里，我所经历的NoSQL和KVS大致如上所述，但是，对于DynamoDB来说，如果能有一次经验，也算是没有白费，因为它能让人了解到在考虑使用RDB和NoSQL时，需要考虑DynamoDB的热分区问题以及RCU和WCU的调整工作等，这样才能真正体会到NoSQL的优缺点。

就我个人的观点而言，对于在关系型数据库（RDB）中能够处理的部分，最好将其全部交由RDB处理。尤其是考虑到像AWS的Aurora这样的全托管且易于扩展的RDB不断发展和进步（如自动扩展功能和多主功能等），现在可能正是从NoSQL回到RDB的时期。对于大多数服务来说，仅使用RDB数据存储似乎是没有问题的印象。但是，我认为对于各种云端的NoSQL服务，最好还是保持一定程度的了解。

Amazon Aurora是一种自动扩展的无服务器数据库服务，由AWS提供。
【重点】Amazon Aurora的多主功能已经发布！#reinvent｜Developers.IO

REST API: REST应用编程接口

我认为没有必要理解REST API和RESTful API之间的区别（只需要对按照REST设计思想创建的API被称为RESTful API有基本的认识即可）。而且我个人没有经历过严格应用REST设计思想中”无状态”概念的服务（除了不需要身份验证和cookie的服务），我认为未来也不太可能出现严格到这种程度的API设计方式成为主流。因此，我认为了解基本遵循REST准则的API定义方法，或者说了解类似REST的API定义方法及其所使用的工具就足够了。

REST初学者指南 – 略懂必备知识 – Qiita

详细来说

• GET

 

• POST

 

• PUT

 

DELETE

在理解这个方法应该实现的行为和适当的URI设计方法之前，还需要了解一些关于API规范和描述格式的知识，比如OpenAPI （Swagger）和RAML。

在GoCon之前作为预演，对各种API规范描述格式进行概述 – Qiita
API文档标准化的现状确认：Excite官方工程师博客

基本上我认为OpenAPI（Swagger）是最常见的，所以我觉得学习其他API定义格式不是必需的。（顺便说一句，AWS的API Gateway和GCP的Cloud Endpoints都可以使用OpenAPI（Swagger 2.0）来定义API，但好像不支持其他的API定义格式。）

確認身份

我认为并不需要详细了解文章中定义的各种认证方式的细节和具体规范，但我认为有必要阅读下面的文章等，大致了解OAuth和OpenID Connect的认证流程。

《Qiita》上最简单易懂的OAuth解释
《Qiita》上最简单易懂的OpenID Connect解释
《Qiita》上关于JSON Web Token的用途

顺便说一句，尽管不能完全了解所有规格的详细信息（不仅限于认证），但大多数情况下库会提供支持，如果使用云服务，例如AWS，它提供了一个名为Cognito的服务来处理认证，所以只需要大概了解概要就足够了（虽然理解Cognito的使用方法可能有些困难）。

即时通讯

• Amazon SQS

 

• Amazon SNS

 

Cloud Pub/Sub

在过去几年中，我使用过的消息传递服务有上述所述。SQS是一种常见的消息队列服务，而SNS和Cloud Pub/Sub是发布/订阅类型的消息传递服务。

这两种消息服务的区别可能仅靠阅读说明可能无法理解，或者说最好的方式是自己动手尝试编写示例代码来感受一下。

将繁重的处理工作流程发送到后端或用作进行通知的方法，因此消息服务经常被广泛使用。所以，即使在工作中没有使用机会，我认为在私人领域学习这项技术也是很有必要的。

常见问题 – Amazon简单队列服务（SQS）| AWS

亚马逊简单队列服务（SQS）和亚马逊简讯服务（SNS）都是AWS内的消息服务，但它们为开发者提供了不同的优势。利用亚马逊简讯服务，应用程序可以使用“推送”机制向多个接收者发送重要的定时消息，因此不需要定期检查或“轮询”更新。亚马逊简单队列服务是用于分布式应用程序的消息队列服务，通过轮询模型交换消息并用于分离组件的发送和接收。亚马逊简单队列服务为分布式组件提供了灵活性，无需对每个可用的组件进行发送和接收消息的需求。

搜索整个文本

在全文搜索引擎方面，我认为ElasticSearch是最著名且最常用的，而且我之前接触过的许多公司团队也都使用ElasticSearch，所以我个人认为这是一个必备工具，学习它不会有任何损失。

在AWS上，可以使用完全托管的ElasticSearch服务。

除此之外，Groonga和Solr这样的全文搜索引擎的名字也经常听到，但作为一种普遍趋势，ElasticSearch似乎是主要选择，因此个人认为研究其他全文搜索引擎并没有太大的优点。

Docker

有关Docker的基本知识应该也是理所当然的。如果您在工作中尚未使用过Docker，我认为您应该怀有强烈的危机感，并且至少需要了解其基本要素。

• Dockerfileを書いて

 

• docker buildコマンドでDockerイメージをビルドして

 

• そのイメージを何らかのリポジトリ(DockerHub等)にdocker pushして

 

• そのイメージを何らかのVM上にdocker pullして

 

• そのイメージをdocker runしてコンテナを実行して

 

そのコンテナの特定のポートに外部からアクセスする

将这一系列的工作全都能够独自完成是必须的，或者可以说，如果无法完成上述工作，那么应该认为自己已经相当滞后于潮流。

由于容器化服务是最近几年Web行业的一个重大趋势，甚至可以说已经完全普及，所以如果你们公司还没有在生产环境中使用Docker，我认为你们最好尽早离职（因为它已经变得如此重要）。

在本地环境进行测试以及在CI中进行测试，使用Docker似乎已经成为理所当然的趋势。

网络服务器

这篇文章似乎将nginx和apache归为Web服务器，但除了LAMP环境外，apache已经越来越少见了。而且我认为在作为反向代理的用途上，nginx的使用远远超过apache。所以，如果不使用PHP作为语言，我认为几乎没有必要学习apache。

大概先熟悉一下nginx的配置文件写法比较好。

网页套接字

对于开发游戏、聊天服务或类似Trello的服务来说，我认为使用Web Socket是必不可少的技术。然而非常遗憾的是，我至今还没有在工作中开发过基于Web Socket的服务。 （当时在使用Elixir + Phoenix进行服务开发时，我应该尝试验证这类功能，感到有点后悔）

如果你将来想要创办类似的服务，我认为学习这项技术是很重要的。（我也计划在将来的工作中尝试使用它）

图灵API

由于最近这个话题非常受关注，我当然也很感兴趣。但我认为一般来说，最好等到一些最佳实践逐渐形成后再进行推广，所以目前我觉得观望一段时间应该就足够了。

引入GraphQL后获得的经验和感想。GraphQL可能成为像泰坦尼克号的救生板一样的存在 – Qiita
GraphQL不是REST的替代品｜こんぴゅ｜note

由于GraphQL是单一终端，因此无法直接使用基于URL的缓存机制或CDN中的缓存，如HTTP的Cache-Control。

在REST中，错误通过HTTP状态码进行表示，但在GraphQL中，只要请求成功，便返回200，并且当出现错误时，错误对象会被抛出。在从REST迁移时，客户端的错误处理也需要进行修改。

由于GraphQL是单一终端，无法对每个终端监控响应性能。以下是使用Newrelic的解决方案示例，但需要进行某些调整。

图形数据库

在AWS上已经发布了名为Neptune的图数据库服务（尽管目前还只是预览版），我也对此很感兴趣。但是，除非要创建类似于社交网络服务的网站，否则在Web行业中很难想到其他用途。因此，我的印象是还需要继续观察，暂时不急着使用。

尽管路线图中未提及，但在现场是至关重要的技术。

容器编排

我认为在GCP上是用Kubernetes和GKE，在AWS上是用Cloud Formation和ECS（或者Beanstalk/Fargate）这样的组合（最近AWS也可以使用Kubernetes）。不仅仅是管理独立的Docker镜像或容器，对于管理多个容器的组合以及它们的部署和自动扩展的机制的知识也变得非常重要，所以学习Kubernetes是必须的，与学习Docker并驾齐驱。

总览 – Kubernetes

关于Kubernetes，我觉得学习成本有点高，理解Pod、Service等概念和设置方法需要一定时间（尤其是网络部分比较困难）。但作为容器编排工具，它算是标准的，所以学习一下也不会亏吧（虽然我觉得将来可能会出现更简单的工具）。

无服务器

在AWS上，Lambda函数和在GCP上的Cloud Functions是核心服务，但是只要合理使用，您就可以轻松地将各种功能集成到服务中，而不是使用虚拟机或容器。所以，学习这方面的内容也是必须的。

唯一需要一种选项的汉语本地化改写：

但是，例如对于Lambda来说，可能存在使用语言的限制，同时执行数的限制，最大执行时间的限制，以及在AWS的VPC环境中执行时的启动成本问题，所以我们需要判断适当的使用情境。

基础设施的编码化

我认为，在AWS或GCP的Web控制台上点点鼠标来启动EC2或GCE实例的方式已经完全成为一种过时的方法(开发和测试阶段除外)。

以流程手册的方式管理基础设施，无疑无法防止手册更新遗漏导致的操作错误和工作个人化，并且非常困难了解这些基础设施的实际构成，因此这种方法有非常大的缺点。

如果使用AWS，可以使用CloudFormation；如果使用GCP，可以使用DeploymentManager；同时，还可以使用Terraform等工具，以代码的方式管理基础设施，从而可以消除上述问题。

当然，如果试图通过代码来管理所有基础设施，可能会引起一些麻烦，所以适度的妥协是必要的。但基本上，将可由代码管理的基础设施全部代码化是一个在各方面都会变得更轻松的方针。我认为这是一项值得掌握的技术，因为我相信在未来，各个公司也会更普遍地采用这种方法。

CI/CD 持续集成/持续部署

在2018年，我不认为还有任何团队在代码库中推送代码到源代码管理库时，CI工具并未执行测试。但如果你们的公司是这样的环境（我在Docker部分也提到了），那它就是一个非常陈旧的环境，我建议你尽快换工作。

我认为很多团队可能会使用CircleCI 2.0，如果您为依赖的服务创建Docker镜像和用于测试执行的脚本，那么无论是在本地环境还是在CI上，都可以使用相同的命令来执行测试。并且，只要编写合适的部署脚本，可以在云端一键执行部署（不需要手册或部署专家），因此将源代码管理服务和CI工具进行协作已经成为提高工作流效率必不可少的知识。

自动化DB迁移

我认为，登录到用于执行迁移脚本的服务器（跳板服务器）等，在其中通过SSH执行迁移的方法是流行的。但是，如果将这个过程交由CI工具端的脚本来执行，那么跳板服务器一方面必须允许从CI工具端的IP进行访问。

若CI工具本身具有固定IP，则没有问题，但是像CircleCI等CI工具的访问来源IP范围是不确定的，所以需要允许来自预计范围非常广的IP地址段的访问，这样设定在安全方面是极为不可取的。将数据库设为公开的方法也可能，但这当然也是危险的。

我个人认为，对于这个问题，如果是在AWS环境下，巧妙地使用Lambda来执行迁移是最佳实践。但无论如何，我认为在云环境中自动化数据库迁移方面的经验非常重要。

内容分发网络

如果使用AWS，可以选择CloudFront；如果使用GCP，则选择Cloud CDN。不管选择哪个，开发静态文件（如HTML/CSS/JS/图片等）分发服务都必须掌握CDN知识。

基本上，例如在AWS上，只需要將CloudFront與S3進行連接，但需要了解S3的元數據設置以及對S3訪問的限制（設置CloudFront的源訪問身份），所以如果有機會的話，建議創建一個類似的網絡服務並測試這些操作的行為，這樣可能會更好。

监视/监控

如果使用AWS，您可以使用CloudWatch进行监控和监视。如果使用GCP，则可以使用StackDriver等完全托管的服务进行监控和监视。对于小型服务，我认为使用它们足够了。但是，如果您想创建易于查看的仪表板，或者希望除了具有AWS或GCP访问权限的人之外的其他人能够查看仪表板，那么CloudWatch等服务将无法满足需求。考虑到功能的细节和使用便捷性，有时也需要使用第三方监控服务，如Datadog。

我认为在云上自己托管Zabbix、Nagios等非托管服务的情况相当罕见，但是Datadog、Mackerel、NewRelic等受管理的第三方服务通常被广泛使用，所以我建议有机会一定要尝试使用这些服务。

“入门监控服务（Mackerel、Datadog、New Relic）！- Qiita”

日志平台/分析平台

我认为TreasureData和GCP的BigQuery是顶尖服务，但在费用方面（如果使用正确），大多数服务都比较划算，所以使用BigQuery的公司较多。

对于后端工程师来说，我认为与其通过向分析平台提交查询以进行分析，不如掌握从应用程序向分析平台稳定地发送数据的方法论更加重要。在这方面，我认为使用fluentd是普遍的做法，因为它在许多不同公司中广泛使用。因此，我认为最好尽早积累实际经验，学习如何使用和配置fluentd。

机器学习

我认为虽然这一点因人而异，但随着云计算的出现，服务器端工程师可以独自完成基础架构的管理，就像通过云计算、各种库和工具对机器学习复杂部分的抽象化一样，卓越的后端工程师可以独自负责服务的机器学习部分。这个时代即将到来，这是我的个人印象。

当然，若要求对机器学习部分非常高的情况下，可能需要借助专业的机器学习工程师或咨询师的力量，但在希望能够迅速发布一定精度的服务的情况下，通过使用云端托管服务，由后端工程师独自负责所有工作的情况可能会越来越常见。

另外，我現在加入了一個專注於機器學習和數據科學的團隊，從後端工程師的角度來看，機器學習的基礎架構和工作流程往往顯得相當過時，我意識到有一種非常強烈的需求，即要將它們現代化。

根据我的预测，未来机器学习工作流和基础设施的现代化将成为Web行业中非常重要的主题。因此，不仅要掌握机器学习本身的知识，还要熟悉机器学习周边的各种技术，这对于推动后端工程师的职业发展具有重要的优势。

顺便提一下，我之前写过类似的文章，最近终于开始学习Kaggle了。机器学习的学习确实很困难，但是很有趣♪(^.^)

为了学习机器学习，文科工程师一口气复习了从小学数学到高中数学。- Qiita
由于完成了Coursera上的机器学习课程，文科工程师进行了回顾。- Qiita

总结

实际上，我认为还有一些其他需要的技术，但在写作过程中我感到没力气了，所以我想就到这里为止吧。（我将在日后再次补充）

有些人可能会认为，需要做这么多吗？但与其说是“需要做”，我认为更重要的是，如果在您目前所就职的公司或团队中无法获得这样的经验，那么这种环境很可能是“传统的”并且您在传统的环境中待得越久，转移到现代化环境的可能性就会变得越小，所以我认为应该意识到这一点。

我从未见过在所有方面都是现代化的企业或团队，但至少在老式的日本价值观中，”咬紧牙关努力工作在传统环境之中”被视为一种”美德”，但对于追求成为前端工程师的人来说几乎没有任何好处，所以我认为应该考虑改善传统环境，或者转移到其他团队或公司。

我认为在Web行业工作的乐趣不在于成为SIer，而在于每天都能接触到现代有趣的技术，以充满激情的心情工作。因此，如果只能忍受传统环境，那么在Web行业工作就失去了意义，这是我的观点。

附赠

我在YouTube上推出了一个名为「雜食工程師TV」的频道，特别为对Web工程师或对Web工程感兴趣的人而设。如果您对此感兴趣，我会非常高兴您能订阅我的频道。

此外，自2019年起，我也开始了名为“综合工程师沙龙”的在线沙龙活动。

我们在 Twitter 上也发布了各种关于“网络工程师的职业策略”的信息，请您考虑关注一下。@poly_soft