程序员易踩的 9 大坑

不重视系统安全、过于微服务化、各种导入包……这些问题开发人员可能会在日常工作中会犯，除此之外，还有哪些开发者容易掉的坑呢？本文作者以下为译文：

我是一名Python + Go开发人员，在过去的几年中，我一直在运营全球规模的应用程序。我们团队每天都需要为200万名客户提供服务，运营这种规模的系统并非易事。我想在本文中分享多年以来学到的九大经验教训。

保障安全刻不容缓

保障安全刻不容缓，你不能轻描淡写地说：“今后系统会加强安全性。”

强大的应用程序安全应该被当作开发过程中的首要问题，应该从第1天开始就需要讨论，绝对不能等到第你可能并不需要微服务

微服务非常有魅力，我完全理解。即便只是想一想能够单独扩展应用程序中的各个小功能，就足以让人兴奋不已，因为你可以感受到满满的成就感。

但是，说实话你可能不需要微服务。比如“我希望将功能X的代码从功能Y的代码中分离出来”，“防止不良代码渗透到应用程序的其他部分”，或者“最小化受影响的应用”等到这些理由不是使用微服务的原因，这些不过是糟糕的开发实践导致的恶果，你需要的是更严格的代码审查标准（不要合并不良代码），以及更为细致的安全控制。

你是否需要单独扩展应用程序的各个部分，而且目前的组件（例如登录流程）是否存在容量的问题？然后再探索那些需要扩展成独立服务的组件。

你是否需要运行基于虚拟服务器的架构并希望降低成本？如果是，那么就不应该探索微服务。即便采用微服务，充其量也不过是功过相抵。恶劣的情况下，最终只是多了几个需要单独启动的实例。

假设你的整体式架构包含5个服务，而你却将其分解成了微服务。那么，现在你有5个应用，你所面临的局面是：

a）你需要逐个启动专用实例，而占空的空间是最初的5倍；

b）你利用现有的空间，同时承担额外的运营成本。

标准化的开发环境

在与多个开发人员合作时，标准化整个团队使用的开发环境可以让你受益无穷。我并不是说你必须将一些基于容器的虚拟开发环境通过魔法混合在一起。虽然你要这么干我也拦不住，但是你只需使用同一个版本的语言就可以为团队带来奇迹。

如果你的同事用Go 1.11编写代码，而你却在Go 1.12上发现了Bug，那么可真是欲哭无泪。协调何时升级版本可能很困难，但一旦协调成功，诸事都会顺利。

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

虽然有些流行的网站说，配置只不过是“将所有东西都扔进环境变量中”，然而事实远非如此。

我认为配置应用程序的方法至少有四种：代码内的默认值、本地配置文件、命令行的标志、环境变量、远程配置（如使用Hashicorp的Consul）等。我认为远程配置是可选的，而其他四个都是必要的。

对于开发来说，为了在本地运行应用程序而不得不将27个不同的配置值放入环境变量，这会让人万分沮丧。另外，你可能需要更好的自动化和Makefile。你可以利用本地配置源的方法，如主机上的任何进程都可以读取环境变量。你应该借助某种Secret管理工具。我个人喜欢使用Vault（来自Hashicorp），但你可以根据应用选择最合适的工具。

只在必要时导入软件包

我们都知道left-pad的那个故事吧（https://在导入库时，通常我会遵循一个简单的规则：如果我可以在10-15分钟内自己编写，那么就自己写；否则再考虑使用外部的库。

在开发的时候，牢记这条规则可以避免将不必要的内容导入应用程序，但是你不必每次需要提供API时都考虑从头开始编写新的没必要抽象所有代码

还有一个很大的坑：抽象一切。

有时，你会觉得“稍后我可能会再用到这个功能”，这个想法可能会将你引向一条黑暗又可怕的面向对象之路。

DRY原则（Don’t Repeat Yourself，不要自我重复）彻底征服了我们，尽管这条原则有其充分的理由。

然而，你需要注意不要在抽象上花费太多时间，以至于没有足够的时间编写逻辑。你的工作是写代码！等到你发现你需要实现的某个方法或函数之前已经写过了，那么可以再回过头来抽象，但是切记量力而行。

我个人遵循的原则是，如果抽象之前只是一个只有3行的函数，那么就重复好了。如果真的只有3行代码，也许你该想一想是否值得写成函数。

项目需要像“凤凰”一样，

经历浴火重生的洗礼

这个想法令人不寒而栗。经理们会为此感到紧张，产品所有者会为此变得暴躁，而且开发人员也会因此而感到愤怒，但你必须这么做。

每隔一段时间就从头开始其实是一件好事。你可以借机删掉代码中的冗余，而且无需改造现有的半个代码库就可以实现新的想法，同时还可以强制每个人重新评估项目。

你可以把项目想象成一片森林，每一行代码都是一棵参天大松树，绵延数里。随着时间一天天过去，这片森林会布满灌木丛、飘落的松针、松果、枯枝和许多其他杂物。这些都是你的麻烦，你的技术债务。

这些东西越积累越多，直到受到某种外部力量的影响。对于森林而言，这种外部力量就是野火。火焰肆虐过的森林，地表寸草不生，只有树皮足够厚的树木才能存活下来，所有未长成的树木都会被大火烧尽。虽然这对森林来说是灭顶之灾，但其中蕴含着一个惊天的秘密：森林渴望大火。多年来，它一直在耐心地等待，等待火焰来净化一切，因为火焰在树冠下肆虐过后，下一代的参天大树才会从松果中发芽。

当火焰横扫过森林地面时，它会孵化出幼小脆弱的树苗，让它们与被大火烧得漆黑的幸存者并肩而立。你的应用程序也需要这样的洗礼：生命力旺盛、编写良好的代码会从清理中存活下来，而新的想法和代码会从累累白骨中站起来，宛如浴火重生的凤凰。

你不是谷歌

如果你是谷歌的一员，那么请绕道。但如果你真的是谷歌的员工，又何必来读这篇文章呢？关键在于，你是谷歌微软、亚马逊、Twitter或Facebook一员的可能性非常小。所以，你无需在全球17个不同数据中心的10,000台裸金属服务器上协调150,000个容器。通常，你的问题不会影响到世界各地的人民。

那么，为什么我们要谈这个话题？因为你应该根据规模决定你的运营平台。如果你只需要运行几百个容器，那么有必要使用Kubernetes吗？你真的需要运行Kuberetes，还是说只想在简历中多添一项炫耀的资本？

HashiCorp Nomad等系统非常适合中小规模的系统：设置简单，几乎不需要维护，还有良好的文档记录，而且转换应用程序很容易，因为它适用于容器以及系统进程和JVM原生应用程序。如果你真的想使用Kubernetes，那么为什么不使用Rancher等把混乱的东西都抽象化呢？运行Kubernetes这般复杂的系统实在让人感到头疼，而且也心疼钱，因为这些系统都是给谷歌这样的公司设计的，单凭一个团队很难管理。

我甚至会说，不要听互联网上陌生人的忽悠

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

网页名称：程序员易踩的 9 大坑
当前路径：/news31/103031.html

成都网站建设公司_创新互联，为您提供企业网站制作、全网营销推广、做网站、搜索引擎优化、网站排名、品牌网站制作

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联