Skip to content
Павел Бородин

Что по коду?

Dev2 мин. на чтение

Хотел бы затронуть тему, о которой все знают, но мало кто решается о ней заговорить. Это — качество кода.

Код — это поэзия

Каждый, кто так или иначе связан со сферой разработки понимает, что бывают разные задачи, клиенты и сроки. Многие стартапы и небольшие компании приверженцы методологии LeanStartup или запуска MVP продуктов. В рамках тестирования гипотез и быстрого развертывания проектов, - это отличные методики, но в них есть одна большая проблема, которая проявляется при попытки масштабирования продуктов.

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

И казалось бы, что в этом плохого?

Очень часто, в дальнейшем, подобные продукты, прощупав свою нишу или осознав, что их продукт или услуга востребованы, начинают делать попытки масштабирования (прикрутить новые способы оплаты, сделать интеграцию с CRM системой или привязать чат-ботов, к примеру) и как-раз в этот момент натыкаются на то, что…. Да просто не выходит.

У них в голове уже сформировалась мысль, что все это можно сделать быстро и вложив минимум финансов. И зачем делать с нуля, когда уже есть готовая наработка? Но никто не будет браться за такую работу.

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

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

Есть такое выражение — Индусский код (в среде программистов 80х также известен как Glitch) — в самом общем случае, это криво написанный, но каким-то удивительным образом работающий код. Индусский код написан наиболее неочевидным и неестественным из всех возможных способов. Именно этим он и отличается от быдлокода, который хотя бы капельку очевиден и сделан, хоть и по детсадовским, но по правилам.

Так вот, чаще всего я встречался с таким кодом, как-раз в молодых проектах, которые пытаются расширяться.

Что делать?

Самое верное решение, - убедить клиента в том, что не рационально тратиться столько времени сил и денег в попытке прикрутить козе баян.

Проект выполнил свою целевую задачу, — он позволил прощупать нишу и востребованность продуктом. Теперь необходима разработка решения с четкой структурой, логикой, понятным и разделенным кодом. Все это позволит создать продукт, который будет покрывать все 100% потребностей клиента, которые есть сейчас и с возможность расширять его.

Разработка подобного продукта дело весьма ёмкое по времени и силам, но на выходе получается действительно стоящее решение, с которым приятно будет работать.

Основные тезисы

  • Под каждую задачу необходим свой набор инструментов и варианты решения;
  • Хорошая разработка полноценного ресурса, который будет масштабироваться и выдерживать нарастающие нагрузки требует большого количества времени и, как следствие, денег;
  • Индусский код — зло. В любом виде. Даже если речь идет о быстром запуске продукта, не надо совсем пренебрегать его качеством.
© 2021 Павел Бородин. All rights reserved.