Всякий кодер, начиная со студента и заканчивая профессиональным разработчиком, пишет программу под определенные цели. Чаще всего это выполнение чужого заказа. Это может быть задание из методички или работа – не важно. То, о чём пойдет речь в данной статье — распространённый подводный камень новичков, перфекционизм.

Написание кода очень похоже на решение математической задачи. Известны исходные данные, есть представление о конечной цели, дело за малым – проложить путь. И тут начинается самое интересное. Увлёкшись решением какой-нибудь подзадачи, человек старается сделать программу наиболее «удобной»: вставляет дополнительные условия проверки, изменяет стиль вывода, старается сделать алгоритм универсальным и так далее. И что в результате? Колоссальное количество времени уходит впустую. Потом вспоминается истинная цель, программа в спешке переделывается. На выходе получается продукт с кучей ошибок, если он вообще получается за оставшееся время. Приведу пример на скриншоте 1.

screenshot 1
screenshot 1

Согласно этому коду, программа должна получить от пользователя два числа, узнать какое из них больше и вывести его на экран. Превосходно, не правда ли? В методе «Greater» учтена ситуация равенства переменных, в основном теле кода есть надстройка, выводящая сообщение о равенстве, можно было бы еще вставить цикл, который бы позволил сделать алгоритм многоразовым… А должен был быть код на скриншоте 2.

screenshot 2
screenshot 2

Достаточно написать два раза число 1, чтобы вызвать ошибку. Тем не менее следовало сделать именно так, поскольку задача заключалась в том, чтобы понять принцип работы метода и затем написать подобные алгоритмы.

Чрезмерный перфекционизм – это плохо. Чтобы его сбалансировать, нужно соблюдать правила:

Перед выполнением задачи полностью прочитать условие

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

Разбить задачу на посильные части

После определения цели следует проложить путь из точки A в точку B. Пытаться написать весь код сразу бессмысленно, не следует даже пытаться. Чаще всего нужно произвести ряд преобразований, время от времени выполняя проверку. Такое количество информации удержать в голове невероятно сложно, но можно поступить разумно. Можно разбить на маленькие подзадачи, запоминая, а лучше записывая то, что имели до выполнения куска кода и что получили после. Такой подход позволит разбить программу на отдельные блоки, работоспособность которых можно проверять отдельно. Очень помогает при отладке.

Не отклоняться от плана

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

Действовать по одному стилю

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

Не возвращаться к предыдущей части после завершения

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

Правило «последней проверки»

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

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

 Перед выполнением полностью прочитать условие
 Разбить задачу на посильные части
 Не отклоняться от плана
 Действовать по одному стилю
 Не возвращаться к предыдущей части после завершения
 Правило «последней проверки»

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

Поделись новостью!

Програмирование и информационные технологии.

ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here