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

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

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

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

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

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 – жучок, как часто называют ошибки в программах.

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

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

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

Имя : Владимир Волосенков Город : Минск 28/04/2003 22:35
Сообщение:
Спасибо за трезвый и взвешенный взгляд на вопрос правильной разработки. Наконец-то телегу и лошадь поставили в правильном порядке :)
Ответить

Имя : Вася Пупкин Город : Киев 28/04/2003 23:35
Сообщение:
Очень правильная статья. Наконец-то я узнал как правильно разрабатывать ПО! Много нового и интересного...
Ответить

Имя : Юрий Город : США 29/04/2003 07:30
Сообщение:
Автор: "Вася! Ты такой крутой программер! Я тащучь! Но если ты задумываешься о будущем, то тебе стоит немного почитать о современных методах и средствах создания программных систем. Я тут и ссылочки припас. Только кликни... За одно найдешь себе работу с большим окладом."

Вася: "у меня глаза теперь открылись..."

№;%:?#&!

А насчет SWITCH-технологии я с Борисом согласен. Там среди авторов еще есть, кажется, Туккель.
НО! Квалифицированный программист должен знать, что такое конечный автомат, и уметь им пользоваться.
Ответить

Имя : * Город : * 29/04/2003 07:33
Сообщение:
Не согласен. У каждого программиста под словом "на коленке"
есть свой набор технологии и инструментария. И от того, что он
не использует новомодных методов, вовсе не значит, что он не
использует ни чего.
А все эти HUP, XP, UML - красивая обертка давно известных подходов
Ответить

Имя : Viking Город : Черкассы 29/04/2003 12:57
Сообщение:
по поводу SWITCH- и других технологий должен сказать, что знать о них желательно, но полностью изучать не обязательно. Настоящему программисту нужно научиться четко представлять себе алгоритм или модель системы в каком-то представлении. Вот тут и играет роль указанное выше "желательно". Ведь чем больше парадигм (логическое, функциональное, стэковое, декларативное, процедурное, модульное, объектно-ориентированное, визуальное, высокоуровневое, низкоуровневое программирование) и технологий програмисту известно тем удачнее он сможет представить себе алгоритм.
Главное не цыклиться над тем, что использовать (в статье же написано, что каждый выбирает сам).
Это как в шахматах - каждый следующий ход должен давать тебе больше свободы для действий, а не ограничивать одной статегией или комбинацией. Свобода - вот что главное в творчестве (читай программировании).
Ответить

Имя : Изуродованная душа с курса талантливейших программ Город : Санкт-Петербург 29/04/2003 14:47
Сообщение:
Сергею:
Хм. А я не понял, в чем смысл статьи. В том, что разрабатывать нужно то, что можно хорошо продать? А как же программирование ради процесса (в свободное от основоной работы время)? Я, например, веду 3 разработки параллельно - одну для "денег" (хотя тоже интересную), и 2 для себя - потому-что интересно... Это значит "неправильное программирование"? Или я недопонял, что-то?

А статья вполне любопытна... Но я (прошу не бить ногами, это мое личное мнение) лучше бы почитал нечто более приземленное.

Борису:
Я не понимаю:
а) Что вы понимаете под настоящим программистом, и когда это Шалыто сказал вам, что он программист?
б) Зачем гадить человеку в месте, где он этого не увидит, вы так боитесь Шалыто, что не можете сказать ему это в лицо?
в) А вы написали 2 книги, десятки статей, попробовали поиметь дело с этими талантливейшими (не спорю... :-)) программистами и "испортить" их души? Не уверен на 100%, но думаю - нет. Как попробуете, расскажите результат - будет интересно :-)

Да, если захотите что-нибудь ответить, не пишите сюда - я оставил свой e-mail, с удовольствием поговорим. :-)
Ответов: 1 Последний ответ: 29/04/2003 15:16

