由 dawei 编码规则是程序编码所要遵循的规则，要注意代码的正确性、稳定性、可读性。
而对于这些条条框框，一些不拘小节的程序猿们往往并不在意，这导致常常会发生一些意想不到的问题和状况，让大家苦恼不已。
现在，小芯整理了一份“命令”清单：列出了作为现代开发人员，你必须要做和不应该做的事情。
下面请看其中的5件，讨论为何你和团队应该采纳它们。
1. 先确定问题，再确定解决方案。
每个人都有自己喜欢使用的东西：Redis、MySQL等。没关系，有偏好是再正常不过的。
但当这些偏好成为要求时，就会出现麻烦;透过这个镜头可以观察每个问题，避免其偏离。别被骗了，这不只是个人的罪恶，组织也应对此感到内疚。
许多公司要求使用某些技术、库或工具，而往往没有“脚踏实地”地进行思考或投入，令开发人员和运营工程师不得不在实际中使用或实施这些技术。
这是我长期以来不甚满意的一部分，既包括企业体系结构，也包括掌控真正编写代码的凡人的上帝般的力量。
结构小组通常决定公司将使用某种技术或产品(Kubernetes、OpenShift、AWS等)，但却未完全了解组织内部的问题以及这些技术旨在解决什么问题。
我在Capital One工作期间亲眼目睹了这一点，当时我们的架构团队决定将使用Kubernetes，但这对那些必须在实际中开发和实施系统及工具的人或将供其运行的应用程序来说并无真正意义。
通常，架构(或是同病相怜的兄弟——企业安全性)是导致他们无法获得所需东西的原因。
如果他们-架构和安全性-首先了解所需解决的问题，然后决定使用哪种工具，情况可能大相径庭，并且很可能顺利得多。
5大代码规则，守护程序猿世界的爱与和平
图源：Unsplash
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进行高性能计算——那么要找到与所需解决问题相匹配的解决方案。