手机屏幕xy坐标软件_软件工程中的xy问题

手机屏幕xy坐标软件

XY problem is classified as a communication problem in which the person who asks the question cannot communicate the problem statement clearly. This situation arises when the questioner needs to do X and they think they can use Y to achieve X so they ask how they can perform Y. However, they should really ask how they can solve X. Without the context of X, people who want to answer can only suggest how to solve Y. Meanwhile, there may be a solution Z that can solve X in a more efficient way.

XY问题被归类为沟通问题，其中提出问题的人无法清楚地传达问题陈述。 当发问者需要执行X并且他们认为可以使用Y来实现X从而询问如何执行Y时，就会出现这种情况。但是，他们确实应该询问如何解决X。在没有X的情况下，想要要回答，只能建议如何求解Y。同时，可能存在可以更有效地求解X的解决方案Z。

There are many instances of XY problems that happen every day in companies. The effect can be from being negligible to sucking resources out of the engineering team for years. There are some case studies from real life examples that help better describe the problem at hand.

公司每天都会发生许多XY问题的案例。 其影响可能是微不足道，甚至是多年以来从工程团队中抽出资源。 现实生活中的一些案例研究有助于更好地描述当前的问题。

案例研究：MySQL搜索 (Case Study: MySQL for Search)

In early stages of a startup that has thousands of users, it makes sense to go with the easiest solution that can solve the problem at hand and just keep the business up and running. However that solution may not scale well when the business gets to millions of users.

在拥有成千上万用户的初创公司的早期阶段，选择最简单的解决方案是有意义的，该解决方案可以解决当前的问题并保持业务正常运行。 但是，当业务吸引到数百万用户时，该解决方案可能无法很好地扩展。

An example is when MySQL was being used for performing search on customers and merchants. Since all the data was already in MySQL, it was the easiest solution to run query on the tables:

一个示例是使用MySQL进行客户和商人搜索时。 由于所有数据已经​​在MySQL中，因此这是在表上运行查询的最简单解决方案：

SELECT * FROM shop WHERE shop.name LIKE '%q%' OR shop.address LIKE '%q%'

SELECT * FROM shop WHERE shop.name LIKE '%q%' OR shop.address LIKE '%q%'

With thousands of rows and even without indexing, this returns results in a reasonable amount of time that matches UX expectations.

在具有数千行的情况下，即使没有索引，此返回结果也会在合理的时间内实现与UX期望相匹配的时间。

As the company grew, the number of rows also grew and we faced a different problem: Paging! Lots of thought went into how to implement a good paging that returns the closest result to the user’s current location. This meant we had to add more criteria to the SQL to include some math for user location. Since the logic was too complicated for ORM to handle, we had to switch to native queries, eventually bypassing the ORM.

随着公司的发展，行数也增加了，我们面临一个不同的问题： 分页 ！ 如何实施良好的分页，使返回的结果与用户当前位置最接近，引起了很多思考。 这意味着我们必须向SQL添加更多条件，以包括一些用于用户位置的数学运算。 由于逻辑太复杂而无法处理ORM，因此我们不得不切换到本机查询，最终绕开了ORM。

When we added international shops to our repository, we faced a new problem. We had to also search both English and the other language name and address. Our SQL looked like this:

当我们在仓库中添加国际商店时，我们面临一个新问题。 我们还必须搜索英语以及其他语言的名称和地址。 我们SQL看起来像这样：

SELECT * FROM shop WHERE shop.name LIKE '%q%' OR shop.i18n_name LIKE '%q%' OR shop.address LIKE '%q%' OR shop.i18n_address LIKE '%q%' [plus paging and user location logic]

SELECT * FROM shop WHERE shop.name LIKE '%q%' OR shop.i18n_name LIKE '%q%' OR shop.address LIKE '%q%' OR shop.i18n_address LIKE '%q%' [plus paging and user location logic]

With more users and merchants added to the system, the query was not efficient anymore. MySQL service connection exhausted and many downstream failures happened. At this point we didn’t know that the increase in number of connections was because of the inefficient search so we focused on healing the database by adding replicas and increasing the instance size for higher CPU and memory.

随着更多用户和商家添加到系统中，查询不再有效。 MySQL服务连接已耗尽，并且发生了许多下游故障。 在这一点上，我们不知道连接数量的增加是由于搜索效率低下所致，因此我们专注于通过添加副本并增加实例大小以提高CPU和内存的容量来修复数据库。

We had a group of engineers that were opinionated to using PostgreSQL instead since it has better performance. Another group debating migrating to a different cloud provider. They spent a lot of time