Процесс разработки

Приветствую всех!

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

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

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

Собственно сам алгоритм

1.       Изначально программа проектируется в голове или на бумаге, т.е. разрабатываем архитектуру приложения.

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

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

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

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

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

7.       После отдыха взгляните на архитектуру приложения ещё раз, и, при необходимости, измените её. После - оптимизируйте код.

8.       Повторять с 5 по 7 пункт при добавлении каждого нового функционала до написания программы.

Пройдемся по пунктам

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

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

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

Оптимизировать лучше меньший объём кода и чаще, чем всё и очень редко. Такой подход хорош простотой и лёгкостью оптимизации. Под оптимизацией понимается все, что входит в оптимизацию кода, например, рефакторинг, оптимизация производительности.

Оптимизирование кода после отдыха, а не перед ним, имеет преимущество из-за того, что происходит на свежую голову.

Заключение

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

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

Начинающим я бы не рекомендовал так часто оптимизировать код, чтобы не потерять интерес к основной разработке. Но людям, страдающим здоровым перфекционизмом, этот метод особенно понравится! Главное не перебарщивать и не делать оптимизацию целью.