不重视系统安全、过于微服务化、各种导入包……这些问题开发人员可能会在日常工作中会犯，除此之外，还有哪些开发者容易掉的坑呢？本文作者结合自身开发经历，为大家分享了九大经验教训。

一、保障安全刻不容缓

保障安全刻不容缓，你不能轻描淡写地说：“今后系统会加强安全性。”
强大的应用程序安全应该被当作开发过程中的首要问题，应该从第1天开始就需要讨论，绝对不能等到第300天。将安全性留到最后一分钟实际上会增加开发的时间，因为你不得不返工，通过重构实现安全要求。
更糟糕的是，届时你就没有那么多时间来解决安全问题了，最终只能发布易受攻击的代码。雅虎等公司的遭遇就是前车之鉴。
每个应用程序各不相同，且有各自的需求，根据应用程序的需求选择，不要屈服于市场流行度。
每个应用程序各不相同，这点无需多说。世上没有一套适用于所有应用程序的万全之策。在启动新应用程序时，应该由应用程序及其体系结构来规定使用的技术或标准化的平台。
如果在你搞清楚“应用程序需要什么”之前，就决定使用gRPC或Kubernetes系统，那么只会阻碍代码的编写工作。这就是为什么Canonical等公司误入歧途，在物联网设备上运行Kubernetes。
引用Jeff Goldblum的一句话：“科学家们忙于思考他们能够干什么，不能够干什么，以至于他们没有时间停下来思考是否应该这样干。”

二、标准化的开发环境

在与多个开发人员合作时，标准化整个团队使用的开发环境可以让你受益无穷。我并不是说你必须将一些基于容器的虚拟开发环境通过魔法混合在一起。虽然你要这么干我也拦不住，但是你只需使用同一个版本的语言就可以为团队带来奇迹。
如果你的同事用Go 1.11编写代码，而你却在Go 1.12上发现了Bug，那么可真是欲哭无泪。协调何时升级版本可能很困难，但一旦协调成功，诸事都会顺利。


三、配置的工作不简单，请务必做好相应的计划

虽然有些流行的网站说，配置只不过是“将所有东西都扔进环境变量中”，然而事实远非如此。
我认为配置应用程序的方法至少有四种：代码内的默认值、本地配置文件、命令行的标志、环境变量、远程配置（如使用Hashicorp的Consul）等。我认为远程配置是可选的，而其他四个都是必要的。
对于开发来说，为了在本地运行应用程序而不得不将27个不同的配置值放入环境变量，这会让人万分沮丧。另外，你可能需要更好的自动化和Makefile。你可以利用本地配置源的方法，如application.yaml，并默认设置为“dev”配置。
此外，如果代码中有默认值，则意味着你需要更改它们的默认值。在通过systemd等初始化系统运行应用程序时，命令行的标志非常实用，因为在查看进程的运行情况时，你可以清楚地看到应用程序的配置方式。在容器内运行应用程序时，环境变量非常实用，但也有一些东西不适合放入环境变量，比如Secret。
你永远不能将Secret（密码、身份验证令牌、证书等你不想泄露给公众的数据）放入环境变量，因为它们不安全，而且主机上的任何进程都可以读取环境变量。你应该借助某种Secret管理工具。我个人喜欢使用Vault（来自Hashicorp），但你可以根据应用选择最合适的工具。

四、没必要抽象所有代码

还有一个很大的坑：抽象一切。
有时，你会觉得“稍后我可能会再用到这个功能”，这个想法可能会将你引向一条黑暗又可怕的面向对象之路。
DRY原则（Don’t Repeat Yourself，不要自我重复）彻底征服了我们，尽管这条原则有其充分的理由。
然而，你需要注意不要在抽象上花费太多时间，以至于没有足够的时间编写逻辑。你的工作是写代码！等到你发现你需要实现的某个方法或函数之前已经写过了，那么可以再回过头来抽象，但是切记量力而行。
我个人遵循的原则是，如果抽象之前只是一个只有3行的函数，那么就重复好了。如果真的只有3行代码，也许你该想一想是否值得写成函数。


五、不要听互联网上陌生人的忽悠

你应该自行决定适合自己的应用程序和开发风格的规则。即使本文提到的几件事，你也应该仔细推敲，毕竟我也只是互联网上的一个陌生人。