Олег Стрекаловский

— Эх, может стоит всё бросить и снова заняться лапшой…

— Бросить – не бросить, лапша – не лапша. Тебя слишком занимает, что было, и то, что будет. Мудрецы говорят: «Прошедшее – забыто, грядущее – закрыто, настоящее – даровано». Поэтому его и зовут настоящим.

Кунг-Фу Панда.

Ещё будучи студентом-ACM-щиком, я понял, что теория без хорошей практики как минимум бесполезна. А как максимум – буквально «выжигает» тебя изнутри, потому что ты не можешь отбить затраченные усилия и получить заслуженный дофаминчик. Хорошая практика – это не бросание человека в воду в надежде, что он сам выплывет. Это про понимание типичных «граблей» на которых можно крепко застрять, и помощь в нужный момент на протяжении всего пути. Именно поэтому хороший специалист != хороший учитель.

В завершающем эпизоде курса поговорим о том, как перейти от теории к практике.

Дальше »

Книг и докладов по архитектурным паттернам очень много. Многие из них хорошо известны даже новичкам: о них не рассказывал только ленивый. В этом эпизоде я не буду разгонять очередной хайп на тему «прав ли дядька Боб/Фаулер/etc. или нет». Вместо этого расскажу, как я ищу внутренний покой в этом бушующем «океане страстей»: как не стать заложником одного продвигаемого решения всех проблем, и при этом постоянно не скатываться в аналитический паралич.

Дальше »

«Задумывались ли вы, зачем у машины тормоза? Инженеры изобрели машину, чтобы быстрее перемещать людей. Но зачем они добавили в неё подсистему, которая замедляет перемещение и противоречит цели изобретения? В теории машина может ехать настолько быстро, насколько это позволяет двигатель, особенно на прямой дороге. Но именно благодаря тормозам машина будет ехать быстро: без них вы бы и не рискнули разгоняться на реальных дорогах. Тесты нужны для этого же: чтобы «разогнавшись» вы могли безопасно изменить «траекторию» своего продукта». – Kevlin Henney.

В этом эпизоде мы поговорим о горячей теме unit-тестирования. Из материалов вы узнаете:

• откуда такой разброд и шатание в понимании людей что такое unit-тест,
• что мы хотим от тестов, а что получаем в итоге,
• как писать тесты так, чтобы со временем не захотелось их удалить.

Дальше »

На первый взгляд может показаться, что рефакторинг – дело не хитрое: меняй названия функций и объектов/структур/полей, разделяй/объединяй код. Но главный риск наивного подхода в том, чтобы в процессе пересборки движка он может перестать крутить колёса. Корректность небольших косметических изменений можно доказать внимательным чтением кода. Но что, если изменения в коде начинают распространяться далеко за границами того, что первоначально планировали изменить, и нарастают как снежный ком? О том, как научиться делать рефакторинг «at scale» и пойдёт сегодня речь.

Дальше »

Это первая статья из цикла, который я посвящу рефакторингу программного кода. Больше года я изучал материалы по этому навыку и, наконец, решил поделиться своими находками с вами. Тема оказалась настолько глубока и широка, что я даже не буду пытаться пересказывать всю мудрость, которой напитался за это время, но попытаюсь структурировать подход к её изучению. На каждом этапе я буду делать обзор материалов (книг и докладов), которые помогут вам разобраться с каждым кусочком этого паззла. Тут не будет абстрактных банальностей «хорошо делай – хорошо будет». Только мясо от экспертов из отрасли, чьи работы меня впечатлили.

Абстракции сложны для человека, т.к. мы привыкли оперировать тем, что ощущаем. Когда же речь заходит о их перестройке в сложной системе, мозг того и гляди наровит вообще выйти из чата. Поэтому, чтобы начать сталкиваться с подобным не только в рабочие часы, но и в свободное время, неплохо бы сперва убедиться, что у вас есть достаточный запал, который будет поддерживать всю дорогу. Как я нашёл его в себе, почему именно сейчас – об этом в первом эпизоде.

Дальше »