Но вот с некоторых пор питаю некоторое отторжение (иногда даже отвращение) к подобного рода статьям. И вот почему. Есть две стороны медали, как бы это не было банально — с одной её стороны есть десятки и сотни тысяч 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+ лет опыта разработки в комерческой сфере. Да и диплом желательно иметь из «ведущих ВУЗов», остальные — извините, проходите мимо, в крайнем случае — «мы вам перезвоним», ага, жду…
На волне популярных историй успеха, описанных создателями различных стартапов в последние несколько лет, кто-то очень удачно заметил: истории успеха ничему не могут научить — они лишь хвастовство, но научить (или скорее предостеречь) могут истории «неуспеха». Только вот историю успеха рад написать любой, в отличии от историй неуспеха, несмотря на то, что историй неуспеха в разы больше, на порядки больше…
Данная заметка тоже вобщем-то — история неуспеха. Такая история, о которой не напишет менеджер компании, ведь он о ней даже не подозревает…
Комментарии (39)
youlose
15.06.2015 12:18+6Про vim, вообще не в тему. Многие профессионалы используют vim/tmux/emacs и разрабатывают быстрее и качественнее чем остальные с навороченными IDE.
poxu
15.06.2015 13:06+2Совершенно не в тему. В случае, описанном в статье скорее будет проект для Eclipse или MSVS. Положенный прямо в систему контроля версий. Вместе с файлами, которые изменяются при каждом открытии проекта. А в ответ на замечание, что таким файлам в системе контроля версий делать нечего тебе посоветуют просто не комитить изменения в этих конкретных файлах.
Если проект действительно представляет из себя что-то, что можно редактировать текстовым редактором и собирать из консоли — это большое счастье. Ведь если программист действительно владеет своей IDE, то подключить её к такому коду не составит большого труда, правда?
RPG18
15.06.2015 13:27+1осоветуют просто не комитить изменения в этих конкретных файлах.
А не проще эти файлы в ignore записать?poxu
15.06.2015 14:23-5Ну можно сделать и так. Но записывать в игнор файлы, которые уже есть в vcs, технически непросто. Если кто-то случайно их закомитит, то они обязательно обновятся. И скорее всего vsc поймёт это как конфликт.
HunterNNm
15.06.2015 12:38+2Где же найти такую компанию, где всё так, как должно быть? Ведь в большинстве сидят эникейщики, каждый пилит свой проект/кусок кода, про комментарии или git знают единицы и из этих единиц их пользуют опять же единицы. Вижу вокруг просто неприлично огромное количество людей, которые для разработки используют блокнот++ или же редактор года этак 2006, про дебаг или тесты слышали, но пользовать не видят смысла, проф.литературу в глаза не видели, вместо чтения документации к инструменту и полноценного пользования пишут свои костыли. Подскажите, куда податься для реализации своих знаний человеку без заветного диплома престижного ВУЗа? Ибо я так и не нашел такого места, и вынужден сидеть, писать костыли, и иногда умничать про что-то новое…
vedenin1980
15.06.2015 12:54+3А язык программирования-то какой и что за город? У нас в Самаре, например, скорее нехватка специалистов, чем хороших компаний. Вообще, можно посоветовать участвовать в крупных open source проектах на популярных языках в свободное время, это самый лучший способ получить опыт, с которым потом можно придти в компанию мечты.
HunterNNm
15.06.2015 13:05ЯП самые разные. Сидит человек 10 и каждый костылит на своем… PHP, C#, Java, Python… Каждый решает задачи в меру своих знаний. Самая печаль — это когда надо взаимодействовать нескольким сразу… Но даже 2 специалиста, пишущих на одном ЯП, редко взаимодействуют. А с напрягом на работе ни на какой open-source сил не хватает… Город провинциальный, так что возможности уйти в другое место просто нет.
ServPonomarev
15.06.2015 14:34-1Поймите правильно. У каждого инструмента или технологии — своя сфера применимости. Крупное энтерпрайз решение невозможно без контроля версий, тестирования и прочих вещей, упомянутых в статье. В небольшой компании заниматься всем этим — просто тратить ресурсы, отвлекаясь от решения основной задачи. Энтерпрайз бы тоже отказался с большим удовольствием от всего этого, но не может — сложность уже превышает возможности ею управлять. Небольшая фирма может, а значит — должна, сэкономить.
VolCh
15.06.2015 16:50+3По нынешним временам даже единоличную разработку лучше вести с использованием git или hg. Для самого простого случая не нужно никакого сервера настраивать, достаточно несколько команд выучить.
vedenin1980
15.06.2015 14:38Попробуйте поискать удаленную работу, только нормальную где не просто фриланс, а именно работа в команде. Ну или попробовать переезд в другой город.
veitmen
15.06.2015 12:57Не важно, как вы сейчас решаете свои задачи, важно то, как вы будете это делать завтра. И да, не так важны инструменты в целом, важно их верное применение. Сегодня IDE, завтра блокнот. Или наоборот? Какая разница что вы используете, если сегодня вы работает лучше чем вчера, а завтра будете лучше, чем сегодня, то пишите хоть на листочках и перфокартах.
Как всегда проблема лишь одна — деньги. И ваша эволюция будет строиться лишь вокруг того, что бы вы зарабатывали больше. Это меня всегда печалит, что деньги такой двигатель. Если сегодня вы зарабатывает больше, чем вчера — значит вы на верном пути. Если меньше — свернули не туда. И да, если вы зарабатываете столько же, то может быть это не плохо. Может быть вы дошли до той точки, когда зарабатывать больше невозможно. Но, мне кажется, это не может не злить.
Gorthauer87
15.06.2015 15:57+3В итоге юниор может просто остаться в болоте, меня хватило всего на пару месяцев бултыхания в подобной трясине, в итоге быстренько убежал при первой же возможности.
Но, в сотый раз, наверное, повторюсь: наиболее ценный опыт в моем становлении как программиста сыграла разработка opensource'а. Там был и гит и багтрекер и инсталляторы и юнит тестирование — всё вообще.
Поэтому повторюсь, наверное, ещё раз: быстрее всего научиться прогать — это прибиться к более менее внятному opensource проекту.
tangro
15.06.2015 16:11Беда, если в ядре разработчиков людям не хочется писать современный и красивый код, а хочется получать свои три рубля в месяц за десяток пофикшенных багов и одну новую фичу. Тогда все предложения молодёжи о переходе на новую систему контроля версий, БД, язык, фреймворк натыкаются на непреодолимую стену. Из такой конторы можно только бежать, тут уже ничего не изменить.
ServPonomarev
15.06.2015 16:21+1Предложения молодёжи могут быть банально непродуманы. молодёжь, предлагающая новое-интересное, не задумается о стоимости миграции в человеко-часах и рублях. Да, потратить квартал и изучить новый модный фреймворк — это круто. Но есть ли у старших товарищей этот квартал времени? И кто будет оплачивать банкет?
tangro
15.06.2015 23:25Более того, они почти всегда будут непродуманны. И никогда за этими предложениями не будет экономического обоснования в часах и рублях. Но если их не рассматривать — придётся повторить путь Нокии, Блекберри, Palm, и прочих, создавших в своё время неплохие вещи, но не пожелавших принимать новое.
VenomBlood
16.06.2015 03:18+1Но есть ли у старших товарищей этот квартал времени?
Если речь идет о фреймворке который действительно помогает в работе, а не какой-то непонятной фенечке — то это проблемы «старших товарищей». Нету времени учиться? Придется уступить место тем, кто учиться хочет, а самому на пенсию. Выживает наиболее приспособленный, а консерваторы оправдывающиеся «а кто за банкет платить будет, а у меня времени нету и т.д.» — всегда оставались на отшибе отрасли.
Puteg
15.06.2015 16:32+1В «говно-компаниях» многое зависит от самого человека, если есть большое желание можно развиваться и там. Никто же вам не помешает использовать ваши знания. Знание без опыта, ничто…
Antelle
15.06.2015 16:33+2Хороший процесс разработки не только в гугле, яндексе, jetbrains,… Он в большинстве нормальных компаний среднего размера, а вот дремучий легаси-ынтырпрайз с исторически сложившимся «процессом» бывает у гигантов с закомплексованным карго-культом руководством. И процесс там хреновый не от того, что так лучше или так менее затратно, а потому что менять что-то лень, архитектору/менеджеру/лиду/руководству придётся предпринимать какие-то действия, а хочется в потолок плевать, не выходя из зоны комфорта. Разруха не в клозетах, легаси-проекты тоже можно поддерживать адекватно.
Джуниору достаточно устроиться в любую здравомыслящую компанию с правильным руководством, а от такого болота держаться подальше. Работа там ничего хорошего ни к опыту, ни к резюме, не добавит.
PerlPower
16.06.2015 04:54+1Да ладно вам, все(ну или почти все) проходят через это — вот опыт моих знакомых и меня habrahabr.ru/post/167997. Сплошные истории успеха. Перед тем вы достигнете такого уровня, что сможете выбирать работу по принципу нравится-не нравится всегда приходится терпеть подобные вещи.
vlreshet
16.06.2015 09:54+3По поводу компаний в которых «так принято» — вполне возможно что разработчики там совсем ни при чём. Например, когда нам передали проект — там был сплошной говнокод, SVN, и никаких тестов, фреймворков, докеров и т.д. И кодстайл разный даже не в разных файлах, а в двух соседних строках. Но зато этот монстр обрабатывал и проганял через себя сотни тысяч долларов в день. И как тут доказать клиенту мол «нам надо 3 недели фулл-тайма чтобы сделать всё по фен-шую»? Для клиента главное чтобы работало. А бесплатно никто перепиливать не будет. Вот и получается что 2015 год за окном, милионный проект, а у нас правки в базу вручую, и функции на 5000 строк.
maratvildan
мне кажется мало кто сейчас не использует IDE для больших проектов, это вроде уже в порядке вещей. поправьте если ошибаюсь
vedenin1980
Да, только иногда заставляют использовать явно урезанные и менее удобные IDE «потому что так тут принято», причем речь даже не идет о том чтобы за более удобную для разработчика IDE надо платить из бюджета компании, она не сможет обеспечить единообразия кода или в ней нет каких-то функций, просто «потому что традиция».
aml
Если разрабатывается клиентское или мобильное приложение, то наверное IDE уместна. Если серверное приложение, то с этим сложнее. Однако смысла статьи это не меняет — для серверного софта есть свои инструменты. Их нужно тоже знать и уметь ими пользоваться.
TheShock
Объясните. Это как?
aml
Я имел в виду, что синтаксис подсвечивать и рефакторинг делать можно и в vim. А реальные преимущества, которые специализированная IDE даёт (компиляция в реальном времени, отладчик), сложно использовать удалённо, когда у вас сервис, например, в контейнере выполняется, или на другой машине.
gturk
Вы что, дебажите код прямо на продакшене?
aml
Нет
dunmaksim
Звучит неубедительно.
vedenin1980
IDE, вроде IDEA, позволяют производить и удаленный deploy и удаленную отладку, кода выполняющегося и в контейнере и на другой машине, так что проблема все-таки не понятна.
aml
Смотря какой контейнер, и как он у вас деплоится. Если у вас сервис состоит из 5 компонентов, каждый из которых запущен в 5 экземплярах на машинах в облаке, вы вряд ли сможете поставить брекпоинт на событие «пользователь запросил урл /abc», а потом по F7 проследить запросы к бэкендам. Или как отладить проблемы, которые проявляются только под нагрузкой — гонки, переполнения очередей, throttling и т.д.? Я не работал с IDEA, может быть, она позволяет делать такие трюки, тогда был неправ.
vedenin1980
Она много что позволяет дебажить, в том числе и облака. А точка остановка по условию и ограничения остановки по тредам тоже позволяет многие трюки. Ну, и всегда есть возможность использовать логирования. IDE всегда пригодится, даже если и не дебажить на сервере, то хотя бы разрабатывать и компилировать.
maratvildan
Eclipse тоже позволяет удаленно дебажить
RPG18
IDE дает отладчик или нтерфейс к отладчику?
aml
Интерфейс, конечно, я имел в виду.
vedenin1980
А что вы понимаете под серверном приложением? Это то что называется enterprise? Так многие IDE как раз для enterprise в первую очередь и заточены, ибо самые щедрые клиенты.
nuald
Зависит от проектов, работал в двух больших компаниях, с обширной кодовой базой. В первом случае — в основном C, любая продвинутая IDE имела очень большие проблемы при построении индекса, по итогу использовал emacs + etags и sublime text + ctags. Можно конечно сказать, что это как бы IDE, но на самом деле это просто текстовые редакторы с расширенными возможностями.
Во втором случае, как ни странно, проблема была в RAM. Макбуки имеют очень ограниченную память, и у меня всего 16Gb на все про все. К сожалению, специфика работы заставляет все запускать локально (можно и на staging, но я предпочитаю все-таки локально). VmWare + J2EE app server + Android emulator +… тонна другого, к сожалению, нужного по работе => не хватает памяти на IDE. Все продвинутые IDE (даже просто Android Studio) потребляют около гигабайта, и когда в MacOSX заканчивается физическая память, она начинает себя вести не очень хорошо (может даже дело не в самой системе, а в VmWare, но это сути не меняет). Так что опять-таки, Sublime Text с нужными плагинами.