Красиво решать задачи



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



Мой любимый критерий красивого решения — время. Причем время не календарное (если ваша команда не может делать задачи быстро, вам не до «красивости»), а относительное. Почти любую сложную задачу можно решить быстрее, чем при помощи первого пришедшего в голову варианта: не пилить микросервис, а сделать кеширование; не рефакторить все приложение, а сделать микросервис; не писать новый компонент, а допилить и переиспользовать старый.



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



Красивое и быстрое — так: заказчик пришел с проблемой → быстро снимаем боль → решаем другие задачи, параллельно думаем над красивым решением → как только придумали — выкатываем, если ничего не придумали, то записываем техдолг.



К сожалению, чтобы в продукте появлялись красивые и эффективные решения, нужна целая экосистема, т.н. «культура разработки»: сильные тимлиды, отсутствие авралов, разумный техдолг, умение ставить задачи-проблемы вместо задач-решений, вести диалог и еще много всего. А без экосистемы программисты думают не над эффективностью, а над тем, как сделать, чтобы от них отъебались.