Планирование

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

Планируйте, прежде чем писать код

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

Вместо этого потратьте время на размышления о проблеме. Используйте абстракцию, начните с самого высокого уровня абстракции (самый низкий уровень детализации) и подумайте о проблеме, не глядя ни в какой код.

Подумайте о проблемной области или точке зрения пользователя, а затем постепенно увеличивайте уровень детализации. Начните думать о том, как интерфейс и сервер (где это применимо) взаимодействуют друг с другом. Затем спуститесь на уровень ниже и подумайте о пакетах или классах, отправляющих сообщения друг другу. Перемещайте свой ум вверх и вниз по разным уровням детализации, старайтесь упростить задачу, а не просто пытайтесь удерживать в голове действительно сложные структуры.

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

Планирование краткосрочных, среднесрочных и долгосрочных целей

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

Планирование дня

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

Программная методология

Обсудите методологию программного обеспечения со своей командой. Мы сделали это в нашей команде и в конечном итоге представили собственную облегченную методологию, на которую повлиял унифицированный процесс. У нас есть пять этапов разработки, которые мы используем для каждой задачи/функции, над которой мы работаем. Следование этим этапам заставляет нас не слишком рано переходить к коду и правильно планировать, поскольку первые два этапа не требуют никакого кодирования. Это значительно улучшило качество нашего кода и производительность.

Приоритеты

Еще один способ упростить планирование — составить списки приоритетов. Мы начали составлять список из пятнадцати приоритетов для каждого из наших проектов. При принятии решения о том, что имеет высокий или более низкий приоритет, хороший совет — оценивать вещи по воздействию/выгоде по сравнению с усилиями. Также полезно поставить приблизительную оценку времени для каждого из приоритетов, она не должна быть идеальной (эти оценки никогда не бывают идеальными), но это поможет спланировать ближайшие недели и месяцы.

Оценки времени

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

Если вы обнаружите, что всегда недооцениваете время, необходимое для выполнения задач, вы можете попробовать добавить дополнительные «дополнения» к своим оценкам, пока не достигнете точки, когда вы переоцениваете так же часто, как недооцениваете (иногда у вас даже может получиться!). Полезнее делать точные прогнозы, чем радовать людей оптимистичными оценками, которые оказываются ошибочными.

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

Примечание: четвертая часть уже доступна и ее можно найти здесь!.

-Майк Грегори