软件开发很少被提及的方面

　　最近，我经历了半天的时间来实现某种功能，并更改了代码库中的许多内容。 我正在努力处理一个测试用例，并要求同事进行澄清。

　　到那时，我发现大部分逻辑是完全不必要的，因为我根据对该功能的解释做出了错误的假设。

　　提示悲伤的音乐。

　　如果我只花时间来检验我的理解，我本可以节省几个小时的工作。

　　生产者的假设是生产者

　　在Alberto Brandolini在2021年欧洲域名驱动设计大会上的演讲中，我想起了这一事件，他说：

　　"这是开发人员投入生产的假设。"

　　这真的打我。

　　作为软件开发人员，我们不仅应该知道如何编程，而且应该具有足够的领域知识来编写正确的东西。 最终，我们的理解反映在我们编写的代码中。

　　我将第一个承认，有时，我只阅读了有关机具的任务的标题，进行了更改并提出了拉取请求。 有时候这适用于较小的功能和故障单，但要实现更大的功能，则根本不起作用。

　　如果幸运的话，在请求请求期间会发现错误的假设。 如果您不走运，则会在质量检查期间甚至在应用程序审查期间被抓住。

　　现在，不仅要返回并更正您的假设，还需要创建新票证和新的拉取请求。 浪费每个人的时间，并可能不得不重写整个功能。

　　所有这些都是由于基于票证标题的假设以及一个月前进行的改进期间的讨论。

　　尽管实际上阅读接受标准可以大大避免上述情况，但是产品所有者和利益相关者也是人。 我们都会犯错误或认为某些事情是显而易见的。 接受标准可能不完整。

　　因此，作为软件开发人员，我们应该牢记这一点，并询问我们何时进入未知领域，即使您并不感到未知。

　　避免越过栅栏最低的地方

　　专注于技术解决方案非常容易，因为这是我们作为开发人员所了解和理解的。

　　建立所有微妙的微服务架构很酷。 调用所有微服务以完成所有任务-并不是很酷。

　　因此，即使解决方案是一项技术专长，也是最新，最伟大的技术的艺术品，它也可能完全达不到目标。

　　我曾经帮助监督Python课程的考试。 这是第一次考试是数字化的，申请非常酷。 该应用程序具有内置的外壳，自动分级功能，并已部署在Kubernetes集群中。

　　它过去挺美。 直到400名学生必须登录才能立即使用。

　　在所有学生都登录之前，过了30分钟。答案没有保存下来，会话有问题。 那是一场噩梦。 本来可以为我们节省评分时间的系统最终导致评分延迟了数周。

　　应用程序的复杂性使其在重负载下完全不可预测，并最终导致其无法满足主要要求-保存考试并为其评分。

　　花点时间确保您实际上满足了用户的需求，这可能意味着成功的应用程序与失败的应用程序之间的区别。

　　结论

　　了解域听起来像是产品所有者或提出要求的人员的工作。

　　但是，您不是代码猴子。 您无需消耗需求并返回代码。 您有责任确保所编写的代码尽可能正确。

　　尽管您可能永远不具备领域专家所拥有的知识水平，但是您可能了解得足够多，可以在请求请求中发现错误的假设，或者能够做出可持续的基础架构决策。

　　因此，当您偶然发现对您而言毫无意义的内容时，请与您的领域专家联系。 询问为什么必须这样满足接受标准。 谁知道您会找到什么。

　　请记住，除了编写代码之外，软件开发还有很多其他内容。

　　感谢您的阅读！