Настало время поговорить о том, что значит L в аббревиатуре SOLID. В качестве сегодняшнего примера возьмем простейшую ситуацию. Представьте, что вы идете на совещание (или на лекцию, семинар), и вам нужна с собой тетрадь, чтобы делать заметки. Вы берете тетрадь в клетку и внезапно начинаете ловить на себе негодующие взгляды. Как оказалось, на этом конкретном совещании (лекции, семинаре) принято писать в тетрадях в линейку. Окей, через пару часов вы идете на другое совещание и берете с собой тетрадь в линейку, но, по закону подлости, здесь уже приняты блокноты формата А4 без разметки. Вы снова чувствуете себя глупо. Казалось бы, какая разница, какая у вас тетрадь – в клетку, в линейку…

Это второй пост из цикла статей про SOLID, и сегодня мы разберем, что означает буква O в этой аббревиатуре. Как обычно, мы рассмотрим принцип на примере и поговорим о том, как он нам помогает, что было бы без него и зачем он вообще нужен.

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

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

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

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

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

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

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

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