Перевод статьи «Do it like an engineer».
Задача разработчика программного обеспечения – решение задач. К этому действию можно свести буквально все. Поэтому важно иметь какие-то устоявшиеся подходы к нему. В конце концов, мы же разработчики, нас учили решать задачи. И мы должны делать это именно как разработчики.
Разберитесь с требованиями
Первый шаг – понять требования. Для решения задачи вы должны точно понимать, в чем она состоит. Был у меня случай, когда работа над фичей должна была занять 2-3 недели, а превратилась в три бестолковых месяца, заполненных «Ой, а здесь еще…», «О, а об этом мы не подумали!» и «Может, было бы лучше, если бы…». Это была моя вина. И я усвоил урок.
Приступая к решению задачи, убедитесь, что понимаете исходную точку, конечную цель и препятствия между ними. Худшее, что может с вами случиться, это выдача решения, которое не делает того, что ожидалось.
И, наконец, помните, что вы и только вы определяете, как решать задачу. Это ваша работа. А люди, выдающие вам требования к новому функционалу, должны сделать это как можно лучше – это их работа. И если кто-то, не являющийся разработчиком, пытается рассказывать вам, как нужно решать задачу, дайте ему в нос. Вас все поймут. Я уж точно пойму.
Определите размер
Каждый согласится, что обслуживание 100 тысяч запросов в секунду несколько отличается от обслуживания 100 запросов в минуту. Подходы к решению этих задач будут разными. Вот почему так важно понять «объем входящих данных» или, иными словами, определить, насколько велика задача. Без соблюдения этого пункта возможны два сценария дальнейших событий.
В лучшем случае вы потратите шесть месяцев на проектирование и реализацию системы, которая будет использоваться на 10%. В худшем случае вы потратите один месяц на проектирование системы, которая будет использоваться на 180%. Если в лучшем случае у вас будет просто потеря времени и ресурсов, то худший лучше даже не представлять. Чтобы избежать подобных ситуаций, мы должны задавать правильные вопросы.
- Сколько запросов должна обслуживать система?
- Каково ожидаемое время ответа?
- Сколько у нас ресурсов?
- Как насчет дедлайнов?
Правильные вопросы зависят от контекста, но цель у них одна-единственная: понять размер задачи.
Встаньте на плечи гигантов…
Я открою вам секрет. Вероятность, что кто-то другой уже решил вашу задачу, весьма высока. Очень высока. Все, что вам нужно сделать, это поискать в литературе, есть ли подходящее для вашего случая готовое решение задачи. Избегайте кустарных решений известных проблем: они лишь порождают новые проблемы. Есть множество компаний, у которых «свой Hibernate», «свой Kafka» и т. д., потому что:
- «У нас отличается use case» (хотел бы я на это посмотреть)
- «Производительность технологии Х для нас недостаточна» (серьезно?)
- «Мы можем сделать это лучше» (вот это смешнее всего 😆)
В общем, разобравшись с требованиями и размером задачи, поищите готовое решение. Нет никакого смысла изобретать велосипед заново.
…Но помните, что вы не гигант
Надстраивать что-то свое на основе существующих решений это нормально, однако старайтесь не переусердствовать. Помните, что вы не Google. В имеющемся океане крутых технологий самые известные / инновационные / используемые не всегда являются самыми подходящими для вас. Разворачивать Kafka-кластер для обработки 5 сообщений в день, пожалуй, не лучшая идея. Выбирайте технологии, которые выполняют нужную задачу с минимальными сложностями. Такое решение окупится в долгосрочной перспективе.
Бабушко-ориентированная разработка
Когда реализуете свое решение, старайтесь сделать так, чтобы оно было понятно вашей бабушке. Избегайте замысловатых и слишком сложных решений. Откажитесь от них ради более простых и понятных. Благодаря этому ваш код станет более поддерживаемым. Отложите оптимизацию до момента, когда она будет необходима.
Выражаясь более формально, при реализации своего решения следует придерживаться правила о наименьшей мощности. В оригинале это правило касается выбора языка программирования. В нашем контексте оно может звучать так:
«Среди доступных решений выбирайте наименее мощное из способных решить вашу задачу».
Я усвоил это правило, когда начал использовать функциональное программирование. Оно позволяет реализовывать элегантные решения, которые, однако, порой бывают слишком сложными. Я предпочитаю решения немного менее элегантные и эффективные, но зато намного более понятные и поддерживаемые. Ваш код будете читать не только вы.
Заключение
Мы разработчики, и наша работа состоит в решении задач, в какой бы форме они ни появлялись. Чтобы прийти к верному решению, нам нужно задействовать свои инженерные навыки и анализировать задачи с прагматической точки зрения. Мы должны помнить, что верное решение не то, которое просто выдает желаемый результат. Верное решение делает это с наименьшими усилиями и наименьшей сложностью.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]