anetto1502

Я пробовал организовывать рабочие чатики самыми разными способами: иногда просто в отдельную папочку, иногда – в папки по проектам.

Но у такой логичной организации есть проблемы:

– Ты не можешь сходу понять, какие чатики требуют внимания

– Имея большое количество чатов в папке, иногда невольно открываешь посмотреть то, что тебе сейчас вовсе не нужно

И некоторое время назад я придумал (вряд ли я, но в моем мире – именно я), как иначе организовать рабочие чатики – по срочности.

Сделал 4 папки:

🔹Now – то, на что мне нужно реагировать незамедлительно. Таких чатов всего 1–2, но стремиться нужно к нулю

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

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

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

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

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

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

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

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

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

Формат:

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

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

Структура: