Сообщение Re: Прыжки по коду от 12.12.2016 18:00
Изменено 12.12.2016 18:09 Sinix
Здравствуйте, licedey, Вы писали:
L>Вобщем я пишу все в блокнот, все эти микрозадачи, и при каждом прыжке лезу в заметки, чтобы не забыть. У вас как?
Старый добрый принцип "слона едят по кусочкам". Разбиваем любую фичу на микрофичи (максимум на полдня работы каждая, обычно меньше) таким образом, чтобы в по завершению каждой у нас был рабочий код. Рабочий — это не в смысле полностью функциональный, это в смысле всё, что доступно пользователю, является рабочим или прикрыто заглушкой. На микрофичу заводится отдельный тикет (подтикет, если ваш issue tracker такое умеет), дальше всё как обычно.
Конкретный способ разбиения зависит от команды, опыта разработчика, архитектуры и тыды и тыпы и подбирается по ходу дела, с третьей-пятой попытки обычно выстраивается рабочая схема. Оформляем по ней чеклист — готово.
Если разбиение систематически не получается — ну, вот вы и узнали, что такое технический долг
И да, пара сотен файлов — ни о чём. Разумеется, если у вас вменяемая система именования и IDE, которая умеет в моментальный глобальный поиск по произвольной части имени.
L>А еще, часто на слуху в IT-блогах проскальзывает "состояние потока".
Состояние, когда удаётся удерживать в кратковременной памяти все детали по текущей задаче. Переоценено, т.к при должном уровне опыта переключение с контекста на контекст не представляет особой проблемы. Особенно если прокачать скилл "отвечать угу/ага/давай позже, не вслушиваясь в вопрос"
L>Вобщем я пишу все в блокнот, все эти микрозадачи, и при каждом прыжке лезу в заметки, чтобы не забыть. У вас как?
Старый добрый принцип "слона едят по кусочкам". Разбиваем любую фичу на микрофичи (максимум на полдня работы каждая, обычно меньше) таким образом, чтобы в по завершению каждой у нас был рабочий код. Рабочий — это не в смысле полностью функциональный, это в смысле всё, что доступно пользователю, является рабочим или прикрыто заглушкой. На микрофичу заводится отдельный тикет (подтикет, если ваш issue tracker такое умеет), дальше всё как обычно.
Конкретный способ разбиения зависит от команды, опыта разработчика, архитектуры и тыды и тыпы и подбирается по ходу дела, с третьей-пятой попытки обычно выстраивается рабочая схема. Оформляем по ней чеклист — готово.
Если разбиение систематически не получается — ну, вот вы и узнали, что такое технический долг
И да, пара сотен файлов — ни о чём. Разумеется, если у вас вменяемая система именования и IDE, которая умеет в моментальный глобальный поиск по произвольной части имени.
L>А еще, часто на слуху в IT-блогах проскальзывает "состояние потока".
Состояние, когда удаётся удерживать в кратковременной памяти все детали по текущей задаче. Переоценено, т.к при должном уровне опыта переключение с контекста на контекст не представляет особой проблемы. Особенно если прокачать скилл "отвечать угу/ага/давай позже, не вслушиваясь в вопрос"
Re: Прыжки по коду
Здравствуйте, licedey, Вы писали:
L>Вобщем я пишу все в блокнот, все эти микрозадачи, и при каждом прыжке лезу в заметки, чтобы не забыть. У вас как?
Старый добрый принцип "слона едят по кусочкам". Разбиваем любую фичу на микрофичи (максимум на полдня работы каждая, обычно меньше) таким образом, чтобы по завершению каждой у нас был рабочий код. Рабочий — это не в смысле полностью функциональный, это в смысле всё, что доступно пользователю, является рабочим или прикрыто заглушкой. На микрофичу заводится отдельный тикет (подтикет, если ваш issue tracker такое умеет), дальше всё как обычно.
Конкретный способ разбиения зависит от команды, опыта разработчика, архитектуры и тыды и тыпы и подбирается по ходу дела, с третьей-пятой попытки обычно выстраивается рабочая схема. Оформляем по ней чеклист — готово.
Если разбиение систематически не получается — ну, вот вы и узнали, что такое технический долг
И да, пара сотен файлов — ни о чём. Разумеется, если у вас вменяемая система именования и IDE, которая умеет в моментальный глобальный поиск по произвольной части имени.
L>А еще, часто на слуху в IT-блогах проскальзывает "состояние потока".
Состояние, когда удаётся удерживать в кратковременной памяти все детали по текущей задаче. Переоценено, т.к при должном уровне опыта переключение с контекста на контекст не представляет особой проблемы. Особенно если прокачать скилл "отвечать угу/ага/давай позже, не вслушиваясь в вопрос"
L>Вобщем я пишу все в блокнот, все эти микрозадачи, и при каждом прыжке лезу в заметки, чтобы не забыть. У вас как?
Старый добрый принцип "слона едят по кусочкам". Разбиваем любую фичу на микрофичи (максимум на полдня работы каждая, обычно меньше) таким образом, чтобы по завершению каждой у нас был рабочий код. Рабочий — это не в смысле полностью функциональный, это в смысле всё, что доступно пользователю, является рабочим или прикрыто заглушкой. На микрофичу заводится отдельный тикет (подтикет, если ваш issue tracker такое умеет), дальше всё как обычно.
Конкретный способ разбиения зависит от команды, опыта разработчика, архитектуры и тыды и тыпы и подбирается по ходу дела, с третьей-пятой попытки обычно выстраивается рабочая схема. Оформляем по ней чеклист — готово.
Если разбиение систематически не получается — ну, вот вы и узнали, что такое технический долг
И да, пара сотен файлов — ни о чём. Разумеется, если у вас вменяемая система именования и IDE, которая умеет в моментальный глобальный поиск по произвольной части имени.
L>А еще, часто на слуху в IT-блогах проскальзывает "состояние потока".
Состояние, когда удаётся удерживать в кратковременной памяти все детали по текущей задаче. Переоценено, т.к при должном уровне опыта переключение с контекста на контекст не представляет особой проблемы. Особенно если прокачать скилл "отвечать угу/ага/давай позже, не вслушиваясь в вопрос"