В прошлом посте я говорил, что вам не нужны юнит-тесты. Но то были #вредныесоветы, а сейчас настало время разоблачений. Сегодня мы поговорим о всей важности тестирования и о том, чем грозит его отсутствие (либо неправильное применение). Я постараюсь максимально подробно описать плюсы тестирования и разобрать вредные советы из прошлого поста.

Да, вы не ослышались – именно так! В IT-сообществе прочно укоренилось мнение, что все эти тесты вам хоть как-то помогают, но так ли это на самом деле? Вы сами пробовали мыслить критически и анализировать это расхожее мнение? Хипстеры придумывают кучу парадигм – TDD, BDD, ПДД, ГИБДД – лишь чтобы создать иллюзию бурной деятельности и хоть как-то оправдать свою зарплату. Но задумайтесь, что будет, если вы (либо ваши программисты) начнете все свое время уделять исключительно написанию кода? Для тестирования есть отдельное направление и целые подразделения. Вы же не заставляете программистов писать требования, так? Тогда почему они должны писать тесты? Всех согласных и несогласных прошу проследовать внутрь поста, где я вам наглядно…

Agile, scrum, agile-coach, scrum-master… Что только люди не придумают, чтобы казаться продуктивнее, верно? Когда вы читаете описание вакансии, то там почти наверняка будет упоминание, что «наша команда работает исключительно по методологии agile», как будто это то единственное, на чем стоит сделать отдельный акцент. Сам по себе аджайл – это не хорошо и не плохо, это просто очередная модель, которую многие находят эффективной. Но при этом многие попадают в ловушку и больший упор делают на следование определенным процессам, а не достижение результата. Скрам ради скрама, аджайл ради аджайла. Есть даже отдельный вид нечисти – это скрам коучи. Эти злобные, маленькие и противные существа преследуют только одну цель – сидеть на вашей…

Как более опытный коллега, вы ответственны за развитие молодых специалистов, которые с вами работают. Этот тезис мы сегодня и разберем. Демотивировать и замедлить развитие джуниора очень просто, а дать ему хороший старт – сложно. И многие «зрелые» специалисты почему-то не особо желают помогать более молодым и не испытывают к ним уважения. В прошлом посте я давал #вредныесоветы про то, как нужно относиться к менее опытным коллегам, а сегодня хочу на эту тему поговорить серьезно.

Представьте, что вот уже долгие месяцы вы – единственный разработчик на проекте. И вроде бы все замечательно: вы вовремя завершаете задачи, пишете качественный код и получаете удовольствие от работы. Но однажды все меняется. Заказчик решает увеличить нагрузку на проект, добавить больше функциональности, и, как результат, отправляет вам на подмогу двух молодых специалистов. Вы больше не один. Теперь интересные задачи придется делить с двумя неопытными троглодитами.

В прошлый раз я писал про разницу между опытом и стажем, и почему первый гораздо важнее второго. Сегодня хочу поговорить о людях, которые не ценят свое время и работают исключительно или в большей степени на стаж, не особо вдумываясь в суть задачи и не стремясь изучить что-либо новое для себя. Для таких специалистов вполне приемлемо довести задачу до стадии «вроде работает» и на этом остановиться, не задумываясь о возможных последствиях такого решения. Здесь я расскажу об этих самых последствиях, а также о том, чем такой подход опасен для будущего проекта и для будущего специалиста.

Вася работает программистом 5 лет, а Петя – 7. Вроде как Петя работает аж на два года дольше, и по идее он должен быть Васиным начальником и отдавать распоряжения. Но нет. Пост начальника занимает именно Вася. Несправедливость, скажете вы? А что, если наш Вася за пять лет развился так, как Пете не развиться и за десять? Что такое опыт, а что такое стаж? Почему опыт – это то, к чему вы должны стремиться, а стаж – это лишь цифры в вашем резюме?

Наша жизнь кардинально изменилась, когда нас повсюду начали окружать высокие технологии. Ты – поэт и хочешь поделиться своим творчеством с широкой публикой? Тебе в сеть, товарищ. Может быть, ты – бизнес-тренер и тоже желаешь распространить свою чудодейственную методику, как заработать легкие деньги? Тебе снова в сеть. А что, если тебе 12 лет, твоих карманных расходов не хватает на новый гаджет, и ты грезишь о легкой наживе? В сеть! Любой человек может реализовать себя в сети, и это здорово. Но разве когда-нибудь было что-то хорошее, на чем не хотел бы поспекулировать хотя бы один лентяй в поисках легкой выгоды? Представляю вам небольшую подборку лодырей в этом посте.

Недавно я давал вредные советы на тему того, как быстро заработать повышение: «всегда добавляйте фичи в последний момент», «забейте на структуру и тестирование» и так далее. Настало время всерьез поговорить об этом и разобрать, почему вам на самом деле стоит крепко задуматься, прежде чем согласиться что-то добавить накануне релиза и сказать твердое «нет» своему начальнику.

Недавно наткнулся на пост про отношение программистов к такой базовой штуке, как инкапсуляция. Собственно, все ее уважают и стараются соблюдать, но складывается впечатление, что не все до конца понимают, зачем оно все-таки нужно на самом деле. В этом посте попробую привести простую аналогию, чтобы у вас сразу отпало желание эту самую инкапсуляцию нарушать.