Имя : Alik Город : Донецк 30/04/2003 13:14
Сообщение:
Как говорится "на вкус и цвет одни враги"... Я хотел бы только выразить свою точку зрения, предварительно выразив уважение и понимание вышесказанных точек зрений. Принимать их или нет - это личное дело каждого. Лично мне кажется, что автор больше пускается в полемику, поскольку я в настоящее время сталкиваюсь с тем, что ряд программ нужно писать и на Shell'e, а автор говорит о Rational Rose и т.д.... Приведу слова своего первого преподавателя по Pascal'ю, правильность которых я понял только через несколько лет - "Программа должна писаться на бумаге, а не на компьютере". Я прекрасно понимаю, что после этого в меня полетит целая куча кирпичей и булыжников со стороны людей, которые пользуются теми же самыми Rational Rose и т.д., но прошу и меня понять правильно - я никого не пытаюсь судить. Я прошу каждого, кто кинет в меня камень ответить на один вопрос - "Много блоков, различных моментов, функций процедур и их назначение будет он помнить при разработке разработке программы более 2000 строк? И насколько много он захочет изменить по прошествии хотя бы одного месяца?"
С уважением ко всем высказавшимся и тем кому еще высказаться по этому поводу.
Алик.
Ответов: 1 Последний ответ: 09/09/2003 22:30

Имя : adisk 01/05/2003 11:32
Сообщение:
Читая статью, все больше узнавал свою ситуацию. Раньше было стремление использовать новомодные языки и лишь недавно понял, что главное все-таки результат. Не супер-модное ПО, а удовлетворение потребителя.
А вот новые методы и алгоритмы знать надо.
Ответить

Имя : Mogikan Город : ..сегодня здесь, а завтра там. 04/05/2003 22:19
Сообщение:
4all, но для студентов "одного из вузов СПб" особенно.

Не собираюсь защищать Шалыто (тем более не знаю кто он), но советую все же прислушаться к его словам. Видно, что человек сталкивался с серьезными вещами на практике! И не стоит здесь ИМХО студентам их личное отношение высказывать.
Статья, в общем, хороша тем, что достаточно точно описывает ситуацию создания ПО в большинстве фирм, а именно: практически полная безответсвенность программиста перед своим продуктом. Работаем по принципу "лишь бы продать", а потом, если что, патчей наклепаем.

А вы можете себе представить (судя по комментам к статье и автор и "сочувствующие" на практике не сталкивались с ПО для жизнекритичных систем.) такую задачу, где каждый "патч" может человеческих жизней стоить?? Например в системе управления тормозами грузовика? (я не говорю о системах ПРО или управления ядерным реактором).

В общем видно, что автор этой статьи даже не удосужился взглянуть на те методы, что предлагаются нынче для написания "правильного ПО". Существуют даже стандарты (напр. TickIT).

Заключение: Статья студента первокурсника о способах написания ПО. Описана живым и понятным языком.Но выводы сделаны просто ущербные!!

/**Mogikan*/
инженер контроля ПО. (электроника для VOLVO,MAN,Dimler-Crysler.)
Ответить

Имя : Сергей Трофимов 05/05/2003 08:52
Сообщение:
Для начала несколько общих замечаний:
Можно меня называть разными словами, а можно называть этими же словами кого-нибудь другого (здесь это уже прозвучало), это банально и не интересно.
Люди из разных уголков нашей страны (и не нашей тоже) читают личную перепалку, и, наверное, кто-то посмеется над несдержанными русскими, публично втаптывающими друг друга в грязь. Мне же грустно видеть эти мелкие «наезды» друг на друга. Поэтому неудовольствие той или иной ЛИЧНОСТЬЮ выражайте в другом месте. Давайте уважать собеседника!
Теперь по поводу процесса разработки. Каждый человек смотрит на этот процесс относительно багажа своих знаний и опыта, и спор между разработчиками критически важных программных систем (например, управления ядерным реактором или космическим челноком), и между разработчиками настольных приложений подобен спору о том, какой язык программирования лучше, т.е. принципиально здесь не может быть единого мнения.
Это программные продукты разных весовых категорий, и, соотвественно, процесс разработки кардинально отличается. Одни говорят, что нужны тысячи страниц проектной документации, а другие гордятся тем, что могут разработать программу совсем без оной. И каждый будет по-своему прав, поскольку у каждого есть успешный опыт такой работы. Никто не принуждает вас использовать приложение Windows CE для управления головкой наведения ядерной ракеты, так и никто не может принудить написать тысячу страниц проектной документации для программы печати платежных поручений.
Поэтому, призываю читателей, перед тем, как начать клеймить позором всех этих «дилетантов», для начала определить для себя область применения полученной информации.
Ответов: 1 Последний ответ: 05/05/2003 18:50


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

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