软件工程的黄金法则

> Photo by Chris Ried on Unsplash

TL：DR

黄金法则：无论问题是什么，答案几乎总是以”取决于……”开始

软件并不像您认为的那样精确。 我们为他人而不是为计算机编写软件。 为不同的人编写软件会导致对相同问题的不同答案。 在下定决心并选择解决方案之前，我们需要退后一步，考虑所要提出的问题的背景。

软件工程的黄金法则

TL：DR中已经提到过，但是需要重复：无论是什么问题，答案几乎总是以”取决于……”开始。

· 应该如何实现此功能？ 这取决于…

· 应该如何测试此功能？ 这取决于…

· 此段代码应使用哪种语言/框架？ 这取决于…

· 哪种架构最适合此应用？ 这取决于…

· 这段代码将运行多快？ 这取决于…

光荣的不精确

如果您的观点是非常精确的软件之一，则可能使某些人感到不适。

黄金法则基本上说没有什么是确定的。 每个问题都有选择，利弊，应考虑的不同结果。

这很奇怪，因为众所周知，计算机完全按照您告诉他们的方式去做。

那么，软件中任何问题的答案又为何如此模糊？

软件更重要的是人而不是计算机

我们为他人而不是为计算机编写软件。

如果只为计算机编写代码，我们本来可以保留汇编程序。

我们没有。

我们希望以个人作家的身份提高生产力，为未来的自我写作。 我们希望使在相同代码库上的协作更加容易。 我们开发了各种不同的方式来相互交流思想和模式。

当我们编写代码时，主要读者是另一个人。

读者可能是热情，印象深刻的新工程师。 刚到大型玻璃钢办公室，吃了免费的巧克力饼干，不知道什么是最佳实践，或者只是想尝试一些最终可行的方法。

代码在计算机上运行，但通常一旦将其编译为计算机可以实际读取的内容即可。 大多数时候，我们正在编写的代码是供其他人阅读的。

这是因为软件是为人们编写的，所以任何问题的答案都可以从”取决于……”开始。 人们是多种多样的，因此，软件是多种多样的。 有许多不同的处理方式，根据情况的不同，情况可能会有所不同

情境就是一切

编写软件的环境与编写软件的方式有很大的不同。 可以根据上下文以各种不同的方式编写同一个应用程序。

上下文是将要阅读我们编写的代码的其他人。

这是一个人的项目吗？ 以技术为中心的创业公司？ 公司的庞然大物？在每种情况下，它们都会以不同的方式回答相同的问题。

一个人的项目可能会不太担心严格的编码标准和文档，因为它是由一个人编写的，具有所有上下文。

以技术为中心的初创公司可能会专注于允许其尽可能快地迭代和试验的技术，如果它不是最具扩展性的代码，那么无所谓，如果它们不能迭代，它们就会死掉。 在需要扩展成为问题之前很久。

企业庞然大物在为他们准备的技术上已经做出了很多决定，现在这是保持一切运转的情况。 引入新的闪亮框架无效，因为它需要培训整个公司。

这里的困难在于上下文的变化，在一个人的项目的上下文中做出的决策成为启动中的问题。 初创公司遇到的困境永远不会重新回到公司的庞然大物上。

在一个人项目中，对某个问题的答案可能与在公司庞然大物中，对同一问题的答案不同。

一切取决于。

你自有主张

在某些方面，如果对所有软件问题都有确定的答案，那将是很好的。 这将消除许多所需的决策，这可能会减少误解的数量。 如果每个人都以完全相同的方式写相同的东西，则更容易预测其外观。

在其他方面，这将使生活变得更加困难，并非每个问题都是相同的，在一个地方起作用的解决方案可能在另一个地方不起作用。 如果我们处在一个完全同质的世界中，那么将失去针对特定情况定制特定工具的许多功能。

我们不能只是将问题的答案留为”取决于情况”，而会感到一切自鸣得意。 我们需要以一种平衡的观点来遵循该声明，概述各种可能性。 然后对哪种可能性最适合我们的情况做出决定。

在大多数情况下，可能会有一些正确的答案，选择该答案不应该是默认答案，但可能是经过考虑后得出的答案。

以选择项目框架为例。 可以很容易地跟随人群，加入团体思维，并随您认为最适合您的项目类型的框架。

假设您选择将React用于前端项目。

我并不是说您不应该为前端项目选择React。 我的意思是，只有在考虑了各种可能性的平衡观点并且已踏入React时，才应选择React。 这里要考虑的事情类型可能包括：

· 我知道React吗？

· 我有时间学习React吗？

· 这个项目上还有其他人吗？

· 他们是否知道或想学习React？

· 这个项目的时间表是什么？

· React是否是该前端项目试图解决的问题的合适解决方案？

· 有哪些选择？

· 我更喜欢什么？

“我的前端项目应使用什么框架？”这个问题的答案。 可以而且应该以”取决于……”开始。 它不应以” React”开头和结尾，因为它被认为是编写前端项目的默认方法。

我应该指出，我喜欢编写React，我认为它是一个有用的工具，但是应该在适当的地方使用它。

权衡选项，考虑上下文并下定决心的方法不仅适用于选择框架，而且几乎适用于软件中的所有内容。 像这样的问题：

· 我们应该编写微服务吗？

· 我们应该使用什么框架？

· 我们应该使用哪种语言？

· 我们如何在代码中表示这个概念？

· 我们应该采用什么编码标准（如果有）？

· 这段代码应该放在哪里？

· 我们如何测试此功能？

· 我们应该使用哪个数据库？

· 我们应该使用NoSQL还是SQL？

· 我们应该使用编排还是编排？

· 我们应该如何托管代码？

还有更多……

这些问题的每一个答案都应以”取决于……”开头，并以对背景和受该答案影响的人的看法结尾，然后作出决定。

可以使用流行的默认答案。

这不是唯一的答案。

摘要

黄金法则：无论问题是什么，答案几乎总是以”取决于……”开始

来自软件的一些功能：

· 我们为其他人而不是为计算机编写软件

· 编写软件的上下文对问题的答案有很大的不同

· 我们需要采取平衡的观点，考虑各种可能性，然后下定决心，最合适的答案是什么，而不是用默认的答案来回答。

嗨，我是Doogal，我是技术负责人，花了很多年的时间从几个非常有才华的人那里学习软件工程。 当我开始指导工程师时，我发现我认为应该继承很多知识。 这些故事是我尝试付出的方式。

我可以在Facebook，LinkedIn或Doodl.la上找到。