Суть в том, что даже хорошо отлаженный onboarding требует чьего-то внимания/ресурсов. Новичок не может сам по себе, «в вакууме», въезжать в проект. Ему всё равно потребуется помощь коллег. А уж когда дедлайн на носу, мобилизуются все доступные ресурсы команды.
VCS, bug tracking, wiki — это именно те инструменты, которые дал нам технический прогресс и они облегчают нашу жизнь. Назначение их при этом не меняется. В начале документацию распечатывали на бумаге и подшивали в архивы, затем Брукс предлагал как более современное решение использовать «микрофиши» (уменьшенные в 90 раз фотокопии документов на плёнке). Сейчас мы фиксируем документацию в wiki. Но назначение инструмента от этого не меняется — распространение знаний о системе.
Да, это практически неизбежно, потому что это жизненный цикл любого приложения. Относительно чистый код со временем переходит в legacy. Вопрос лишь в том, насколько быстро это происходит)
Я сознательно не стал включать выдержки из серии статей «серебряной пули нет», т.к. по сути это промежуточное подведение итогов каждого десятилетия, которое Брукс делает на основании своих же заметок. Мне хотелось прежде всего сравнить его мысли с текущим положением вещей.
Если бы программист 70-х узнал про возможности, предоставляемые сегодняшними технологиями, которые доступны любому разработчику (контроль версий, непрерывная интеграция, облачные решения и т.п.) и сравнил бы со своими, то он подумал бы, что перед ним «человек-оркестр». Поэтому да, сегодня такая специализация будет излишней.
По поводу второй части вашего комментария позволю себе не согласиться. Возрастание энтропии — это один из основных законов, которые встречаются в разных сферах, а не что-то специфичное для индустрии разработки ПО.
Не забывай, что в книге и в статье описан взгляд на процессы разработки, которые были в 70-е года. По нынешним меркам, Брукс работал в «кровавом энтерпрайзе». Отсюда все эти титулы, секретари и прочее. К тому же технологическая составляющая ушла далеко вперёд, во многом повлияв на процессы. Я лишь постарался провести аналогии между тем, что было «тогда» и тем, что имеем «сейчас».
«Чёрная магия» чаще встречается в legacy-проектах, в которых, возможно, уже успела полностью обновиться команда разработчиков и не осталось тех, которые разрабатывали систему с нуля. Ну а в новых проектах гораздо больше возможности писать «чистый» код.
Я думаю, что далеко не все стартапы имеют и материальные, и людские ресурсы на «прокачку» джунов. Для многих стартапов прежде всего важнее выйти на самоокупаемость. Там зачастую царит атмосфера «это надо было сделать ещё вчера». Поэтому развитие джунов грамотно можно реализовать только в крупных компаниях.
Groovy допускает, например, динамическую типизацию, что делает его ближе к скриптовым языкам. А в больших проектах это может усложнять рефакторинг. С этой точки зрения можно сказать, что kotlin обладает преимуществами groovy (работа на JVM, совместимость с Java), но при этом лишён некоторых его минусов.
А где, на твой взгляд, новичку проще начать карьеру: в маленьком стартапе, где от каждого разработчика требуется решать сразу много разноплановых задач, или в большой компании, где все процессы уже более-менее стандартизованы и поставлены на поток?
Всё верно. Мне в статье хотелось прежде всего наглядно показать разницу в API двух языков. При этом если мы добавим к каждому примеру на kotlin использование asSequence(), то тем самым ещё и повысим производительность и уменьшим расход памяти.
Да, вы правы. Однако record в Java 15 имеет статус preview и её нужно явно активировать. Мне же хотелось рассказать про ту функциональность обоих языков, которая доступна «из коробки».
VCS, bug tracking, wiki — это именно те инструменты, которые дал нам технический прогресс и они облегчают нашу жизнь. Назначение их при этом не меняется. В начале документацию распечатывали на бумаге и подшивали в архивы, затем Брукс предлагал как более современное решение использовать «микрофиши» (уменьшенные в 90 раз фотокопии документов на плёнке). Сейчас мы фиксируем документацию в wiki. Но назначение инструмента от этого не меняется — распространение знаний о системе.
По поводу второй части вашего комментария позволю себе не согласиться. Возрастание энтропии — это один из основных законов, которые встречаются в разных сферах, а не что-то специфичное для индустрии разработки ПО.