По кирпичикам: планирование перед программированием и Agile-разработка

В 2016 году я посетил двухнедельную программу творчества и робототехники под названием Ashesi Innovation Experience. Это было здорово; хотя я не освоил никаких новых навыков программирования, я многое узнал о творчестве и многом другом. Однако я усвоил одну очень важную концепцию программирования, о которой раньше особо не задумывался.

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

Сейчас я не говорю о том, чтобы быть каким-то современным программистом Бобби Фишером и запоминать все планы вашего программного обеспечения в своей голове. Нет, я говорю о планировании на бумаге.

Если вы чувствуете себя немного ошеломленным этой, казалось бы, нелепой идеей, вы не одиноки. У меня было такое же чувство, когда этим новым программистам посоветовали достать несколько листов формата А4 и начать набрасывать, что должны делать их роботы на английском языке, прежде чем они будут вводить команды в своих IDE.

Я решил «пошутить» и попробовал.

Боже, я был удивлен тем, как это упростило задачу. Мне больше не нужно было сосредотачиваться на том, почему я заставляю его делать что-то конкретное (или как все его действия в конечном итоге приведут к цели), но как я собираюсь поместить эти инструкции в красивую форму. базового Робота С, которым мы пользовались в то время.

Немного предусмотрительности не помешает

Спустя более года я все еще храню этот совет в сердце, хотя и применяю его в меньшей степени, чем в AIX.

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

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

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

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

Уверяю вас, в таких ситуациях несколько возвратов не помогут.

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

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

Итак, я думаю, вы поняли: планирование наперед важно. Но есть хороший вопрос: Как мы будем планировать?

Водопад против гибкого программирования

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

Первый называется каскадным программированием.

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

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

Да ладно, мы все знаем, что программирование не всегда так гладко.

Вторая методология называется гибкое программирование.

Гибкое программирование больше подходит для больших проектов с командами, но его можно применять везде. Agile-программирование — это, по сути, противоположность водопадному программированию: вместо того, чтобы создавать программу одним махом, вы создаете ее постепенно, итерациями.

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

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

Сбалансированная диета

Ааа… Я же говорил, что это не займет много времени! Теперь вернемся к обсуждаемой теме!

Лучший способ планирования программы — это планировать с учетом обеих этих методологий. Соблюдайте баланс.

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

Однако не переусердствуйте.

Не усложняйте дизайн и внутреннюю работу. Да, вы планируете, но не переусердствуйте со своими проектами только потому, что теперь у них есть какая-то форма плана (иногда мы все попадаем в эту ловушку). Как говорится в программной поговорке: «Не усложняй, тупица». Держите план простым, но достаточно подробным, чтобы служить своей цели.

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

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

Однако будьте со вкусом.

Не добавляйте функции только потому, что они могут оказаться полезными в будущем. Такое отношение обычно лучше всего подходит для крупных проектов (часто коммерческих), где программное обеспечение будет использоваться и повторно использоваться несколько раз. В таких ситуациях можно упростить задачу, оставив в программном обеспечении некоторые дополнительные функции plug-and-play. Тем не менее, в небольших проектах добавляются функции, которые стоят потраченного на них времени, и при этом служат или поддерживают основную цель программного обеспечения.

Это все люди!

Фу! Я думаю, что я сказал тонну здесь. Итак, давайте подведем итог:

  • Планирование важно.
  • Для более крупных проектов потратьте несколько минут на планирование того, что происходит.
  • Не переусердствуйте с планированием. Он должен быть простым, относительно быстрым и тщательным.
  • Будьте со вкусом в своих итерациях и функциях — не все функции необходимы.

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

Кредит:

Программное обеспечение XB

Хейлем, Джефф О и Морган Херлокер из Software Engineering Stack Exchange

XKCD комиксы

Freepik.com

Первоначально опубликовано на www.loadingdeveloper.com 28 сентября 2017 г.