Написать пост

Что труднее всего даётся разработчику и что с этим делать: 5 практических советов

Аватар Типичный программист

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

Владимир Масальцев, руководитель группы разработки ПО Тверского Технологического центра Accenture Russia

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

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

Шаг 1: Доверяй, но проверяй

Начинающие разработчики часто реализуют «хорошие» алгоритмы, которые прекрасно работают с «правильными» данными. Они не обращают внимание на поведение программы, когда в качестве исходной информации поступают «неправильные» данные. А именно это, как правило, первым делом и случается, как только программа начинает работать в продуктивной среде.

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

Шаг 2: Встаньте на место пользователя

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

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

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

Шаг 3: Комментируйте логику кода при его написании

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

В большинстве случаев достаточно будет одного пояснения на каждые 10–20 строк кода, это сильно упростит последующую поддержку и модификацию приложения.

Шаг 4: Ничего не откладывайте на потом

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

Такие вещи выглядят не слишком существенными на фоне других задач. Создаётся ощущение, что их можно пропустить и вернуться к ним позже. Самое трудное — осознать, что потом может не наступить. После тестирования и исправления дефектов на доработки часто просто не остаётся времени. Не стоит пропускать или откладывать что-либо в реализации алгоритма, особенно если работа над ним занимает больше одного дня.

Шаг 5: Сохраняйте спокойствие и выдержку

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

В лучшем случае код может содержать кучу «мусора», оставшегося от попыток решения алгоритмических проблем. А в худшем — программа может просто не быть в достаточной степени отлажена и протестирована, чтобы справляться со всем спектром возложенных на неё бизнес-процессов.

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

Следите за новыми постами
Следите за новыми постами по любимым темам
8К открытий8К показов