Давайте поговорим о том, что такое SOLID? Наверняка вы читали книгу «Чистый Код» Роберта Мартина (как это не читали???) и вам уже давно известно, что это такое. Да и в интернете есть множество статей на эту тему. Однако же, мне, как и большинству других разработчиков, постоянно приходится работать с грязным кодом, который можно улучшить. Возникает парадокс – если все знают правила написания хорошего кода, откуда берется код плохой? В следующем блоке постов я хочу кратко рассказать, как я понимаю каждый из принципов SOLID, и, что самое главное – как мне это помогает писать более понятный и чистый код. Никаких научно-занудных объяснений. Все максимально просто, кратко и на примерах. Сегодня поговорим…

Мы уже успели поговорить про такие важные вещи, как тестирование кода, обучение молодых специалистов и разницу между опытом и стажем. Давайте теперь немного расслабимся и поговорим о вещах более приземленных. Сегодня предлагаю обсудить следующий вопрос: каким должен быть надежный пароль и зачем его менять. Разумеется, периодическая смена паролей должна подразумеваться политикой безопасности компании, поэтому поговорим также и о том, какая частота смены пароля будет оптимальной.

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

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

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

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

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

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

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

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