Как обрабатывать короткие сессии кодирования?

Question

Я работаю над некоторыми любимыми проектами, и обычно я сижу около своего ПК около 22:30 или 23:00, чтобы кодировать. Но так как я стараюсь спать около 24:00, я не начинаю кодировать и заканчивать читать статьи, играть в некоторые игры и т. Д.

Я не чувствую, что могу написать приличный код за час, потому что проект довольно большой, и я не хочу случайно или небрежно взломать его. Несмотря на то, что я использую TDD, большую часть времени я делаю не так просто, что требует много испытаний, прежде чем все получится.

Какой у вас подход к такого рода проблемам? Вы просто пишете код позже, когда у вас есть достаточно времени, или у вас другой подход, который позволяет вам кодировать всего 30 минут и продолжить позже?

Answer 1

Я обычно не пишу много кода, пока у меня нет времени, чтобы сделать это. Причина в том, что для того, чтобы я стал эффективным, нужно сосредоточиться, а для того, чтобы правильно сфокусироваться, требуется немного времени. Тем не менее, эти 30-минутные слоты отлично подходят для

• Написание большего количества тестов: ничего подобного попыткам достичь 100% покрытия кода, и это не большая трата, так как вы вкладываете
• Исследования: я провожу много времени за чтением блогов, поиском фреймворков или инструментов, которые я могу использовать. Тратить 30 минут на поиски фреймворка, который делает 80% необходимой вам функции, гораздо лучше, чем тратить часы на ее кодирование. Другим фактором является то, что если вы внедряете фреймворк и обнаруживаете, что он плохо подходит, вы лучше осведомлены о потребностях, а значит, ваше развитие будет более плавным.

Answer 2

Небольшой совет (которым я тоже пользуюсь на работе) - прекратить кодирование в середине чего-либо с ожидающей очевидной большой красной ошибкой компиляции.

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

Пока вы работаете над небольшой проблемой, общая картина проясняется, и затем вы можете продолжить проектирование.

Answer 3

Вот несколько вещей, которые вы можете попробовать:

• Не сидите рядом с компьютером. Вместо этого возьмите большой лист бумаги и идите куда-нибудь тихо. Подумайте, чего вы хотите достичь. Запишите идеи интерфейса, подробную реализацию. Составьте список вопросов, которые необходимо решить, прежде чем продолжить.
• Сними неделю и закодируй. Соотношение попадания в поток и времени потока слишком плохое для 30 минут.
• Ведите журнал о том, что вы делаете, вместо того, чтобы кодировать. Наблюдайте за своим эмоциональным состоянием.
• Ложитесь спать пораньше и постарайтесь, чтобы ваш питомец занимался кодированием рано утром.

Answer 4

Что ж, моей первой мыслью было «использовать модульное тестирование», но потом я прочитал, что вы уже используете это. Но я все еще думаю, что это решение вашей программы.

Постарайтесь сделать ваши тесты как можно меньше и используйте правило «1 утверждение на единицу теста» для создания небольших атомных тестов. Вы сможете исправить некоторые из этих небольших тестов за 30-минутный сеанс.

Answer 5

Всегда есть еще одна ошибка. Если нет, есть еще одна полезная функция, которую вы можете добавить, и это добавит больше ошибок. Это одна из причин, почему я считаю, что использование фразы «Все, что вы должны сделать ...» кем-либо в (или с использованием) ИТ должно быть повинным преступлением.

Я могу сократить продолжительность моих сеансов кодирования, выполняя тривиальные вещи, продумывая вещи, находясь вдали от клавиатуры (лучше всего принимать душ - или в постели в 4 часа утра) и используя легкие среды, такие как языки сценариев , но «быстрые» сеансы кодирования - это то, на что я давно потерял надежду.

Простое переключение ментальных механизмов в режим кодирования занимает время, нахождение нитей того места, где я был раньше, занимает время, обнаруживая, что мое «быстрое и простое решение» не было ни одним из вышеперечисленных, требует времени. Исправление мое "быстрое и простое решение требует времени, отладка - больше времени и т. Д.

Answer 6

Вот что я делаю со своими личными проектами вне работы:

• 1) Я стараюсь составить хорошую карту своего проекта, планируя ее на бумаге. Я строю схемы всех своих объектов, структур данных и / или таблиц SQL и определяю, какие основные функции и взаимодействия между этими компонентами необходимы. Я могу написать какой-то реальный код на этом этапе, если решение очевидно, но обычно нет.
• 2) Как только общая картина будет создана, я расставлю приоритеты для самых основных и критических элементов. Я также пытаюсь выяснить, какие части будет легче писать, чем другие.
• 3) После того, как приоритеты установлены, я начинаю сначала работать с самыми простыми и наиболее важными частями и постепенно переходить к более сложным и менее важным компонентам. Разбиение каждой задачи на более мелкие части, как правило, помогает. Например, я могу сначала спроектировать таблицу базы данных, а на следующий день создать класс интерфейса данных, который контролирует взаимодействия с этой таблицей.
• 4) Модульное тестирование действительно помогает мне почувствовать себя выполненным, даже если 30 минут усилий приведут к появлению всего лишь нескольких строк кода качества.
• 5) Вести журнал изменений, даже если он не очень подробный. Я обнаружил, что мои журналы изменений неоценимы, если я работаю над большим проектом в течение коротких периодов времени.

Эти шаги тут же помогают мне больше всего. В конце я могу определить небольшие фрагменты проекта, которые обычно могут быть выполнены за 30-60 минут. Конечно, по мере развития проекта мне обычно приходится что-то переоценивать и на какое-то время возвращаться к началу, когда я обнаруживаю, что что-то упустил из фаз планирования. Иногда мне нужно пойти немного дальше, назначить временные рамки с некоторыми сроками и убедиться, что я отмечаю вехи с личным вознаграждением. Если у вас есть склонность не спать до утренних часов, что-то, с чем я борюсь, я также предлагаю также ввести для себя кодовый комендантский час. Я также стараюсь убедиться, что мой «компьютер кодирования» не слишком отвлекает, например, игры.

Answer 7

Никогда не работал для меня, проекты домашних животных обычно слишком интересны, и я заканчиваю работать до поздней ночи или в выходные дни.

Я бы посоветовал пересмотреть ваши приоритеты - если все, что у вас есть, на час позже поздно, возможно, лучше потратить его на игры, статьи и т. Д. Или просто тусоваться. Когда у вас будет немного больше времени, скажем, в ленивое воскресенье, потратьте все время сразу и на самом деле почувствуйте, как выполнить то, что должны дать домашние проекты.

Answer 8

Трудно развиваться в такие короткие времена, но вы все равно можете получить что-то из этого времени. Модульное тестирование одно. Запись интерфейса класса - это другое. Хотя для написания реальных вещей потребуется гораздо больше времени, эти задачи, по сути, не представляют никакой сложности, и они являются всего лишь упражнением в наборе текста.

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