Подводные камни

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

Начинаем новый проект
Как вы начинаете новый проект? Общаетесь ли вы с заказчиком, или требуете "техническое задание"? Готовитесь ли вы к будущей работе или садитесь за написание кода сразу? Многие начинающие программисты (да и не совсем начинающие) стремятся минимизировать данную фазу проекта и поскорее перейти к непосредственному программированию, но не стоит забывать, что написание кода это не есть программирование, как не есть дырка сыром, это лишь его часть, хотя и наиболее важная, но все же часть.
Подводные камни
И вот новый заказчик с очередным, довольно простым и прибыльным проектом. Пусть его техническое задание на первый взгляд кажется трудоемким, но вас это не пугает! Вы внимательно, хоть и по диагонали, читаете этот увесистый документ и оцениваете стоимость будущей системы. Конечно это не общепринятый план действий, но довольно распространенный, не так ли? Этот подход имеет множество подводных камней, но и полезен тем, что позволяет не утруждать себя сложной подготовкой к простому проекту.
И так какие проблемы могут ждать вас и уже попадались мне?
1. Недопонимание - заказчик хотел одно, а вы поняли совершенно иначе, и в результате заказчик хоть и не против выкупить систему, ибо долго ждал, да и спорить с авторитетным "кодером" не хочется, но осадок остался;
2. Плохой фундамент - вроде вот оно, техническое задание, но многие моменты в нем вам кажутся непонятными или абсурдными. Конечно это не проблема, но хотелось бы лучше;
3. Недооценка или переоценка - два предыдущих пункта обычно ведут к занижению или завышению стоимости;
4. Стандарт - у вас вряд ли есть четкий прайс-лист ваших услуг, не так ли? Максимум n руб. за час, и то, с "можно договориться".
Эти, "не очень" серьезные проблемы, могут сильно повредить вам, когда заказчик станет крупнее, бюджет больше, и риски выше.
Возможные решения
Я всегда начинаю проект не с кода или листа бумаги, а с подробного плана будущих работ, анализа требований заказчика и оценки эффективности. Крупные компании, занимающиеся разработкой программного обеспечения, формируют довольно большие пакеты документации именно на данном этапе, так почему бы не последовать их примеру. К подобной, обязательной документации, лично я отношу следующую:
1. Модель прецедентов - если вы еще не знаете что это, настоятельно советую узнать. Прецедент это сценарий использования некоторой части системы, и описывать требования заказчика с точки зрения сценариев использования очень легко и понятно как для вас, так и для заказчика;
2. Словарь терминов - все неясные или неоднозначные термины я выношу в отдельный словарь, привязанный к проекту;
3. Предметная модель - когда я писал свой преобразователь объектов в реляционные структуры, я уже достаточно хорошо знал SQL, но все равно предварительно я перечитал свои конспекты и записал основные моменты в отдельный документ. В последующем этот документ сэкономил мне немало времени, так как он содержал очень полезные решения и подзабытые мною хитрости SQL. Изучайте предметную область перед началом работы;
4. Функциональная спецификация - данный документ служит для закрепления понимания между мной и заказчиком. Если написанная мной программа полностью соответствует изложенным в этом документе требованиям, а заказчик не доволен, то я забираю деньги (но, конечно же, не бросаю заказчика ) ).
Заметьте, что данный этап не включает в себя технического задания. Почему? - спросите вы. Дело в том, что техническое задание это документ, используемый разработчиками, и он, как правило, состоит из огромного числа других документов, а потому, нет возможности подготовить его на столь раннем этапе.

Готовим фундамент
Заказ принят, аванс оплачен, компьютер включен, что дальше? Открываем любимую IDE или текстовый редактор и начинаем писать главную страницу сай... то есть главное окно системы )) Ну как правило так и поступают, но это не лучший выбор для проектов, которые планируется сопровождать, а не просто продать и забыть.
Подводные камни
На данном этапе могу выделить множество "подводных камней", но остановлюсь на наиболее важных:
1. Непонимание проекта - вы вроде поняли, что нужно сделать, но часто останавливаетесь и задумываетесь - а что я сейчас делаю? Для вас подбор имени свойству, классу или методу целая проблема, а о размерах классов я вообще молчу. Скорее всего, вы плохо понимаете, что вы делаете;
2. Сложность моделирования - всем нам тяжело держать в голове сложные модели. Если вы забываете недавно пришедшею мысль, то вы не одиноки;
3. Недопонимание внутри команды - вы пишите код, за вами его тут же переделывают ваши коллеги - знакомая картина?
Возможные решения
Никогда не начинайте проект с кода! Это наиболее опасный путь, так как подобные программы нужно писать на одном дыхании и как можно быстрее избавляться от них, как от бомбы с часовым механизмом! Такие системы, это как бег у сороконожки, пока она делает это подсознательно, все получается, но стоит задуматься над тем, что в данный момент нужно делать и что ждет впереди, как все рушиться и бедное создание попадает в глубокий ступор.
1. Модель классов - выделите основные сущности будущей системы и опишите их в модели классов, а за основу можно взять уже существующую модель предметной области;
2. Модель взаимодействия - объекты создаются для взаимодействия, так опишите эти взаимодействия в данной модели;
3. Абстрагирование - старайтесь использовать слоистую модель разработки, внизу наиболее прикладные механизмы, вверху наиболее абстрактные. Внизу класс для работы с файлом, вверху класс для буферизации данных с помощью файлов.

