Николай Долганов
Так, собственно, вы последним блоком комментария и описали мою идею: есть стандарты, есть KPI, и тот же принцип KISS вполне себе сочетается с принципами SOLID. Есть разница между "зафигачить необслуживаемый продукт" и "зафигачить MVP". Если ты знаешь, как будет дальше идти оптимизация и расширение, как потенциально протестировать свой код, то оптимизация качества идёт несколько другим путём. Просто есть много проектов, где качество кода вообще выходит за рамки любых стандартов, и это порождает проблему анализа кода на этапе обслуживания и расширения. Например, я сталкивался с проектами, где считается нормой дублировать код сейчас, а оптимизировать его - потом. И это, как ни странно, не связано с лидом - он пришёл в проект позже. Но это вызывает проблемы обслуживания кода. Я видел и обратную крайность: когда человек много лет пилил проект, следуя логике тотальной оптимизации качества, а потом настолько увлёкся рефакторингом, что провести через него доработку в продакшен стало почти невозможно. В первом случае, лид работает по-старинке, пока нет глобальных переделок. Во втором случае, лид столкнулся с глобальными переделками и психанул, осознал, что если бы он применял заранее некоторые паттерны разработки, то в последние два года у него не было бы конфликта с бизнесом. В обоих случаях джуны не растут. В первом случае потому, что в работу не берутся паттерны проектирования и разработки. Во втором случае - из-за того, что только лид знает, как работает его код. В первом случае, джун сразу приносит прибыль, но эта прибыль в будущем рассеется на обслуживании кода. И первый случай неизбежно порождает второй. Когда джуны не смогут решать проблемы обслуживания и фиксить критические баги, никто их не будет держать на месте. Отсюда следует, что принципиальное значение имеет знание общих принципов и паттернов проектирования. Например, декомпозировать код, покрывать его простыми тестами, которые будут дописаны в будущем, внимательнее относиться к реализации задач и применять шаблоны проектирования вместо лобовой атаки. Это не сильно замедлит процесс, но даст более качественный код. Кроме того, это позволит джунам сразу приносить прибыль. Джуну требуется формализация реализации вплоть до псевдокода. Ему надо сразу обозначить, какие паттерны он должен применить. Проблема джуна не приносящего прибыль - это проблема лида, который занимается фигнёй вместо формализации D-требований (см. Эрика Дж. Брауде). На мой взгляд, лид не должен сам писать код. Для хорошего кода есть сеньоры. Как и для обучения джунов. Лид должен строить архитектуру и формализовать требования к коду, писать документацию. Тогда вся команда будет приносить прибыль.
Главное, чтобы юристов не нагрузил.
А правда, что людей с дипломом стабильно зомбируют постоянно всем рассказывать о том, что у них шире кругозор и системнее мышление?
К пенсии сертификаты и дипломы дадут возможность работать, не работая. Каким-нибудь мелким чиновником, например.
Я, в последнее время, чаще встречаю лидов, которые не хотят сливать в продакшен даже не джуниор код (чистый, покрытый тестами). Просто потому, что он не соответствует их представлениям о мире. Я видел компанию, где люди не перерастают джунов просто потому, что так выгодно. Поэтому, склонен не согласиться. Джун должен приносить прибыль, максимум, через 3 месяца с момента приёма на работу. Если ты берёшь 2 - 3 джунов, а прибыли с них нет ни через месяц, ни через 2, ни через 3, то это говорит о проблемах твоего лида. Есть общие правила написания кода для рынка. Например, те же solid + clean code. Высокий Test coverage позволяет в процессе ревью менять условия исполнения кода, входные данные и проверять работоспособность кода. Если твой лид гонит про то, что тесты ему не нужны, и при этом сразу не сливает код джунов, если он объективно соответствует общерыночным стандартам, то проблема, скорее-всего, не в джунах, а в высокооплачиваемом лиде. Может, он потому и высокооплачиваемый, что является носителем некоего индивидуального стандарта разработки, нигде более на рынке не встречающегося? И его замена вызовет проблемы с тем, что джуны не обучены, а новый лид будет долго разбираться с тем, что происходит в коде?
Заголовок: Кликбейтные заголовки предпочитают писать геи и моральные уроды.
Текст: на самом деле, нет!
Тело человека приспосабливается к условиям окружающей среды. Качалка - это, прежде-всего, потребность в питании. Ты питаешься больше, чаще, потом идёшь к железу, и программируешь своё тело на раскачку мышц, поскольку даёшь ему усиленную нагрузку, и механизмы твоего организма работают на прирост мышечной массы. Потом, ты бросаешь качалку: организм требует того же объёма продуктов, но нагрузки уже нет. Мышечная масса сокращается, чтобы отложить жир, поскольку тебе больше не нужна. Плюс, потребление пищи если и сокращается, то не на много.
То, что обещает битрикс, надо делить на ноль.
Так 1С же вам обещали, что там всё из коробки работает, настраивается любой обезьяной с мышкой, прошедшей курс разработчика Битрикс, который вы можете и сами купить.
Зачем же они всем всегда об этом рассказывают?