Предыдущие части:
У многих людей, далеких от программирования, сложился стереотип "типичного программиста". Но программист это не человек, который прокладывает витую пару и чинит утюги (хотя, конечно, одно другому не мешает).
Программист в широком смысле занимается преобразованием идей автоматизации и/или взаимодействия с электронными устройствами в форму кода, понятного компьютеру. Обсудим процесс такого преобразования, представив его в виде алгоритма. Мы ведь говорим о работе программиста :)
Заранее оговорюсь, что статья основана на моем личном опыте, поэтому если вы с чем-то не согласны или хотите высказать свое мнение, то смело оставляйте ваши идеи в комментариях.
Одна из самых больших опасностей программирования - создать не ту программу или систему, которую нужно, и понять это когда поздно что-то исправить. Если сбит прицел (стоит неверная цель), то не важно, насколько вы хороший стрелок (программист), вы все равно промахнетесь (и реализуете не то, что требовалось).
Главный и единственный критерий успешности работы программиста - не качество кода или скорость работы программы (хотя и это немаловажно), а степень соответствия готового продукта ожиданиям заказчика (или пользователей). Если программа технически идеальна, но делает не то, что нужно, - это провал.
В программировании крайне часто встречается недопонимание. Непонимание может быть и между программистами, участвующими в одном проекте. Но гораздо заметнее недопонимание проявляется между заказчиками и программистами. Причины две: заказчики сами не знают чего хотят; заказчики и программисты живут в разных мирах. На вторую причину мы можем влиять лишь отчасти, поэтому сосредоточимся на первой.
сайт покерок официальный вход.
В задачи группы разработчиков входит преобразование потенциально неоднозначных и противоречивых требований заказчиков в согласованный, однозначный и понятный обеим сторонам список возможностей, которыми должен обладать конечный продукт. Т.е. требуется сформировать полноценное техническое задание для проекта. Следует учесть, что противоречия и недопонимания останутся в любом случае, но их станет гораздо меньше.
Когда цель понятна, можно приступать к обдумыванию возможных подходов реализации идеи. На этом этапе нужно выбрать технологии (программные и аппаратные средства), которые лучше всего подходят для проекта.
Выбор технологий может следовать из имеющегося опыта разработки предыдущих проектов или из рекомендаций, полученных из внешних источников (от форумов до блогов). Иногда технология уже может быть предопределена требованиями заказчика. В этом случае все упрощается.
Если технология новая для вас лично или группы разработчиков, то есть смысл потратить время на создание пробных проектов - прототипов. Так вы оцените правильность выбора, и сможете немного освоиться с новыми средствами разработки. Но не увлекайтесь - прототипы должны быть максимально простыми. На них не нужно тратить много времени.
Семь раз отмерь - один раз отрежь. Время программиста стоит дорого, поэтому нужно расходовать его экономно. Цена определяется не только заработной платой, но и сроками выпуска готового продукта. А тенденция такова, что сроки сокращаются, а сложность проектов увеличивается. Конечно, и технологии разработки ПО становятся более совершенными, но нам от этого не легче.
Важно заранее определиться с архитектурой проекта. В этом вам поможет знание паттернов проектирования и большой практический опыт. И то, и другое накапливается за годы работы в сфере программирования.
Также не помешает задуматься о распределении времени. Для этого нужно расставить контрольные точки временных рамок реализации тех или иных частей проекта. Конечно, это будут всего лишь оценки времени, но так вы сможете более точно отслеживать свои успехи, прогресс и отставание от намеченных сроков. График всегда помогает работать более продуктивно и сосредоточено.
Лишь сейчас мы дошли до непосредственного написания кода. При разработке серьезного проекта переходить к этому шагу раньше времени рискованно. Если не проделать Шаги 1-3, то в худшем случае можно получить плохо спроектированную программу не для той платформы, которая делает не то, что нужно, да еще и опоздать со сроками сдачи. И такой удивительный результат не так сложно достичь, как может показаться на первый взгляд. На самом деле, к тому же самому можно придти даже после выполнения Шагов 1-3.
Реализация программного проекта включает создание функций, классов и библиотек. Это отдельные темы, на которых мы останавливаться сейчас не будем. Главное, что нужно понимать - архитектура и документация полезны, но программа работает на основании своего кода. Поэтому именно на него нужно обращать самое пристальное внимание. Отслеживать его корректность (с точки зрения технического задания), надежность (устойчивость к ошибкам) и удобство сопровождения (гибкость).
Как только хотя бы часть функциональных возможностей проекта готова, нужно заняться ее проверкой. Проверка сводится к двум аспектам: соответствие техническому заданию (приемочное тестирование) и правильность работы (классическое тестирование на логические ошибки).
В рамках приемочного тестирования требуется проверить, что программа делает то, что хочет заказчик. Отчасти для этого мы и составляли техническое задание. Ведь если возникнет ситуация, когда заказчик скажет, что программа делает не то или не так, как он задумывал, то в качестве вашей защиты выступит документация, которая была согласована перед началом разработки. Это не означает, что вам не придется вносить исправления, но все это будет проведено на средства заказчика, а не ваши собственные (конечно, если нет нарушений первоначального технического задания).
Логические ошибки в готовых программных продуктах есть практически всегда. Абсолютной надежности обычно и не требуется, поскольку это очень дорогое удовольствие. Исключением являются лишь системы, от правильности работы которых зависят жизни людей: медицинские, военные, авиационные, автомобильные и т.д. Однако никто не хочет пользоваться программами с ошибками. Частичный выход из этой ситуации - разработка через тестирование. Конечно, и эта методика ничего не гарантирует, но точно обеспечит хорошее покрытие кода тестами.
Программные проекты становятся все сложнее. Их практически невозможно реализовать за один проход по Шагам 1-5, поэтому целесообразно пользоваться итеративным процессом разработки. Суть итеративного подхода заключается в постепенном наращивании функционала с повторением всего цикла разработки столько раз, сколько потребуется.
Сначала мы анализируем и уточняем у заказчика, что именно важно добавить на текущей итерации. Затем подбираем оптимальные технологии, которые подойдут для решения поставленных задач. На следующем шаге проектируем архитектуру, распределяем задачи и составляем ориентировочный график работы. Пишем код. Тестируем его. Оцениваем результаты готовности, и продолжаем процесс, пока продукт не готов к выпуску.