Пишем
К тому времени как я начну писать код, вы наверняка уже закончите половину системы ))). И так написание кода, или реализация системы, является наиболее важной и ответственной частью проекта. Это одновременно и наиболее сложный этап, так как он требует наибольшей концентрации и использования всех своих умений. Обычно данный этап для многих новичков является испытанием их возможностей, но для меня это механический труд, по типу - а как быстро я сейчас набираю слепым методом? - да, да! Я пишу код на основе подробных моделей и разработанных архитектур, потому его написание практически не вызывает трудностей, написание данной статьи для меня куда сложнее )
Подводные камни
Сразу к делу:
1. Не на что опереться - вы держите всю систему в голове и каплями выплескиваете ее в код, часто забывая, что вы делаете в данный момент? Знакомая картина для 99% начинающих программистов;
2. Сложность - самая опасная часть программирования! Все описанное ранее требуется лишь для того, чтобы сделать систему наиболее простой в понимании;
3. Сроки - я еще не видел программиста, который всегда успевает сдать проект во время, а истоком данной проблемы является первый этап!
4. Знания - учитесь во время программирования? Не стоит! Учиться надо в свободное от работы время и наиболее жадными способами. Как вам 350 страничная книга за 4 дня? Это не предел!
Знакомые проблемы? Думаю да. С ними сталкивался каждый программист!
Возможные решения
1. Планы - если вы не упустили предыдущих двух этапов, то проблем у вас с фундаментом для будущей системы не будет;
2. Разделяй и властвуй - если алгоритм вам кажется сложным, разделите его на части, а те еще раз, и так, пока алгоритм не станет тривиальным. Это старое, но мощное средство снижения сложности задач;
3. Запасы времени - заказчик не согласен на 2 недели работы? Откажитесь от заказа! Условия ставите вы, а не заказчик, так как вам выполнять заказ;
4. Учитесь - читайте больше качественных книг по программированию, языку программирования, архитектурам, решениям, шаблонам, теории и т.д.

Проверяем
Программа написана, запущена в специально подготовленной среде и выдала ожидаемые результаты? Продавай скорее! ))) На данном этапе необходимо сломать программу. "Сломать ее полностью"!
Подводные камни
1. Страх - в процессе написания или изменения кода часто появляется чувство страха. Оно вызвано нашей неуверенностью, тем что код может не запуститься или того хуже, повлиять на всю систему.
Возможные решения
1. Юнит-тесты - пишите юнит-тесты чаще, пишите их всегда, когда появляется чувство страха! Они как лакмусовая бумага, покажут вам, что и почему не работает;
2. Покрытие - постарайтесь покрыть тестами как можно больше кода, часто ошибки встречаются там, где меньше всего их ждешь.

Описываем для потомков
Вы когда-нибудь писали документацию для своих программ? Если да, то это уже хорошо, но если нет, сжечь вас и прах ваш... хотя нет, лучше так:
Подводные камни
1. Поддержка проекта - нет желания возвращаться к той каше, что была написана 4 месяца назад? Можно ведь просто выключить телефон )
2. Популярность - какой проект вы выберете? Японоязычная документация и никаких комментариев в коде или рускоязычная документация с отлично поддержикой?
Возможные решения
1. Документирование - PHPDoc ваш лучший друг! Нет? Уверен что да! )
2. Пакет документов - если вы послушали меня, и все же к концу проекта у вас набралось 2-3 документа, не выкидывайте их, они вам еще обязательно понадобятся, хотя-бы чтоб вспомнить, зачем же вы в цикле обращались к базе.
Итоги
Попробуйте написать проект с использованием изложенных здесь правил, хотя-бы просто для общего развития, стоит попробовать что-то новое, не так ли? Удачи в программировании!

URL: https://visavi.net/articles/438