Что такое правильная
разработка программных систем? Что
является правильным? Создаете ли вы «программу
на коленке» или используете новейшие
методологии RUP,
XP, UML,
или что-то более экзотическое. Когда
можно сказать, что разработка правильна,
что является критерием? Вот некоторые
мысли по этому поводу.
Мне кажется, что этот вопрос,
вынесенный в заголовок, сродни уже
обсуждавшемуся на страницах сайта
вопросу, какой язык программирования
лучше Delphi
или VC++?
Найдется масса людей, которые
проигнорируют его, и будут доказывать вам,
что все этих «сях» и «дельфях» нет ничего
интересного и Visual
Basic
самый лучший из когда-нибудь написанных
человечеством языков программирования.
Ведь он такой простой, в нем нет никаких
там классов или еще чего-нибудь такого,
что можно может быть использовано при
работе со страшным, похожим на
ругательство словом UML.
И оставим этих людей при их
мнении, поскольку разубеждать человека в
чем-то занятие неблагодарное. Итак, не
будем касаться вопроса, на чем или при
помощи каких средств создаются программы,
а подумаем о том, как они создаются, т.е.
нас интересует собственно процесс. (Как в
анекдоте про поручика Ржевского,
которого спросили «Вы любите детей?»,
ответ, я думаю, вам известен*)
Представим, что есть такой
программист или системный администратор,
в общем, человек, которого сегодня
называют гордым именем «IT
специалист» Вася Пупкин (персонаж
полностью вымышленный и все
совпадения с реальными людьми в части
имени фамилии или отчества, года рождения
и вероисповедания, совершенно
случайны). Как истинно русский
человек, он приходит на работу к обеду,
зато до трех часов ночи может долбить по
клавишам компьютера. Когда он в
настроении, то может написать какой-нибудь
мудреный алгоритм, которым потом
похвастается перед друзьями, а когда не в
духе, то гоняет по сети в «кваку» или
просто «чатится»**.
Итак, наш Василий в свободное
от основной работы время, или даже на
работе, когда начальство смотрит в другую
сторону, пишет под заказ небольшие
программы, скажем на Visual
Basic,
макроязыке 1C,
Delphi (выберите
нужное и подчеркните это на своем
мониторе), которые автоматизируют
рутинные операции в какой-нибудь
знакомой бухгалтерии, для его девушки,
бабушки или просто знакомых (продолжаем
интенсивно подчеркивать).
Совершенно не используя
никаких новомодных штучек, не нуждаясь в
команде аналитиков и тестеров (с которыми
потом нужно делиться дивидендами) он
получает за свою работу нормальное
вознаграждение, которого хватает на пиво
с друзьями, и совершенно, ну то есть
абсолютно доволен жизнью (что даже как-то
странно в наше время).
Как вы думаете, он правильно
разрабатывает программы, не используя
никаких методологий, не написав ни
строчки официальных документов и не
нарисовав в Rational
Rose, Visio
или еще Бог знает в чем,
каких-нибудь UML
диаграмм? На мой взгляд, такая разработка
совершенно правильна. И я могу
аргументировать эту точку зрения,
читайте дальше. Как говорят, не
переключайтесь на другой канал, мы
вернемся к вам после рекламной паузы :).
Есть определенная цель
разработки, которая может быть не всегда
точно очерчена и осознается, но она есть
всегда. В нашем случае – эта работа
делается, для того чтобы создать нужный
кому-то программный продукт, за который и
будет получено вознаграждение. Если
вознаграждение наш программист получает,
значит – цель достигнута. Вознаграждение
может быть получено как в денежном
эквиваленте, так и в форме опыта,
признания товарищей, получения
внутреннего удовлетворения от глубины
собственного интеллекта и т.д.
Однако если программа
делается для пользователя, коим не
является сам программист, то его (пользователя)
меньше всего волнует, что там внутри и как
организован процесс разработки. По
большому счету его даже не волнует,
сделана ли программа на Visual Basic или С++, главное, чтобы программа
была не слишком «тормознутой», занимала
не очень много места, стоила тех денег,
которые за нее просят, и, самое главное,
выполняла желаемые функции без большого
количества «жучков»***, чтобы
работа с программой не превращалась в
хождение по минному полю, где «шаг вправо,
шаг влево – расстрел на месте».
Итак, отталкиваясь от мысли,
что получение адекватного
вознаграждения, которого,
к примеру, хватает на распитие легких
спиртных напитков, а может и на ресторан,
боулинг, поездки на Гаваи, за вполне
определенную работу – есть показатель,
что работа выполняется успешно (если вы
еще подчеркиваете, то вам пора прекратить
это занятие и идти за тряпочкой для
протирки монитора). Если нашего Василия не поджидают
вечером после работы разъяренные
пользователи его программных продуктов,
чтобы высказать ему все, что они о нем
думают, а может не только высказать, что
также является одним из показателей
успешно выполненной работы.
Вознаграждение есть, пользователи не
более или менее довольны – наш Василий
идет правильным путем (согласно
завещанию великого рассказчика).
Теперь немного расширим наш
пример и представим, что небольшая
компания-разработчик программного
обеспечения до 10-15 человек, «клепает»
свои программы для таких же небольших
компаний, которые занимаются торговлей,
штучным изготовлением мебели или чем-то
подобным, но у которых оборот таков, что Excel
или того хуже, бумажный гроссбух не
справляется с ними.
Должна ли такая компания
придерживаться объектно-ориентированных
методов разработки, использовать UML, RUP,
MSF или что-то
еще? Вот здесь мы как раз и попадаем в
ловушку. Мы не можем точно сказать,
нуждается ли конкретная компания в этих
средствах, если не рассмотрим то
вознаграждение, которое она получает за
свои труды. Ведь эти средства только помогают ускорить
разработку и сделать ее более
качественной. А если компания-разработчик
не нуждается в том, чтобы ее продукция
выпускалась быстрее?
Если вы думаете, что таких уже
нет, то ошибаетесь. Я знал несколько
компаний, руководители которых на вопрос
о том, хотелось ли ему сделать разработку
более быстрой и
более качественной, а значит более
дешевой и, соответственно, получать
большие прибыли мне отвечал, что в этом
нет необходимости (!).
На постановку процесса нужны
дополнительные деньги, а компания
нормально существует, доход ее стабилен и
его (обычно!) хватает
на оплату труда программистов и с трудом
хватает на upgrade
технических средств. Да, программисты
делают свое дело долго, не очень
качественно, часто переделывают, но и
платят им не особенно много, поскольку
нужны кодировщики не очень высокого
класса, достаточно студентов вузов,
которые часто работают только за опыт и
небольшие деньги.
Обычно, в таких компаниях есть
жесткая иерархия. Есть костяк
профессионалов, на которых собственно и
держится разработка, таких людей немного,
один-два в компании и они могут общаться
между собой, не пользуясь программными
инструментами, а держа все вопросы в
голове или в большой схеме на стене.
Правильно ли организован в
такой компании процесс разработки? С
точки зрения руководителя – совершенно
правильно. Цели достигаются, разработка
идет, клиент, обычно, доволен. Зачем в
таком случае тратить деньги на
приобретение программных средств, для
использования которых нужно нанять
профессионалов или отправить всех своих
работников на дорогостоящие курсы (а они
после обучения найдут себе работу с
большим окладом).
Небольшие компании
вырабатывают собственный стиль ведения
программных проектов, который со стороны
выглядит несколько странно, но только на
первый взгляд. Если приглядеться, то
такие компании сами создают себе
программные средства, которые облегчают
им жизнь. Например, я видел несколько
программных продуктов в той или иной
степени повторяющих функциональность Rational
ClearQuest и
разработанных для внутреннего
использования. Хотя такие продукты и
обладают меньшим набором функций, однако
не меньшим, чем нужно для нормального
ведения программного проекта в
конкретной компании.
Такие компании создают
собственные регламенты разработки,
общаются по e-mail
между собой и «подкручивают» ПО под
заказчика без бюрократических
проволочек. Процесс поставлен таким
образом, что он как бы балансирует между
затратами и прибылью и при нормальном
ходе вещей он все-таки прибыльный.
И в конце концов, Microsoft или Oracle
тоже не всегда были большими компаниями,
они тоже начинали, и тоже вырабатывали
свои методики.
Теперь мы непосредственно
подошли к ответу на вопрос, вынесенный в
заголовок. А именно, что такое правильная
разработка программ? Я думаю, что для вас
ответ уже очевиден. Правильная
разработка – не та, в которой
используются самые последние методы и
средства разработки. Правильная
разработка – это процесс, приносящий
дивиденды. Не так важно, в каком виде
приходят эти дивиденды, и не важно,
сколько затрачено на это времени и сил.
Возможно, это время можно было сократить,
но после того, как проект закончен уже
трудно об этом судить. Важно, что прибыль
компания или отдельный разработчик
получает именно здесь и сейчас и это его
устраивает.
* * *
P.S.
Однако, если вас в чем-то не устраивает
процесс разработки, в котором вы
участвуете, или вы задумываетесь о
будущем, то вам стоит немного почитать о
современных методах и
средствах создания
программных систем.
______________________________________________________
*Имеется
ввиду анекдот
– Поручик, Вы любите детей?
– Детей-с, хм…, но сам процесс…
**Quake
– известная стрелялка («шутер»).
Чатиться – общаться
посредством чата.
*** bug
– жучок, как часто называют ошибки в
программах.
