Раскрутка бизнеса - создание сайтов, SEO, SMO в Киеве Голосов: 0 Адрес блога: http://grnweb.ru/ Добавлен: 2015-01-20 16:04:49

Заказчик всегда прав

2014-12-22 13:27:44 (читать в оригинале)

Заказчик всегда прав

Ни одной программе не добиться успеха, если ее проектировщики не общаются непосредственно с ее конечными пользователями. Несмотря на это, часто ситуация больше напоминает игру («испорченный телефон»), в которую многие из нас играли в детском саду, когда 20 ребятишек садятся в кружок. Кто-нибудь шепчет фразу своему соседу (соседке), который передает ее своему, и так далее по кругу. Забава заключается в том, чтобы послушать как сообщение звучит после того, как пройдет весь круг — обычно ничего похожего на исходную фразу. Тот же самый процесс зачастую встречается при разработке программ. Пользователь говорит с управляющим, докладывающим другому управляющему, который нанимает консультационную фирму. Президент консультационной фирмы разговаривает с руководителем разработчиков, который в свою очередь говорит со старшим группы, обращающимся наконец к программистам. Шансы на то, что даже простой документ с требованиями останется после этого процесса невредимым, равны нулю. Единственным решением этой проблемы является тесное вовлечение пользователей в процесс разработки, лучше всего путем включения по крайней мере одного конечного пользователя в команду разработчиков.

Родственная ситуация складывается в случае простой самонадеянности части программистов, которые говорят: «Я знаю, что пользователи сказали, что им нужно сделать это таким-то способом, но у них нет достаточных знаний о компьютерах, чтобы принять сознательное решение; мой способ лучше». Такое отношение фактически гарантирует, что программой никогда не будут пользоваться. Исправить ситуацию здесь можно, официально назначив конечного пользователя лицом, оценивающим качество проекта. Никто не может начать писать код до тех пор, пока пользователь-член команды не даст на это добро. Сотрудники, игнорирующие проект в пользу своих идей, должны быть уволены. В реальной жизни для подобного типа детского упрямства на самом деле нет места.

При этом нужно сказать, что опытный проектировщик зачастую предлагает лучшее решение проблемы, чем придуманное конечным пользователем, в особенности, если учесть, что конечные пользователи часто предлагают интерфейсы, созданные по образцу прoграмм, которыми они постоянно пользуются. Несмотря на это, до начала реализации вы должны убедить пользоваться в том, что ваш способ лучше. «Лучший» интерфейс не является лучшим, если никто, кроме вас, не сможет (или не захочет) им пользоваться.

---

Компьютерное программирование является индустрией обслуживания

2014-12-22 13:27:27 (читать в оригинале)

Компьютерное программирование является индустрией обслуживания

Меня иногда шокирует неуважение, проявляемое некоторыми программистами по отношению к пользователям своих программ, как если бы «пользователь» (произносится с презрительной усмешкой) был низшей формой жизни, неспособной к познавательной деятельности. Но факт состоит в том, что весь компьютер существует лишь с одной целью: служить конечному пользователю наших продуктов. Если никто бы не пользовался компьютерными программами, то не было бы и программистов.

Печальным фактом является то, что существенно больше половины из ежегодно разрабатываемого кода выбрасывается за ненадобностью. Такие программы или никогда не поступают в эксплуатацию, или используются лишь очень короткое время, после чего выбрасываются. Это означает невероятную потерю производительности, сокращая для большинства управленцев реальные среднесуточные цифры выработки. Подумайте о всех начинающих фирмах, выпускающих программы, которые никогда не будут проданы, о всех группах разработчиков, пишущих бухгалтерские пакеты, которыми нельзя воспользоваться.

Легко увидеть, как возникает эта печальная ситуация: программисты создают программы, которые никому не нужны. Исправить ее тоже легко, хотя в определенном окружении это и сталкивается с неожиданными трудностями: спросите людей, что им нужно, и затем сделайте то, что они вам сказали.

К сожалению, многие программисты производят впечатление лиц, полагающих, что конечные пользователи не знают чего хотят. Вздор. Почти всегда пользователи оказываются так запуганы сыплющим специальными терминами «экспертом», что замолкают. Мне часто говорили: «Я знаю, что мне нужно, но не могу это выразить». Лучший ответ на это: «Отлично, скажите это на нормальном языке — я сделаю перевод на компьютерный».

---

Проблема должна быть хорошо продумана перед тем, как она сможет быть решена

2014-12-22 13:27:13 (читать в оригинале)

Проблема должна быть хорошо продумана перед тем, как она сможет быть решена

Эти правила посвящены весьма реальным проблемам и во многих отношениях являются самыми важными правилами в этой книге.

