Всякий раз, когда мы думаем о технологиях, легко представить образы кодирования, малопонятных языков и неразборчивой терминологии. До того, как я занялся индустрией, цифровой дождь Matrix был для меня аналогом технологий.

Хотя изучение надежных методов разработки программного обеспечения, контроля версий и обновления новейших библиотек очень важно для достижения успеха, многие сложности кодирования можно разбить на более удобоваримые логические потоки. Код следует рассматривать как средство для достижения цели, а не как саму цель. Представьте себе плотника, который строит письменный стол. Первая задача состоит не в том, чтобы думать о том, какой молоток использовать, а в том, чтобы представить этапы и дизайн конечного продукта.

До того, как я занялся технологиями, я очень мало знал о программировании. Я впитал все, что мог, на своей первой работе и прошел несколько онлайн-курсов по SQL и Python. Эти навыки помогли мне по-новому взглянуть на технические проблемы. Однако после нескольких лет развития моих навыков я считаю, что более важно думать о том, «что» и «почему» в решении проблемы, а не о том, «как».

Рабочий пример

Чтобы проиллюстрировать этот подход, давайте представим, что у вас есть база данных с информацией о клиентах. Для простоты предположим, что есть таблица заказов клиентов и таблица местоположений клиентов.

Если вы хотите использовать SQL для просмотра того, что было продано клиентам в Миннеаполисе, как бы вы к этому подошли? Если вы немного знаете SQL, возникает соблазн сразу же приступить к написанию кода для извлечения данных. Однако, даже не зная SQL, мы все же можем решить проблему и прийти к некоторому псевдокоду, который делает то же самое.

Давайте сначала ответим на вопросы «что» и «почему». Что мы пытаемся сделать? Мы хотим получить информацию о заказе для клиентов из Миннеаполиса. Это означает, что мы, вероятно, хотим включить всю существующую информацию из таблицы заказов клиентов и применить некоторый фильтр к городу. Зачем мы это делаем? Мы стремимся получить представление о наших продажах клиентам в Миннеаполисе, чтобы потенциально оценить нашу работу на этом рынке. Исходя из этого, вероятно, было бы неплохо включить город, из которого поступил каждый заказ, в наш окончательный результат.

Теперь, когда мы ответили на вопросы что/почему, мы можем подумать о разработке нашего подхода. В таблице заказов клиентов перечислены все детали заказа, включая CustomerId. Это идентификатор, который сообщает нам, какой клиент сделал заказ. Затем у нас есть таблица местоположения клиентов, которая сообщает нам, где находится каждый клиент. С точки зрения высокого уровня нам нужны все данные из таблицы клиентов, но мы хотим сохранить только те заказы, которые расположены в Миннеаполисе. Это говорит о том, что нам нужно получить данные из обеих таблиц, а затем применить условие к городу.

Давайте теперь суммируем шаги, которые мы можем предпринять для достижения нашей цели.

1) Get all the data from the CustomerOrderTable
2) Get the city from the CustomerLocationTable
3) Join together the data from Step1 and Step2 based on the CustomerId
4) Only keep the resulting data from Step3 that is from Minneapolis

Ниже приведен некоторый псевдокод, который можно использовать для достижения этой цели. Инструкции написаны по порядку сверху вниз (это не на известном языке, просто пометки о том, что бы я сделал).

get Data from CustomerOrderTable
get City from CustomerLocationTable
join CustomerOrderTable and CustomerLocationTable as FinalTable by CustomerId
keep Data from FinalTable where City is "Minneapolis"

Эти инструкции извлекают данные из обеих таблиц, создают новую таблицу, содержащую все данные, а затем применяют фильтр, где городом является Миннеаполис. Независимо от того, используете ли вы SQL или другой язык, этот подход применим повсеместно. Теперь, когда мы знаем, что/почему, мы можем, наконец, перейти к нашему набору инструментов и применить SQL.

SELECT CustomerOrderTable.*, CustomerLocationTable.City
FROM CustomerOrderTable
INNER JOIN CustomerLocationTable
ON CustomerOrderTable.CustomerId == CustomerLocationTable.CustomerId
WHERE CustomerLocationTable.City == "Minneapolis";

Приведенный выше сценарий является допустимым SQL. Если мы посмотрим на этот код, мы увидим тот же тип шаблона из нашего псевдокода. Мы получаем все данные из таблицы CustomerOrderTable (обозначается символом «*»), а также город из таблицы CustomerLocationTable. Мы делаем то, что называется внутренним соединением двух таблиц, соединяя их по их общему столбцу CustomerId. Внутреннее соединение гарантирует, что мы храним только те записи заказов клиентов, которые имеют связанную запись в таблице местоположений. Наконец, мы гарантируем, что город равен «Миннеаполис». Выполнение этого кода возвращает следующее.

Сначала дизайн, потом код

Приведенный выше пример показывает, как интуиция и дизайн должны предшествовать любым конкретным техническим подходам. Если вы сможете рассуждать о том, какую задачу вы пытаетесь решить и почему это важно, ваше решение будет основано на этих ответах. Даже если вы мало что знаете о конкретном языке/инструменте, который используете, понимание проблемы и ее разбивка на части позволят вам преуспеть в постоянно меняющейся технологической среде. Языки программирования, библиотеки и фреймворки развиваются. Но основные навыки решения проблем никогда не выходят из моды.