云栖号：https://yqh.aliyun.com
第一手的上云资讯，不同行业精选的上云企业案例库，基于众多成功案例萃取而成的最佳实践，助力您上云决策！

编码规则是程序编码所要遵循的规则，要注意代码的正确性、稳定性、可读性。

而对于这些条条框框，一些不拘小节的程序猿们往往并不在意，这导致常常会发生一些意想不到的问题和状况，让大家苦恼不已。

现在，小芯整理了一份“命令”清单：列出了作为现代开发人员，你必须要做和不应该做的事情。

下面请看其中的5件，讨论为何你和团队应该采纳它们。

1.先确定问题，再确定解决方案。

每个人都有自己喜欢使用的东西：Redis、MySQL等。没关系，有偏好是再正常不过的。

但当这些偏好成为要求时，就会出现麻烦；透过这个镜头可以观察每个问题，避免其偏离。别被骗了，这不只是个人的罪恶，组织也应对此感到内疚。

许多公司要求使用某些技术、库或工具，而往往没有“脚踏实地”地进行思考或投入，令开发人员和运营工程师不得不在实际中使用或实施这些技术。

这是我长期以来不甚满意的一部分，既包括企业体系结构，也包括掌控真正编写代码的凡人的上帝般的力量。

结构小组通常决定公司将使用某种技术或产品，但却未完全了解组织内部的问题以及这些技术旨在解决什么问题。

我在Capital One工作期间亲眼目睹了这一点，当时我们的架构团队决定将使用Kubernetes，但这对那些必须在实际中开发和实施系统及工具的人或将供其运行的应用程序来说并无真正意义。

通常，架构（或是同病相怜的兄弟——企业安全性）是导致他们无法获得所需东西的原因。

如果他们-架构和安全性-首先了解所需解决的问题，然后决定使用哪种工具，情况可能大相径庭，并且很可能顺利得多。

2.提出问题

听起来很简单、容易、还有点幼稚，但其实很难。遇见不懂的，那就提出问题。想知道为什么是这样吗？提出问题。想知道项目的方向吗？提出问题。

仅仅提出问题并不意味将得到想要的答案，也不意味根本不能得到任何答案。但是如果不提出问题，那将永远找不到答案。

进入新团队或开始新工作后，最好的事情之一就是提出所有问题。拔出FNG卡就像在一开始“摆脱外观愚蠢的”卡一样。

用以下内容作为开头提出问题：“嗨，对这一切而言，我是个新手，所以要提个愚蠢的问题……”这是一种很棒的方式，可以找到想知道的事情，同时挑战现状。

你会惊讶地发现有多少组织按照“以某种原因”这种方式做事。通常是因为有人在不久前设置了这种方式，但没有人愿意修改它。

通过提出问题、质疑假设和挖掘信息，我们令所在团队、集体、个人以及生活变得更好。通过这样的提问，我已经能从基础结构中获得整个层次。

谁知道你将做出哪些修改。

3.使用最佳工具完成工作（除非使用Java）

我不愿这样说，但是的确找不出在当今行业中使用Java的理由。

Java确实有一些与之抗衡的差异，我不会否认，但是这些差异并不能真正适用于当今的工程环境。以下是使用Java的一些优点：

· 它可以在任何地方运行。
· 自动内存管理（及其垃圾回收器）。
· JVM堆栈的广泛社区和框架/库/插件。

让我们谈一谈现实：你看到多少个软件商店使用Java编写用于多个体系结构、操作系统等运行的代码库？至少不是大多数。

如今，Java在内存管理领域也不是唯一。Go和Rust都具有某种垃圾收集功能，Python使用引用计数，许多其他语言也具有这种功能。

到目前为止，Java并不是唯一拥有大量活跃社区的语言。Rust和Python拥有非常活跃、具有帮助的社区，Go的社区与日俱增。

但是，至少在我看来，使用Java进行其他权衡是不值得的。因为Java依赖JVM，所以每个Java应用程序都会产生自动大小调整的成本。

在谈论具有千兆字节可用空间（不到几百MB的空间）的服务器时，这可能不值一提，但在高度集装化的世界中，几百MB却是天文数字。（请注意，Python也具有此种缺点。）

使用Go、Rust（和其他）经过编译的静态链接语言，可以拥有非常小而精简的容器，这些容器中通常只有一个大小为4 MB二进制的文件。

这对于网络吞吐量非常重要的大型组织尤其重要，下载400 MB或5 MB新的容器非常容易。

另外，由于JVM和Java是JIT编译的，因此运行Java代码会降低性能。

对于低延迟、高吞吐量的应用程序，或对服务器进行装箱打包非常重要的场景，将字节码转换为系统调用而导致的性能损失是不值得的。

这一切就是正确使用工具完成当前工作十分重要的原因。

你不想使用BASIC供人登月，也不想使用Java进行高性能计算——那么要找到与所需解决问题相匹配的解决方案。

4. 不要使用Monorepos

如果你不熟悉monorepo概念（羡慕你），请允许我解释一下：monorepo并非为应用程序提供多个源代码存储库，而是将所有内容都放在一个存储库中。

这有益于多个项目，但是要付出代价：必须使用Subversion，而不能使用Git。尽管Git具有很多优点，但它不支持像subversion这样的稀疏检出。

稀疏检出可检出一棵较大树的单个目录，而非像Git一样检出整个树。这意味着可以让多人或团队在树的各个部分上工作而免于重叠。

使用Git不能做到这一点，因此使用Git作为源代码控件时，应该为离散应用程序使用单独的存储库。

5.不要方枘圆凿

就像很多美好的事物——做爱、团队合作精神、精密螺纹的机器螺丝钉，当它们状态良好时，一切都会轻松自在。我们的生活充满了反馈，无论反馈是否明确。

打字时指间会感受到敲击键盘的方式，按下扁平的假想按钮时手机会发出轻微的“咔嗒”声，每当决定吃冰激凌时我患有乳糖不耐症的胃就会100％进行反抗；这些都是反馈形式。

他们会告诉我们什么时候进展顺利、正常或极其糟糕，实际上一切都一样。我们之前都体会过，从事一个项目，胃部的那种感觉不断告诉我们应该更改数据库以更好地支持数据模型。

如果你只使用关系数据库和ORM，则可以编写大量此类数据库内数据，而不用编写大量易碎的数据转换代码。或者，在找到自己的新团队或新工作后，出于某种原因，你不再与同事友好相处。

这并不是说你不喜欢他们，或者他们不喜欢你，只是某些性格的人更适合在一起工作。无需强求。找到更好的解决方案，然后继续。

与经理谈谈更换团队。找到一个ORM并开始工作。停止你正在做的事情，然后做令其变得轻松的事情。将方形钉/圆孔问题留给NASA书呆子。

相信能掌握这5大代码规则，你的编程之路会更加顺利轻松和愉快~

云栖号：https://yqh.aliyun.com
第一手的上云资讯，不同行业精选的上云企业案例库，基于众多成功案例萃取而成的最佳实践，助力您上云决策！

原文发布时间：2020-1-12
本文作者：读芯术
本文来自阿里云云栖号合作伙伴“读芯术”，了解相关信息可以关注“读芯术”