Настоящее правило является настолько очевидным утверждением в повседневной жизни, что кажется странным его восприятие едва ли не ересью в применении к программированию. Мне часто говорят, что «невозможно потратить пять месяцев на проектирование, не написав ни одной строки, кода — ведь наша производительность измеряется числом строк кода, написанных за день». Люди, говорящее это, обычно знают, как делается хороший проект; просто они не, могут позволить себе такую «роскошь».

Мой опыт говорит, что хорошо спроектированная программа не только работает лучше (или просто работает), но и может быть написана быстрее и быть проще в сопровождении, чем плохо спроектированная. Лишние четыре месяца при проектировании могут сэкономить вам более четырех месяцев на этапе реализации и буквально годы в период сопровождения. Вы не сможете добиться высокой производительности, если приходится выбрасывать прошлогоднюю работу из-за существенных изъянов проекта.

Кроме того, скверно спроектированные программы труднее реализовать. Тот аргумент, что у вас нет времени на проектирование, потому что вы «должны захватить рынок программ как можно скорее», просто не выдерживает никакой критики, потому что реализация плохого (или никакого) проекта требует гораздо больше времени.

---

Используйте для работы соответствуюший инструмент

2014-12-22 13:26:58 (читать в оригинале)

Используйте для работы соответствуюший инструмент

Данное правило является спутником правила «Не путайте привычность с читаемостью», представленного ниже, но, скорее всего, больше касается проблем руководства. Мне часто говорят, что студентам не разрешается использовать некоторые аспекты С или С++ (обычно это указатели), потому что они «нечитабельны». Обычно это правило навязывается руководителями, знающими ФОРТРАН, БЕЙСИК или какой-то другой язык, не поддерживающий указатели, и их не очень-то заставишь изучать С. Вместо того, чтобы признать изъяны в своих знаниях, такие руководители будут предпочитать калечить своих программистов. Указатели превосходно читаются программистами на С.

И, наоборот, я видел ситуации, где руководство требовало, чтобы программисты перешли с языка программирования типа КОБОЛ на С, но не желало оплачивать переподготовку, необходимую для перехода. Или еще хуже, руководство платило за переподготовку, но не предоставляло времени, необходимого для действительного изучения материала. Переподготовка является занятием, требующим всего рабочего дня. Вы не можете одновременно выполнять «полезную» работу, а если попытаетесь, то ваши деньги будут выброшены на ветер. Так или иначе, после того, как руководители видят, что их штат не был превращен в гуру программирования на С++ после 3-дневного краткого курса, они реагируют наложением ограничений на использование некоторых компонентов языка. Фактически они говорят: «Вы не можете использовать ту часть С++, которая не похожа на язык, который мы использовали до перехода на С++». Естественно, что окажется невозможным эксплуатировать ни одну из прогрессивных особенностей языка (которые прежде всего и являются главной причиной его использования), если вы ограничите себя «простейшим» подмножеством особенностей.

Глядя на эти ограничения, мне в первую очередь интересно знать, зачем понадобилось менять КОБОЛ на С. Принуждение программистов на языке КОБОЛ использовать С всегда поражало меня своей большой глупостью. КОБОЛ — великолепный язык для работы с базами данных. У него есть встроенные примитивы, упрощающие выполнение задач, которые довольно трудны для С. С, в конце концов, был разработан для создания операционных систем, а не приложений баз данных. Довольно просто дополнить КОБОЛ, чтобы он поддерживал модный графический интерфейс пользователя, если это единственная причина перехода на С.

---

Разлагайте сложные проблемы на задачи меньшего размера

2014-12-22 13:26:45 (читать в оригинале)

Разлагайте сложные проблемы на задачи меньшего размера

На самом деле это также и правило литературного стиля. Если очень трудно объяснить точку зрения за один раз, то разбейте изложение на меньшие части и по очереди объясняйте каждую. То же самое назначение у глав в книге и параграфов в главе.

В качестве примера программирования возьмем прошитое бинарное дерево, отличающееся от нормального дерева тем что указатели на узлы-потомки в конечных узлах на листочках указывают на само дерево. Фактическим преимуществом прошитого дерева является то, что его легко просмотреть нерекурсивно при помощи этих дополнительных указателей. Проблема заключается в том, что сложно выйти из алгоритмов просмотра (в особенности при обратном просмотре). С другой стороны, имея указатель на узел, легко написать алгоритм поиска последующего элемента в обратном порядке. Путем изменения формулировки с «выполнить просмотр в обратном порядке» на «начав с самого отдаленного узла, искать последующие элементы в обратном порядке, пока они не закончатся» получаем разрешимую задачу.