Все
Истории
Дизайн
Код
Геймдев
Бизнес
Маркетинг
Управление
Кино
Музыка
Проектная фотография
Развитие
Здоровье
Деньги
Образование
EdTech
Корп. обучение
Блог Skillbox
Глоссарий
Спецпроекты
Профориентация
«Мне пофигу — главное, чтобы работало», или Лучший совет программисту
Не затягивайте выпуск продукта в угоду академическому подходу и случайным голосам из интернета, которые указывают вам, что и как делать.
Зак Шапиро
(Zack Shapiro)
об авторе
Редактор в Better Programming. Ведёт проект Moneyball, который помогает зарабатывать на Medium.
Когда-то я работал под началом очень правильного техлида (tech lead). Помню, как день за днём он переписывал программный код — даже промежуточные решения, которые должны были прослужить лишь пару недель или того меньше. Он пытался сделать код более совершенным и организовать файлы по уму, а в перерывах читал в сети о шаблонах проектирования и о том, как всё должно быть устроено в нашей кодовой базе.
Мы просрочили выпуск приложения уже на три месяца, а у нас не была готова даже первая версия. Пока другие члены команды реализовывали функциональность, техлид всё экспериментировал с кодом и структурой файлов — переписывал раз за разом, пытался всё сделать идеально. Так шла неделя за неделей, а работающего приложения всё не было. В конце концов об этом узнал наш технический директор (CTO).
После выпуска приложения наш техлид покинул компанию, а меня повысили и я занял его кресло. И тут я заметил кое-что странное — почувствовал, что должен продолжить его традиции. Я вовсе не переписывал код раз за разом, но в меня будто вселился тот же дух перфекционизма.
Как-то раз, уже после повышения, я делал сквозную авторизацию для наших корпоративных клиентов. Мне нужно было написать одну функцию — совсем небольшую (пять строчек кода, не больше).
И тут меня накрыло вопросами и сомнениями:
- Как лучше её написать? И куда её потом впихнуть?
- Размещать её в отдельном файле? Или, может, вместе с другим кодом сквозной авторизации?
- Должен ли это быть класс с одной открытой функцией?
- Раз уж она такая маленькая, то приткнуть бы её куда-то и забыть. Но вот только будет ли это правильно?
В меня будто вселилась тень перфекциониста. Я перенял его образ мышления. Залип над решением, которое, в сущности, ни на что не влияло — и даже не было важно для заказчиков, которые платили нашей компании.
Принять решение самостоятельно я так и не смог. Тогда я отправился к нашему вице-президенту по проектированию (VP of Engineering) и спросил его, как лучше поступить с этой маленькой функцией. Я уже внутренне был готов к долгой дискуссии — вроде тех, какие бывали с моим бывшим техлидом.
Но разговор был коротким. Прозвучавший ответ навсегда изменил мой подход к программированию и работе вообще:
«Мне по барабану. Главное, чтобы работало».
И я вдруг почувствовал себя свободным.
В конце концов, я же техлид! И это моя команда!
Наша задача была простой — поскорее выкатить готовый продукт. И всем нам не нравился предыдущий подход, основанный на академичности, перфекционизме и статьях из интернета. Так почему я должен беспокоиться о том, понравится ли наш код кому-то постороннему, соответствует ли он чьим-то представлениям о правильности?
Подходы и лучшие практики со временем меняются. Поверьте, я редактор Better Programming и знаю, о чём говорю 😊. Пост в блоге может быть правильным в теории, но совершенно бесполезным на практике.
В общем, тот разговор с VP навсегда изменил мой подход к управлению командой.
Я понял, что моё промедление было замаскированным страхом.
«Запомните свой вопрос. Мы вернёмся к нему после релиза»
Теперь я частенько произносил эти слова. И все в команде помнили, что должны сделать прежде всего. Мы создавали фичу, тестировали её, исправляли баги, помечали задачу выполненной и переходили к следующей. А список того, к чему нужно вернуться, лежал где-то в сторонке.
Мы выпускали релиз за релизом, а катастрофы всё не было — несмотря на то, что код наш был далеко не совершенен.
Это абсолютно нормально, если у вас есть стандарты для кодовой базы и вы выбрали лучшие практики для своей команды и компании. Но если ваша команда работает медленнее из-за того, что каждому нужно подгонять код под определённый стиль или чьи-то твёрдые инженерные убеждения, то вам понадобится гораздо больше времени, чтобы получить результат.
Так что неважно, учитесь ли вы кодить или уже давно строите карьеру программиста. Больше времени уделяйте тому, чтобы заставить код работать. И меньше — чтобы подогнать его под чьи-то ожидания.
Ваш код должен быть безопасным, надёжным и относительно эффективным. Но помните, что всегда будет задел по времени, когда недостатки кода не грозят компании убытками — просто потому, что пока ещё ваш код работает «не в тех масштабах». Поэтому не заморачивайтесь! Главное, чтобы он работал.
По мере развития проекта вы всё равно будете переписывать и улучшать код. Так что возвращайтесь к накопившимся вопросам после релиза — во время разработки следующей версии продукта.
Ведь если работающего приложения не будет в нужный срок, это обойдётся компании значительно дороже.
