Сегодня мы поговорим о таком важном явлении в программировании (и в математике), как рекурсия. Наверняка, вы уже писали программы с ее применением, хотя бы на уровне университетских лабораторных работ. И если поначалу рекурсия кажется чем-то сложным, ужасным и непостижимым, то уже после первого на нее взгляда все становится просто и понятно. Итак, приступим к делу.

Готов поспорить, что в 2021 году каждый уважающий себя разработчик не только слышал про такой процесс, как code review, но и на ежедневной основе его практикует. Сейчас нет никакого смысла обсуждать плюсы и минусы код ревью, потому что для всех итак уже очевидно: практика эта весьма и весьма полезная. Если вы считаете, что code review не нужен и только мешает, то взгляните на свой календарь и убедитесь, что на дворе не 1995 год, либо просто валите из профессии, черт возьми! 🤬 Ну а в этом посте я хочу поговорить о том, как правильно подходить к процессу ревью и как заставить ваших коллег трепетать каждый раз, когда они добавляют вас в…

Настало время обсудить последний крайний из принципов SOLID – Dependency Inversion Principle, он же DIP, он же принцип инверсии зависимостей. В качестве примера рассмотрим постройку дома и увидим, как все пройдет в зависимости от того, используем ли мы принцип или игнорируем его. Спойлер: лучше использовать!

I в аббревиатуре SOLID расшифровывается как Interface Segregation Principle, он же Принцип Разделения Интерфейсов. На мой взгляд, это самый простой из принципов SOLID, и сегодня мы о нем поговорим. Как обычно, разберем ISP на примере и посмотрим, что случится, если этим принципом пренебречь.

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

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

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

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

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

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