Б. Страуструп - Язык программирования С++ (1119446), страница 83

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 83)

Повторное использованиепрограммы возможно при условии, что[1]она работает; нельзя использовать повторно, если это невозможно и в первый раз;[2]она понятна; здесь имеетдокументации, руководства;[3]она может работать вместе с программами, которые не создавались специально с такимусловием;[4]можно рассчитывать на ее сопровождение (или придется делать это самому, что обычно нехочется);[5]это выгодно (хотя можно и разделить расходы по разработке и сопровождению с другимипользователями) и, наконец;[6]ее можно найти.значениеструктурапрограммы,наличиекомментариев,К этому можно еще добавить, что компонент не является повторно используемым, пока кто-тодействительно не сделал это.

Обычно задача приспособления компонента к существующемуокружению приводит к уточнению набора операций, обобщению его поведения, и повышению егоспособности адаптации к другим программам. Пока все это не проделано хотя бы один раз,неожиданные острые углы находятся даже у компонентов, которые тщательно проектировались иреализовывались.Личный опыт подсказывает, что условия для повторного использования возникают только в том случае,когда находится конкретный человек, занятый этим вопросом. В маленьких группах это обычно бываеттот, кто случайно или запланированно оказывается хранителем общих библиотек или документации. Вбольших организациях это бывает группа или отдел, которые получают привилегию собирать,документировать, популяризировать и сопровождать программное обеспечение, используемоеразличными группами.Нельзя недооценивать такие группы "стандартных компонентов". Укажем, что в первом приближении,система отражает организацию, которая ее создала.

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

Это является аргументом заиспользование такой группы в роли консультанта и в пользу внутренних поставок программ, чтобыинформация из группы компонентов могла свободно распространяться.Заметим, что не все программы должны быть рассчитаны на повторное использование, иными словами,повторное использование не является универсальным свойством. Сказать, что некоторый компонентможет быть повторно использован, означает, что в рамках определенной структуры его повторноеиспользование не потребует значительных усилий.

Но в большинстве случаев перенос в другуюструктуру может потребовать большой работы. В этом смысле повторное использование сильнонапоминает переносимость. Важно понимать, что повторное использование является результатомпроектирования, ставившего такую цель, модификации компонентов на основе опыта и специальныхусилий, предпринятых для поиска среди существующих компонентов кандидатов на повторноеиспользование. Неосознанное использование средств языка или приемов программирования не может300Бьерн Страуструп.Язык программирования С++чудесным образом гарантировать повторное использование.

Такие средства языка С++, как классы,виртуальные функции и шаблоны типа, способствуют проектированию, облегчающему повторноеиспользование (значит делают его более вероятным), но сами по себе эти средства не гарантируютповторное использование.11.4.2 РазмерЧеловек и организация склонны излишне радоваться тому, что они "действуют по правильной методе".В институтской среде это часто звучит как "развитие согласно строгим предписаниям".

В обоих случаяхздравый смысл становится первой жертвой страстного и часто искреннего желания внести улучшения. Кнесчастью, если здравого смысла не хватает, то ущерб, нанесенный неразумными действиями, можетбыть неограниченным.Вернемся к этапам процесса развития, перечисленным в $$11.3, и к шагам проектирования, указаннымв $$11.3.3. Относительно просто переработать эти этапы в точный метод проектирования, когда шагточно определен, имеет хорошо определенные входные и выходные данные и полуформальную записьдля задания входных и выходных данных.

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

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

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

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

Верный путь к неудаче, когда у такого человека или группы нет средств воздействовать на301Бьерн Страуструп.Язык программирования С++проект в целом.Отсутствие согласованных дальних целей намного более опасно для проекта и организации, чемотсутствие какого-либо одного конкретного свойства. Небольшая группа людей должнасформулировать такие общие цели, постоянно держать их в уме, составить документы, содержащиесамое общее описание проекта, составить пояснения к основным понятиям, и вообще, помогать всемостальным помнить о назначении проекта.11.4.3 Человеческий факторОписанный здесь метод проектирования рассчитан на искусных разработчиков и программистов,поэтому от их подбора зависит успех организации.Менеджеры часто забывают, что организация состоит из индивидуумов.

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

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

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

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

Характеристики

Список файлов книги