Фича против функционала. Кто кого?
Предпочтения у каждого свои.
В текущем проекте появилась возможность поработать с очередями. Задача честно ждала своей очереди несколько недель — и когда дошло дело до неё, дала важный вывод. Не про код, а про то, как мне понравилось работать.
Задача была простая — расширение одного из сервисов. Рядом лежала другая, побольше — её отменили. Тикета не стало, а требований вместе с ним. Но функционал вписывался в проект и давал экономию ресурсов. Озвучил куратору общее видение решения — какой функционал добавлю и зачем — и получил одобрение.
Рамки остались только там, где касалось остальной системы — общий контракт, направление. Как это будет устроено внутри, какие компромиссы принять и какие ошибки допустить — уже было пространством для решений.
Один из компромиссов увидел уже на самопроверке кода — часть решения оставляла технический долг. По-хорошему, стоило переделать сразу. Но на ревью решили иначе: функционал вводим сейчас, долг чиним отдельной задачей позже.
После нескольких месяцев на задачах, плотно завязанных на чужой код, было в кайф подумать не о том, как реализовать то, что попросили, а о том, что вообще нужно реализовать.
Мне нравится работать в команде — созвоны, обсуждение решений, участие в выборе подхода. Это даёт рост и ощущение причастности. Но когда появляется пространство думать масштабнее — это другое: в мелкой задаче ищешь, что упустил, а не как это вообще лучше реализовать.
Были ошибки? Да. Проблема ли это? Нет.
Свои ошибки запоминаются лучше чужих. Наверное поэтому к ним и отношение спокойное — это не провал, а опыт, который двигает по грейду.
· 20.08
Этот волшебный момент ревью, когда "починим потом". ((:
Хорошо, когда есть правильная архитектура и можно действительно починить, а не делать заново. ((:
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 20.08
Не такая критичная проблема, вопрос времени)) когда закончатся причины для рефакторинга задач, которые не соответствуют контактам, тогда и эта исправится. Вопрос вечера, если не спешить.
Были и другие ситуации в прошлом проекте. Где отдельные части действительно было проще с нуля сделать...
Все же, суть поста в работе, где ты можешь придумать реализацию сам. В таком случае, даже архитектуру отдельного функционала поправить проще.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 20.08
Обычно, в работе, реализацию и придумывают сами иначе за что платить? ((:
Элементы творчества, так сказать, полезны для человека.
С легаси работаю регулярно и достаются под час страшные проекты и везде, как раз, начиналось с этой фразы "починим потом". ((:
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 20.08
У каждого разный опыт. У нас куратор делает, если корректно так назвать роль. Быстро накидал архитектуру и что он предполагает увидеть, внутри задачи отличаются. От "сделай а, б и в", до отдельного функционала. Плюсы есть во всем. Все же хочется работать со всем, от какой-то скрупулезной работы над мелкой задачей (когда функционал работают, но нужно права какие-то, настройки сделать) до проектирования функционала. Не считаю, что готов сразу правильно продумать весь сервис. Хотя.. зависит от бизнеса. Если заказчик знает чего хочет, есть над чем подумать
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 20.08
С учётом развития ИИ больше времени нужно уделять архитектуре теперь им тестам. ((:
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён