不重视系统安全、过于微服务化、各种导入包……这些问题开发人员可能会在日常工作中会犯，除此之外，还有哪些开发者容易掉的坑呢？本文作者结合自身开发经历，为大家分享了九大经验教训。
作者
PeterChristianFraedrich
译者
弯月，责编
伍杏玲
出品
CSDN（ID：CSDNnews）
以下为译文：我是一名Python+Go开发人员，在过去的几年中，我一直在运营全球规模的应用程序。我们团队每天都需要为万名客户提供服务，运营这种规模的系统并非易事。我想在本文中分享多年以来学到的九大经验教训。保障安全刻不容缓保障安全刻不容缓，你不能轻描淡写地说：“今后系统会加强安全性。”强大的应用程序安全应该被当作开发过程中的首要问题，应该从第1天开始就需要讨论，绝对不能等到第天。将安全性留到最后一分钟实际上会增加开发的时间，因为你不得不返工，通过重构实现安全要求。更糟糕的是，届时你就没有那么多时间来解决安全问题了，最终只能发布易受攻击的代码。雅虎等公司的遭遇就是前车之鉴。每个应用程序各不相同，且有各自的需求，根据应用程序的需求选择，不要屈服于市场流行度。每个应用程序各不相同，这点无需多说。世上没有一套适用于所有应用程序的万全之策。在启动新应用程序时，应该由应用程序及其体系结构来规定使用的技术或标准化的平台。如果在你搞清楚“应用程序需要什么”之前，就决定使用gRPC或Kubernetes系统，那么只会阻碍代码的编写工作。这就是为什么Canonical等公司误入歧途，在物联网设备上运行Kubernetes。引用JeffGoldblum的一句话：“科学家们忙于思考他们能够干什么，不能够干什么，以至于他们没有时间停下来思考是否应该这样干。”你可能并不需要微服务
微服务非常有魅力，我完全理解。即便只是想一想能够单独扩展应用程序中的各个小功能，就足以让人兴奋不已，因为你可以感受到满满的成就感。但是，说实话你可能不需要微服务。比如“我希望将功能X的代码从功能Y的代码中分离出来”，“防止不良代码渗透到应用程序的其他部分”，或者“最小化受影响的应用”等到这些理由不是使用微服务的原因，这些不过是糟糕的开发实践导致的恶果，你需要的是更严格的代码审查标准（不要合并不良代码），以及更为细致的安全控制。你是否需要单独扩展应用程序的各个部分，而且目前的组件（例如登录流程）是否存在容量的问题？然后再探索那些需要扩展成独立服务的组件。你是否需要运行基于虚拟服务器的架构并希望降低成本？如果是，那么就不应该探索微服务。即便采用微服务，充其量也不过是功过相抵。恶劣的情况下，最终只是多了几个需要单独启动的实例。假设你的整体式架构包含5个服务，而你却将其分解成了微服务。那么，现在你有5个应用，你所面临的局面是：a）你需要逐个启动专用实例，而占空的空间是最初的5倍；b）你利用现有的空间，同时承担额外的运营成本。标准化的开发环境
在与多个开发人员合作时，标准化整个团队使用的开发环境可以让你受益无穷。我并不是说你必须将一些基于容器的虚拟开发环境通过魔法混合在一起。虽然你要这么干我也拦不住，但是你只需使用同一个版本的语言就可以为团队带来奇迹。如果你的同事用Go1.11编写代码，而你却在Go1.12上发现了Bug，那么可真是欲哭无泪。协调何时升级版本可能很困难，但一旦协调成功，诸事都会顺利。配置的工作不简单，请务必做好相应的计划
虽然有些流行的网站说，配置只不过是“将所有东西都扔进环境变量中”，然而事实远非如此。我认为配置应用程序的方法至少有四种：代码内的默认值、本地配置文件、命令行的标志、环境变量、远程配置（如使用Hashicorp的Consul）等。我认为远程配置是可选的，而其他四个都是必要的。对于开发来说，为了在本地运行应用程序而不得不将27个不同的配置值放入环境变量，这会让人万分沮丧。另外，你可能需要更好的自动化和Makefile。你可以利用本地配置源的方法，如application.yaml，并默认设置为“dev”配置。此外，如果代码中有默认值，则意味着你需要更改它们的默认值。在通过systemd等初始化系统运行应用程序时，命令行的标志非常实用，因为在查看进程的运行情况时，你可以清楚地看到应用程序的配置方式。在容器内运行应用程序时，环境变量非常实用，但也有一些东西不适合放入环境变量，比如Secret。你永远不能将Secret（密码、身份验证令牌、证书等你不想泄露给公众的数据）放入环境变量，因为它们不安全，而且主机上的任何进程都可以读取环境变量。你应该借助某种Secret管理工具。我个人喜欢使用Vault（来自Hashicorp），但你可以根据应用选择最合适的工具。只在必要时导入软件包
我们都知道left-pad的那个故事吧（