后端开发哲学

Question

在我现在尝试的这个后端开发过程中，我感到有些迷茫。我在开发客户端应用程序时使用的大多数常规开发实践在这里不适用.让我提供一些背景情况。

调试过程

在开发客户端应用程序(iOS、Java桌面应用程序或其他应用程序)时，很容易在您喜欢的IDE上快速安装项目，让它在您的计算机或测试设备上运行，并尽可能地调试它。

另一方面，将调试器与后端代码挂钩并不是那么简单，特别是如果它是运行在Google (GAE)上的python代码。这就是我要用的，而且..。嗯。指针和所有这些都有很大的帮助，但是语义问题显然不能用这种方式解决。

目前，我正在检查我最近编写的后端代码，并将其填入logging.debug('msg')语句、断言等。这是我唯一能想到的。这对后端开发人员来说是正常的吗？日志记录和挖掘日志通常是后端开发人员如何迭代它们的应用程序吗？

并行性与请求驱动

老实说，这可能对GAE和其他非阻塞后端更具体一些。单线程服务器不受此问题的影响.无论如何，当您处理并行性时，当所有事情都由套接字事件驱动时，后端开发人员通常如何测试他们的后端是否工作呢？

我做了有史以来最天真的一件事，那就是打开python控制台，使用请求库，只需要一点一点地发送请求和测试。然后，我继续编写了一个kivy应用程序来帮助我从GUI界面发送请求并查看发生了什么，但是维护这个kivy应用程序比开发后端要花费更多的时间！！我试着检查GAE的测试框架，但它们似乎不容易得到，所以我想知道它们是否值得？我是否能够使用我的后端使用测试框架来模拟1000多个客户端？现在人们使用什么(特别是GAE )？

可视化“流”

由于我对后端开发缺乏经验，我很难在脑海中清晰地看到请求/响应周期。我知道基本知识，我写了一些后端应用程序，但一旦它变得有点复杂，我必须不断提醒自己，通过查看入口点，所有的步骤，直到作出反应。我确信，如果我能以某种方式将它想象出来，我就不必一而再再而三地回去了。相反，我可以很容易地知道bug的起源位置，或者哪里是添加特定特性的最佳位置。

无论如何，我想知道是否有某种标准的“东西”来设计请求流。我不知道，也许是UML图什么的？我试着把它勾勒出来，但最后弄得一团糟。比如，我会根据特性和需求勾勒出后端的设计，但这样就忽略了实际的逻辑和模型。然后，我试着将它们包括在图表中，它变得过于复杂，并且充斥着许多奇怪的箭头和盒子。我需要后端开发的东西，比如ER图用于关系数据库设计。

是啊，对不起。我说了很多话，在这个世界上迷失了方向。帮助?

Answer 1

调试/测试！

• 单元测试出你的后端代码。它通常比单元测试前端代码更容易，因为代码不会等待任意的单击或按键。所有这些都是“数据输入，数据输出”。积极的单元测试将显着地加快您的速度，因为您不必一直回到起点来验证每一小部分代码。然后你会把这些测试作为回归测试。
• 有一个TDD (测试驱动开发)，它要求您首先编写测试，然后填写使它们工作的代码。但我只能半途而废，并声称我在使用“伦敦风格”。但如果你对此感兴趣的话，那是个好做法。
• 作为一个很高的目标:在Python中，我的目标是100%的测试覆盖率&这很容易实现。
• 我是那些几乎从不使用调试器的人之一。相反，我使用单元测试来让专家了解行为和合理的日志记录。但这只是我的偏好。

平行性

• 更重要的是让它在所有的IMHO上工作

视觉化

• 我发现这些图表对于我的工作是必不可少的:序列图，(较少的) ER图和状态图。
• 看看http://websequencediagrams.com。它将在一个复杂的项目上拯救您的生命，甚至在简单的项目上也能帮助您可视化客户机与服务器之间的交互。
• 如果您绘制了一个序列图，它不仅将显示客户机-服务器交互，而且指向您的服务的每个箭头都是您必须实现的API方法。非常方便，非常直接。
• 是的，当数据达到一定的复杂性时，我使用ER图进行数据库设计和类设计。
• 有时，状态图可能非常有用。

我的观点是，后端开发比前端开发更容易，因为我认为我的工作是“从这里到那里移动字节”。但这可能是因为我在正面发展方面真的很差。