Васин Д.Ю. - Язык программирования Си. Курс лекций - 2003. Руководство для начинающих. М. Мир, 1988г. 512 с. Трой Д. Программирование на языке Си для персонального компьютера ibm pc Пер с англ. М. Радио и связь, 1991г. 432 с
 Скачать 1.1 Mb.
|
3.10. Проблема должна быть хорошо продумана перед тем, как она сможет быть решенаЭти правила посвящены весьма реальным проблемам и во многих отношениях являются самыми важными правилами в этой книге. Настоящее правило является настолько очевидным утверждением в повседневной жизни, что кажется странным его восприятие едва ли не ересью в применении к программированию. Мне часто говорят, что «невозможно потратить пять месяцев на проектирование, не написав ни одной строки, кода — ведь наша производительность измеряется числом строк кода, написанных за день». Люди, говорящее это, обычно знают, как делается хороший проект; просто они не, могут позволить себе такую «роскошь». Мой опыт говорит, что хорошо спроектированная программа не только работает лучше (или просто работает), но и может быть написана быстрее и быть проще в сопровождении, чем плохо спроектированная. Лишние четыре месяца при проектировании могут сэкономить вам более четырех месяцев на этапе реализации и буквально годы в период сопровождения. Вы не сможете добиться высокой производительности, если приходится выбрасывать прошлогоднюю работу из-за существенных изъянов проекта. Кроме того, скверно спроектированные программы труднее реализовать. Тот аргумент, что у вас нет времени на проектирование, потому что вы «должны захватить рынок программ как можно скорее», просто не выдерживает никакой критики, потому что реализация плохого (или никакого) проекта требует гораздо больше времени. 3.11. Компьютерное программирование является индустрией обслуживанияМеня иногда шокирует неуважение, проявляемое некоторыми программистами по отношению к пользователям своих программ, как если бы «пользователь» (произносится с презрительной усмешкой) был низшей формой жизни, неспособной к познавательной деятельности. Но факт состоит в том, что весь компьютер существует лишь с одной целью: служить конечному пользователю наших продуктов. Если никто бы не пользовался компьютерными программами, то не было бы и программистов. Печальным фактом является то, что существенно больше половины из ежегодно разрабатываемого кода выбрасывается за ненадобностью. Такие программы или никогда не поступают в эксплуатацию, или используются лишь очень короткое время, после чего выбрасываются. Это означает невероятную потерю производительности, сокращая для большинства управленцев реальные среднесуточные цифры выработки. Подумайте о всех начинающих фирмах, выпускающих программы, которые никогда не будут проданы, о всех группах разработчиков, пишущих бухгалтерские пакеты, которыми нельзя воспользоваться. Легко увидеть, как возникает эта печальная ситуация: программисты создают программы, которые никому не нужны. Исправить ее тоже легко, хотя в определенном окружении это и сталкивается с неожиданными трудностями: спросите людей, что им нужно, и затем сделайте то, что они вам сказали. К сожалению, многие программисты производят впечатление лиц, полагающих, что конечные пользователи не знают чего хотят. Вздор. Почти всегда пользователи оказываются так запуганы сыплющим специальными терминами «экспертом», что замолкают. Мне часто говорили: «Я знаю, что мне нужно, но не могу это выразить». Лучший ответ на это: «Отлично, скажите это на нормальном языке — я сделаю перевод на компьютерный». 3.12. Вовлекайте пользователей в процесс проектирования3.13. Заказчик всегда правНи одной программе не добиться успеха, если ее проектировщики не общаются непосредственно с ее конечными пользователями. Несмотря на это, часто ситуация больше напоминает игру («испорченный телефон»), в которую многие из нас играли в детском саду, когда 20 ребятишек садятся в кружок. Кто-нибудь шепчет фразу своему соседу (соседке), который передает ее своему, и так далее по кругу. Забава заключается в том, чтобы послушать как сообщение звучит после того, как пройдет весь круг — обычно ничего похожего на исходную фразу. Тот же самый процесс зачастую встречается при разработке программ. Пользователь говорит с управляющим, докладывающим другому управляющему, который нанимает консультационную фирму. Президент консультационной фирмы разговаривает с руководителем разработчиков, который в свою очередь говорит со старшим группы, обращающимся наконец к программистам. Шансы на то, что даже простой документ с требованиями останется после этого процесса невредимым, равны нулю. Единственным решением этой проблемы является тесное вовлечение пользователей в процесс разработки, лучше всего путем включения по крайней мере одного конечного пользователя в команду разработчиков. Родственная ситуация складывается в случае простой самонадеянности части программистов, которые говорят: «Я знаю, что пользователи сказали, что им нужно сделать это таким-то способом, но у них нет достаточных знаний о компьютерах, чтобы принять сознательное решение; мой способ лучше». Такое отношение фактически гарантирует, что программой никогда не будут пользоваться. Исправить ситуацию здесь можно, официально назначив конечного пользователя лицом, оценивающим качество проекта. Никто не может начать писать код до тех пор, пока пользователь-член команды не даст на это добро. Сотрудники, игнорирующие проект в пользу своих идей, должны быть уволены. В реальной жизни для подобного типа детского упрямства на самом деле нет места. При этом нужно сказать, что опытный проектировщик зачастую предлагает лучшее решение проблемы, чем придуманное конечным пользователем, в особенности, если учесть, что конечные пользователи часто предлагают интерфейсы, созданные по образцу прoграмм, которыми они постоянно пользуются. Несмотря на это, до начала реализации вы должны убедить пользоваться в том, что ваш способ лучше. «Лучший» интерфейс не является лучшим, если никто, кроме вас, не сможет (или не захочет) им пользоваться. |