Когда проект считать большим

Все попытки выразить “большевизну” проекта через абсолютные пороги считаю уязвимым в реальном мире. Предлагаю другую систему отсчёта.
Большим проект становится тогда, когда перестаёт быть контролируемым. Вот и всё. Такое бывает с первой же строки кода, бывает через год, бывает через десять.

Признаки потери контроля следующие…
Во-первых, уже нет человека, который знает о проекте всё. Экспертиза расползается по множеству людей. Чревато потерей экспертизы, т.к. Ваня знает про модуль X, часть знаний передал Пете, потом уволился, Петю бросили на модуль Y, Игорь срочно фиксил модуль X безо всяких знаний о нём и т.д.
Во-вторых, уже есть участки, на которые отсутствует документация и/или тесты. Фактически это означает отсутствие хоть сколь актуальной спецификации. Впрочем, если говорить строго, то отставание спецификации от актуальности является тем же отсутствием.
В-третьих, уже есть участки, поведение которых вы не можете предсказать [без дополнительной проверки] при изменении других участков. Вот это довольно тонкий момент, частью следующий из первых двух. О нём отдельно ниже.
Это три кита потери контроля. Нет экспертизы. Нет спецификации. Нет детальной картины системы.

Подтема этого эссе — Python на больших проектах в production’е. В текущий рабочий период могу плотно наблюдать Python на сервисе в 100K+ LoC. И могу с достаточной [для меня] степенью достоверности оценивать стоимость обеспечения хоть какого SLA такого сервиса. Так вот, если у вас нет батальона разработчиков и целой жизни на каждую задачу, не делайте современные большие сервисы на чём-либо, что не C++ или Java.
Да, вы можете взять другой язык. Но обязательно наступите на грабли разного рода — от поиска специалистов на рынке труда (сейчас даже на одного толкового питониста по три толковых джависта, что уж говорить про Go / Rust / Swift) до выстрела в рантайме на пустом месте в рандомное время (которое стопудово будет новогодней ночью, например, по закону подлости).
Да, вероятно, у вас даже получится что-то годное сделать и жить с ним (Facebook и PHP тому примером). Вероятность, правда, 1:100, а задачи могут превратиться в “как сделать интерпретатор лучше” (и снова Facebook), при этом пацаны на C++ и Java со многими вашими проблемами даже не столкнутся.
Но лучше не бросать мины по ходу движения.

Так вот, языки типа Python / JavaScript способствуют потере контроля.
Вы меняете строчку кода. Собираете пакет. Катите. Взрыв через неделю. Почему? Потому, что у вас 100K+ LoC, не каждая строка покрыта тестами (напомню, нет батальона разработчиков), а синтаксически всё норм.
При загрузке модуля интерпретатор и не вякнет о том, что дёргается функция с несуществующей сигнатурой. Не вякнет о том, что в рантайме у объекта трогается отсутствующий member. Уж тем более не в силах вякать в ситуациях, когда активно используется reflection и около него. Вообще потрясающе редко вякает, надо сказать. Что можно понять, т.к. в том же рантайме этот member может появиться. Или измениться. Или морфировать в нужный тип. Вообще всё произойти может.
Потому отхватить эффект бабочки в любой момент проще простого. И таким макаром вы теряете предсказуемость проекта довольно быстро. Если нужен абсолютный психологический барьер, то пусть 100K LoC.
А прохладные советы быть внимательнее, на всё писать тесты и вообще писать правильно я как слышал, так и сам выдавать могу (и даю, кстати). Дайте мне десять senior разработчиков, год кропотливого написания кода и полноту власти устроить фашизм, сделаю сервис и процесс тютелькой в абзацы учебников. А если ещё и бюджет дополнительный дадут на закупку и доработку нужного инфраструктурного софта, так вообще. Только вот реальный мир выглядит ни фига не так.

Сюда же можно добавить потерю самодокументируемости кода. Хоть кол мне на голове разбейте, но никакой самодокументируемости у Python / JavaScript нет. Чтобы она появилась, надо писать на малом подмножестве, которое не использует всякую весёлую динамику, но тогда смысл был выбирать не C++ / Java? А если использовать, то фиг вы всегда угадаете, откуда и с какими параметрами вызывается та или иная функция. Ладно я с розовыми глазами по ночам, но у меня IDE цепочки вызовов раскрутить не могут иногда, потому приходится занятно извращаться, выясняя, откуда и какой вызов прилетает (как и линтеры, кстати, часто ошибаются, потому тоже фиг надежды на).
И если в тяжёлых случаях с C++ / Java вам поможет глубокое качественное и количественное знание языка (чтобы разобрать особо мудрёные небоскрёбы generics hell, например), то в Python / JavaScript не поможет.

Уф. Чё в итоге из этого сумбура, набитого на перекурах? Язык здорово влияет на субъективный размер проекта. Выбрал Java? Получи “большой проект” после 300K LoC. Выбрал Python? Получи после 100K LoC. JavaScript? Пусть 50K LoC.
Считаете иначе? Ну… Беглый тест: берёте Django (Python), берёте Spring (Java). Подгружаете в нормальную IDE (PyCharm и IDEA, соответственно). Ну и начинаете изучать код. Ходить туда-сюда, строить схемы, прикидывать кейсы. Если и после этого вам покажется, что разницы нет, эссе писалось не для вас.

Добавить комментарий