Клуб разработчиков программных систем

Темы | Статьи | Рейтинги |

Что такое правильная разработка программ?

Что такое правильная разработка программ?

Сергей Трофимов

26/04/2003

Что такое правильная разработка программных систем? Что является правильным? Создаете ли вы «программу на коленке» или используете новейшие методологии 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 – жучок, как часто называют ошибки в программах.

11
Статьи по теме:

Сколько стоит программный проект
Джоэл о программировании
Психбольница в руках пациентов
Профессиональная разработка программного обеспечения
Почему я против демоверсий
Что такое правильная разработка программ?
Процесс разработки программного обеспечения ICONIX
К вопросу о современной организации программирования
Заметки о российском программировании
Заметки об американском программировании

Связанные темы:
Процесс разработки программ
| 1 | 2 |

Имя : globus 05/05/2003 14:44
Сообщение:
Не могу сказать что согласен с автором статьи. Вообще даже при разработке небольшого программного продукта должно быть четкое и глубокое планирование и вестись документация. Важно это потому что подавляющее большинство начинают своию профессиональную деятельность именно с таких небольших проектов и подобный подход вырабатывает стиль работы. Просто потом будет легче и проще. Да и вообще эскизы на бумаге позволяют заметить миллион тонких моментов которые потом пришлось бы исправлять по ходу непосредственной программной реализации и тратить время на дебагинг.
Ответить

Имя : Mogikan 05/05/2003 15:40
Сообщение:
Сергей, ты все же невнимателен к коментариям. Кто говорит о выборе и возможностях языков программирования? Это отдельный вопрос. Одно все же радует, что ты согласился и сам написал:"..программные продукты разных весовых категорий, и, соотвественно, процесс разработки кардинально отличается..". Вот это что, по моему, что не хватало в статье - обозначить круг вопросов. При домашней разработке ПО я с тобой полностью согласен - можно действовать под "вдохновение" и со стимуляторами типа пива.
Но почему меня все это так задело? - очень хорошо прокомментировал globus (за что ему спасибо) - это дело стиля (навыков). Если человек с самого начала приучается вести разработки без плана,документации, рассмотрения/анализа соотв. технологий и т.д. то потом его переубедить очень сложно. Известно, что переучивание зачастую гораздо тяжеле, чем человека с 0 обучать.
А твоя статья именно такой стиль и пропагандирует. Вот что обидно.
Видно, что ты парень с мозгами, и сам до всего этого дойдешь со временем, но не смущай, пожалуйста, молодые, еще неокрепршие умы. Ведь перо в твоих руках - оружие!
Удачи!
Ответить

Имя : Oleg 07/05/2003 12:18
Сообщение:
Подеритесь еще!
Человек написал дело - не надо стрелять из пушки по воробьям.
Каждая задача решается по своему, ПО и железо соответственно.
Отлаженная программа красива и действенна, а на чем она работает - второе дело. Вообще складывается впечатление, что ПО хвалит железо и наоборот - чем дальще тем больше. Если взять основной софт- игры :), то пока ничего круче Элиты и Стакана не сделано ("новье" красиво, объемно, тормознуто, просит денег ...)
Ответить

Имя : Ser Город : Istambul 19/09/2003 11:46
Сообщение:
Взгляд автора правильный, обоснованный.
Но это мнение человека, пришедшего в программирование "от сохи".
Прежде чем человека пускать "кодить" по настоящему, надо
надо научить подходам к программированию, показать
разный инструментарий. И он потом выберет, как программировать.
А с неучем в команде не поработаешь нормально. Он единоличник.
И правильно люди говорят, с начала - бумага!
Потом всё остальное.
Ответов: 1 Последний ответ: 18/11/2003 13:56

Имя : Sega 25/10/2003 00:08
Сообщение:
да да. Есть люди которые в 2003г. умудряются продаваь свои проги на ms access 2.0 !!! за 2000 !!! у.е. А руки простите из одного места, а вот маркетинг .....
Отсюда вывод: Что такое правильная разработка программ? - умение продавать!!!
Ответов: 1 Последний ответ: 25/10/2003 13:35

Имя : Balbes 27/02/2004 00:07
Сообщение:
Delphi и VC++ ЭТО НЕ ЯЗЫКИ ПРОГРАММИРОВАНИЯ. Это Среда Разработки.
Языки соответсвенно Object pascal и C++.
Ответить

Имя : Reaper 21/08/2004 03:03
Сообщение:
Заметте - самое большое обсуждение из всех статей представленных на сайте :) Мое ИМХО: тот кто не учится - сходит с дистанции первым. Малые фирмы как правило не устойчиви к серъезным колебаниям рынка программной продукции, и следовательно для того чтобы рынок развивался малые компании должны объединяться, становится большими. Их место пусть занимают новые малые компании. Не развиваться - все равно что бегать с топором за мамонтами, и при этом жить долго и счасливо. Это застой и с этим вероятно нужно бороться. Разные технологии программирования, четкое регламентирование производства и т.п. разрабатывают не только для получения гонораров. Есть реальные проблеммы, которые я бы свел в одну - человеческий фактор. Четко инструктированная машина и программист (часто личность творческая) плохо совмещаются. Если программа маленькая, то ошибка при ее написании может быть сведена к минимуму без специальных методологий. Кгда программа большая - ошибка накапливается быстрее чем ее успевают убирать. Выводы делайте сами.
Ответить

Имя : Reaper 21/08/2004 03:07
Сообщение:
Кстати балбес прав :) ... слона то я и не приметил ... :)
Ответить

Имя : bilimba 02/03/2005 17:11
Сообщение:
в сухом остатке имеем "цель оправдывает средства". но, если так, то самой правильной разработкой является убиение старухи-процентщицы с последующим присвоением её наследства. ну и что, что с программированием здесь как-то не густо? зато "процесс, приносящий дивиденды" налицо
Ответов: 1 Последний ответ: 04/03/2005 23:11


| 1 | 2 |
Комментарии к статьям закрыты.

© Trofimov Sergey   http://www.caseclub.ru при цитировании ссылка обязательна.