anetto1502

Часто говорят, что goto плох. А собственно, почему?

В ассемблерном коде на машинном уровне все управляющие конструкции (if, while, for и другие) преобразуются в набор команд с безусловным переходом jmp (UPD: как правильно заметили, с безусловным или условным переходом, но по указанному адресу, то есть куда угодно). А такой переход — самый настоящий goto. То есть ты весь такой изящный во фраке пишешь циклы, а наглый компилятор/интерпретатор выкидывает всю красоту и делает goto.

Так почему же сам goto является признаком плохого кода, если он на самом деле везде?

Ответ кроется в умении сохранять контекст. Человек может в голове держать 5-9 сущностей, больше не получается. Поэтому придумали функции, и придумали держать их небольшими — для снижения когнитивной сложности. Конструкция if переведёт тебя в одну из веток ниже, циклы for и while выполнят тело цикла или выбросят за его пределы. Команда goto сложность привносит — прыжок может быть куда угодно. А повышение сложности всегда приводит к росту числа ошибок.

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

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

Код легко читается. Правильная архитектура, понятное именование переменных, достаточные комментарии, короткие функции. Это целый набор плохо формализованных требований к коду. Сможете ли вы спустя год понять, что происходит в коде? Сможет ли код разобрать ваш коллега? Сколько времени займут изменения вашего кода?

Быстрый по скорости и компактный по данным. Другими словами, код должен быть нормальной вычислительной и пространственной сложности. Тут помогают и интуитивные представления (что-то тормозит), и теория вычислительной сложности (О-нотация). Если вы сортируете записи за O(n^3) и требуете O(n^5) оперативной памяти, то вы делаете что-то не так.

Когда у вас больше пяти тимлидов в подчинении, а задачи множатся в геометрической прогрессии, стихийные синки превращаются в рулетку: то что-то забудете, то сорвёте дедлайн, то внезапный вопрос срочно «нужно обсудить». За год+ управления командами я перепробовал кучу подходов — и в итоге отточил формат, который убирает хаос, экономит нервы и не даёт терять важное. Рассказываю, как это работает.

Формат:

Обычно, такие встречи проходят раз в неделю. Цель – синхронизация по текущим задачам, проблемам и приоритетам.

Каждый синк – отдельная повторяющаяся приватная таска в таск трекере (как я веду задачи писал тут), либо приватная страничка в вики (в нашем случае конфлюенсе), где фиксируется повестка. Важно, что повестку наполняют оба: руководитель и подчиненный.

Структура:

Это пост для исключительно для маководов.

Уже очень давно пользуюсь такой замечательной программой — Raycast. Это супер-разухабистая штука, которая может упростить повседневную рабочую рутину, да и не только рабочую.

Начну с банального: слёзы текут, когда вижу как кто-то неуклюже ищет нужное ему окно. Ой, это браузер, ой, это почта, блин, это IDE, фух, вот же он — телеграмчик!

Первое, что у меня настроено в Raycast — это хоткеи абсолютно на все программы, которыми я постоянно пользуюсь: Option + M — почта, Option + T — телеграм, option + B — браузер, и т.д.

Штука рекомендуема к использованию абсолютно всем. Периодически буду делать посты, рассказывая, что ещё интересного с помощью неё делаю.