Данная заметка навеяна мыслями от прочтения статей «9 анти-паттернов, о которых должен знать каждый программист», «Семь смертных грехов разработки ПО» и многих других похожей тематики. Мне действительно всегда очень интересно и приятно узнать о том, как можно делать что-то «хорошо», или даже еще лучше. Согласитесь — ведь это здорово! Здорово знать о дизайн-паттернах и уметь их правильно применять при проектировании своей программы; здорово также знать и об антипаттернах и уметь обнаруживать их в своём или чужом коде, уметь их устранять. Здорово знать о тестировании и оптимизациях, о рефакторинге и профилировании и многом другом, что делает программы более быстрыми, экономными и эффективными, а программистов и пользователей — счастливыми.
Но вот с некоторых пор питаю некоторое отторжение (иногда даже отвращение) к подобного рода статьям. И вот почему. Есть две стороны медали, как бы это не было банально — с одной её стороны есть десятки и сотни тысяч it-компаний так или иначе связанных с разработкой ПО, где процесс разработки этого самого ПО — есть процесс «исторически сложившийся», характерный только для одной этой компании, и характеризующийся точнее всего как «закат солнца вручную».
Здесь нет систем контроля версий, или в лучшем случае используется svn (или другая устаревшая SCM) представляющая из себя такую же кодовою помойку, что и её отсутсвие, просто с более очерченными границами, где каждый участник разработки пишет коммиты так как ему заблагорассудится — в любом регистре\склонении и на любом языке, и даже вообще без какого-либо сообщения об изменениях.
Здесь не пишутся тесты на код, что, конечно может быть оправдано в ряде случаев, но процент таких оправданных случаев неимоверно мал, в отличии от количества проектов, где тестирование действительно необходимо.
Здесь нет документации на используемый (написанный ранее) код, или версия API описанная в документации отстаёт от актуальной версии продукта на несколько версий\месяцев\лет. Потому, что документацию скорее всего написали очень давно и делал это какой-то один конкретный человек и делал это единожды, для актуальной в то время версии.
Также печально дела обстоят с такими неотъемлимыми компонентами профессиональной разработки как таск-менеджеры и баг-трекеры, инсталяторы и различные упаковщики пакетов, системы интернационализации и локализации, и многие многие другие, в конце концов — сайт компании и\или продукта. Некоторые из этих компонентов отсутствуют вовсе, а другие представляют из себя такие костыли, которые вместо того чтобы облегчить процесс разработки, только еще больше его усложняют, и как правило — либо вовсе не используются большинством программистов компании или используются с неохотой, просто потому, что «так надо».
И вообще, в таких компаниях очень любят напомнить что «програмирование не самоценно», и что компании нет дела до таких мелочей как тексты коммитов или имена переменных, её интересует конечный результат, достигнутый при этом в заданный срок. Всё это несомненно верно, но только вот забывают менеджеры этих компаний — что на конечный результат, все эти мелочи как раз и влияют, и чем больше перспектива развития продукта (и следовательно благополучия компания) тем большее влияние они оказывают на этот самый результат.
С другой же стороны медали, есть относительно небольшое количество компаний, где топ-менеджеры и тимлиды действительно озабочены реальной продуктивностью своей команды, и они внедряют в свои бизнес-процессы такие элементы как code-review, code-style и code-convention, системы тестирования и системы непрерывной интеграции и т.д. и т.п. Они не поощряют и не допускают использованя антипаттернов в своих продуктах. Они непрерывно тестируют свой код. Они используют Docker и разворачивают свои инфраструктуры в облаках. Они не только используют git, но и вырабатывают четкую схему ветвления проекта, именования веток и сообщений комитов. Они пишут документацию на разрабатываемый ими продукт, как для разработчиков так и для пользователей продукта. Они используют баг-трекер и\или таск-менеджер для распределения задач внутри команды и контроля их выполнения, в конце концов они используют Slack (или другой подобный сервис) — как для чисто технического общения, так и для общения неформального, что также не мало важно и способствует слаженности команды. Но главное, — обо всём этом или по крайней мере о многом, они пишут в свои личные и корпоративные блоги, в том числе и на хабр, что безусловно полезно и правильно. Но… Но, таким образом создается впечатление, что тот набор интрументов, технологий и методологий о которых они пишут, используется если не во всех, то как минимум в большинстве компаний разрабатывающих софт, а это, к сожалению, не так.
И вот простая ситуация: есть молодой программист, желающий работать и развиваться профессионально. Он не только прочитал основные книги выбранного им языка программирования, будь то Python, C++ или какой-либо другой, но также и такие фундаментальные вещи, как «Совершенный код», «Алгоритмы. Построение и анализ», «Приёмы ООП. Паттерны проектирования», «Проектирование и рефакторинг», «Идеальный программист», «Экстремальное программирование. Разработка через тестирование» и т.п. Он владеет основами git, тестирования и документирования кода, а главное — он действительно хочет писать полезный и хороший код, используя при этом все свои знания. И вот он приходит на работу в компанию, где ему говорят: вот эта 3-х гиговая папка — наш проект, ну то есть тут не только проект, тут вся наша платформа, вспомогательные утилиты и несколько десятков проектов, но что именно нужно для того чтобы работать над одним конкретным проектом — никто не знает, поэтому скачать нужно всё, иначе ничего не заведётся. А используем мы С++98, Qt3, Python2 и WindowsXP. Да, и проекта, как такового нет, тут просто папочка c несколькими тысячами файлов, которую можешь открыть в vim и работать с нужным тебе файлом. Что? Какая ещё IDE? какой отладчик? Зачем тебе все это!?
Поймите правильно, — он не против vim, он любит vim, но vim не IDE. Гвоздь можно забить и топором и плоскогубцами, но лучше и правильнее — молотком. Он также не против отладки путём втыкания в нужные места различных put, debug() print(), printf() и console.log() — он отдает предпочтение таким приёмам в 95% случаев, но иногда и стек посмотреть нужно, и мало ли еще что. Он вовсе не против традиций, заведенных в компании, ему просто не понятно — зачем? Зачем не использовать возможности интегрироанных средств разработки, интерактивных дебагеров, профилировщиков и т.п. Зачем? Зачем он так долго читал про то, как делать «хорошо», если делать «кое-как» намного легче, и ничего знать для этого не требуется? Зачем ему понимать важность тестирования и не использовать его? Зачем?
Кто-то скажет — он неверно выбрал компанию, нужно просто перейти в другую, из той самой второй категории. Только вот компаний из первой категории — большинство, или я ошибаюсь? В крупную компанию уровня Yandex, JetBrains, Mail.ru и т.п. разве берут вчерашних студентов? Берут конечно, но только если у вас в резюме вдруг оказалось кроме вчера полученного диплома — 5+ лет опыта разработки в комерческой сфере. Да и диплом желательно иметь из «ведущих ВУЗов», остальные — извените, проходите мимо, в крайнем случае — «мы вам перезвоним», ага, жду…
На волне популярных историй успеха, описанных создателями различных стартапов в последние несколько лет, кто-то очень удачно заметил: истории успеха ничему не могут научить — они лишь хвастовство, но научить (или скорее предостеречь) могут истории «неуспеха». Только вот историю успеха рад написать любой, в отличии от историй неуспеха, несмотря на то, что историй неуспеха в разы больше, на порядки больше…
Данная заметка тоже вобщем-то — история неуспеха. Такого неуспеха, о котором не напишет менеджер компании, ведь он даже о ней не подозревает…
ссылка на оригинал статьи http://habrahabr.ru/post/260283/
Добавить комментарий