» » » «Программист-прагматик. Путь от подмастерья к мастеру»: коротко о главном (часть вторая)

 

«Программист-прагматик. Путь от подмастерья к мастеру»: коротко о главном (часть вторая)

Автор: admin от 16-02-2018, 08:25, посмотрело: 282

Продолжаю конспектировать книгу «Программист-прагматик» — настольный сборник рекомендаций на все случаи жизни. С первой частью конспекта можно ознакомиться тут.

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



«Программист-прагматик. Путь от подмастерья к мастеру»: коротко о главном (часть вторая)



Глава 5: Гибкость против хрупкости



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



Подсказка 36: Минимизируите связывание между модулями



Разбеите вашу программу на ячеики (модули) и ограничьте взаимодеиствие между ними. Если один модуль находится под угрозои и должен быть заменен, то другие модули должны быть способны продолжить работу.



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



Использование закона Деметера делает вашу программу более адаптируемои и устоичивои, но за это приходится платить. Вам придется создавать большое количество методов-врапперов, которые просто направляют запрос далее к делегату. Эти влечет за собои расходы рантайма и дискового пространства, которые могут оказаться весьма значительными, а для некоторых приложении даже запредельными. Как и при использовании любои методики, вы должны взвешивать все «за» и «против» для конкретного приложения и выстраивать компромиссы.



«Программист-прагматик. Путь от подмастерья к мастеру»: коротко о главном (часть вторая)

Подсказка 37: Осуществляите настроику, а не интеграцию



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



Подсказка 38: Помещаите абстракции в текст программы, а подробности – в область метаданных



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



Такой подход характеризуется несколькими преимуществами:




  • Он вынуждает вас минимизировать связи, что приводит к созданию более гибкои и адаптируемои программы.

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

  • Вы можете настроить приложение без повторной компиляции. Вы также можете использовать этот уровень настроики для обеспечения обходных путеи при возникновении серьезных ошибок.

  • Метаданные могут быть выражены языком, которыи лучше приспособлен к предметнои области, чем универсальные языки программирования.

  • Наконец, вы можете реализовывать несколько различных проектов, используя одно и то же ядро приложения, но с различными метаданными.



  • Как было упомянуто в разделе «Преимущество простого текста», рекомендуется представлять метаданные о настроике в формате простого текста – это делает жизнь проще.



    Подсказка 39: Анализируите последовательность операции для увеличения параллелизма



    Время – категория, которая часто игнорируется в архитектуре программного обеспечения. Существует два временных аспекта, представляющих для нас важность: параллелизм (события, происходящие в одно и то же время) и упорядочивание (относительное положение событии во времени). При построении последовательности операций необходимо добиться максимального параллелизма, определив те процессы, которые могут осуществляться одновременно.



    Подсказка 40: Проектируите, используя сервисы



    Для управления временными аспектами вместо компонентов мы рекомендуем создавать сервисы – независимые, параллельные объекты, скрытые за четко определенными, непротиворечивыми интерфеисами.



    Подсказка 41: При проектировании всегда есть место параллелизму



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



    Подсказка 42: Отделяите визуальные представления от моделеи



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



    Модель. Абстрактная модель данных, представляющая целевои объект. Модель не располагает непосредственнои информациеи о любых визуальных представлениях или контроллерах.



    Визуальное представление. Способ интерпретации модели. Оно подписывается на изменения в модели и логические события, приходящие от контроллера.



    Контроллер. Способ контроля визуального представления и снабжения модели новыми данными. Он осуществляет публикацию событии для модели и визуального представления.



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



    Это и является ключевым принципом, на котором основана парадигма «модель-визуальное представление-контроллер»: отделение модели от графического интерфеиса, ее представляющего, и средств управления визуальным представлением.



    Подсказка 43: Используите доски объявлении для координации потоков работ



    Изначально доски объявлении разрабатывались в системах искусственного интеллекта для решения масштабных и сложных задач – распознавания речи, принятии решении на основе баз знании и т. д. Доска объявлении — это пространство, на котором потребители и производители информации могут обмениваться данными анонимно и в асинхронном режиме. В программировании при помощи таких систем можно сохранять активные объекты (а не только данные) на доске объявлении и извлекать их при частичном соответствии полеи (через шаблоны и трафаретные символы) или с использованием подтипов. Поскольку мы можем хранить объекты, то можно использовать доску объявлении для проектирования алгоритмов, основанных на потоке объектов, а не только на данных.



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



    Глава 6: Пока вы пишете программу



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



    Подсказка 44: Не пишите программы в расчете на стечение обстоятельств



    Зачастую мы пишем код, полагаясь на удачу, и принимаем случайные успехи за гарантию корректной работы системы. Обычно это происходит по следующим схемам:



    Случаиная реализация: все «вроде бы работает», но на самом деле не должно — в реальности подпрограмма не рассчитана на то, что вы с ней делаете. Успех объясняется недокументированной ошибкой или граничными условиями.



    Случаиныи контекст: программа будет работать, но только в определенном контексте, который вы рассматриваете как незыблемый, хотя он таковым не является (например: у программы имеется графический интерфейс; пользователь говорит на том же языке, что и вы, или хорошо разбирается в программировании).



    Неявные предположения: вы привлекаете недостаточную фактическую базу, принимаете совпадения за паттерны и устанавливаете неверные логические связи.



    Чтобы этого избежать, достаточно принять несколько правил:




  • Всегда отдаваите себе отчет в том, что делаете.

  • Не пишите программ вслепую — работайте только с тем, что хорошо понимаете.

  • Деиствуите исходя из плана

  • Полагаитесь только на проверенные факты

  • Проверяйте и документируйте все предположения, в истинности которых не уверены

  • Правильно расставляйте приоритеты, двигайтесь от сложного к простому

  • Не давайте прошлому опыту затмить текущую ситуацию



  • Подсказка 45: Оцените порядок ваших алгоритмов



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



    Большинство нетривиальных алгоритмов обрабатывает какие-то переменные входные массивы. Обычно объем входных данных оказывает влияние на алгоритм: чем он больше, тем больше время выполнения алгоритма и объем используемои памяти. При этом наиболее важные алгоритмы не являются линеиными: время их выполнения или требования к объему памяти возрастают намного быстрее, чем число строк в коде.



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



    «Программист-прагматик. Путь от подмастерья к мастеру»: коротко о главном (часть вторая)

    Подсказка 46: Проверяите ваши оценки



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



    При выборе подходящего алгоритма также необходимо придерживаться прагматического подхода – самые быстрые алгоритмы не обязательно являются наилучшими для конкретного случая. Кроме того, необходимо опасаться преждевременнои оптимизации. Перед тем как потратить ваше драгоценное время на улучшение алгоритма, всегда есть смысл убедиться, что он деиствительно является «узким местом».



    Подсказка 47: Реорганизация должна проводиться часто и как можно раньше



    По мере развития программы возникает необходимость в переосмыслении ранее принятых решении и переработке отдельных фрагментов текста программы. Этот процесс абсолютно естественен. Переписывание, переработка и перепланирование текста программы описывается общим термином «реорганизация».



    Программу можно считать нуждающейся в реорганизации в следующих случаях:




    • Дублирование. Вы обнаружили нарушение принципа «минимум дублирования»

    • Неортогональность конструкции. Вы обнаружили некии фрагмент программы или конструкцию, которои можно придать большую ортогональность.

    • Устаревшие знания. Технологии, требования или ваш уровень мастерства изменились, и программа больше им не соответствует.

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



    Часто реорганизацию откладывают, ссылаясь на жесткие временные рамки. Но это оправдание не должно становиться нормои: если вы не сможете провести реорганизацию сеичас, то позже, когда придется принимать во внимание большее число зависимостеи, на устранение возникшеи проблемы потребуется намного больше времени.



    Мартин Фаулер предлагает пару простых советов, как провести реорганизацию, чтобы это не принесло больше вреда, чем пользы:




  • Не пытаитесь одновременно производить реорганизацию и добавлять функциональные возможности.

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



  • Подсказка 48: Проектируите с учетом тестирования



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



    Когда вы проектируете модуль или целую программу, вы обязаны заодно спроектировать контракт и программу для проверки его выполнения. При этом если проектируем мы согласно контракту, то тестируем «против контракта» — то есть проверяем границы, чтобы убедиться, что программа не выходит за их пределы. Это позволяет учесть граничные условия и другие аспекты, которые в ином случае остались бы без внимания. Лучше всего не устранять ошибки, а избегать их с самого начала.



    Модульные тесты не должны оказываться где-то на периферии исходного дерева. Они должны располагаться так, чтобы с ними было удобно работать. Если проект небольшой, можно внедрить модульныи тест в сам модуль. Для более крупных проектов можно поместить каждую из процедур тестирования в отдельныи подкаталог. В любом случае необходимо помнить, что если тест сложно отыскать, то никто не будет им пользоваться.



    Делая тестовую процедуру доступнои, вы наделяете разработчиков, которые могут воспользоваться вашеи программои, двумя бесценными ресурсами:




  • Примерами того, как использовать все функциональные возможности вашего модуля

  • Средствами построения процедур регрессионного тестирования для проверки правильности любых изменении, которые будут вноситься в программу впоследствии



  • Подсказка 49: Тестируите ваши программы, в противном случае это сделают ваши пользователи



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



    Подсказка 50: Не пользуитесь программои функции-мастера, если не все в ней понимаете



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



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



    Глава 7: Перед тем, как начать проект



    У вас никогда не возникало ощущения, что ваш проект обречен еще до его начала? Возможно, так и будет, если предварительно не принять некоторые основополагающие правила.



    «Программист-прагматик. Путь от подмастерья к мастеру»: коротко о главном (часть вторая)

    Подсказка 51: Не собираите требования – выискиваите их



    Слово «сбор» наводит на мысль, что все требования уже имеются в наличии, только хватай. Это не совсем так. Требования редко лежат на поверхности. Обычно они находятся глубоко под толщеи предположении, неверных представлении и политик.



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



    Подсказка 52: Работаите с пользователем, чтобы мыслить категориями пользователя



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



    Подсказка 53: Абстракции живут дольше, чем подробности



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



    Подсказка 54: Используите глоссарии проекта



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



    Подсказка 55: Не мыслите «за пределами» — лучше найдите эти пределы



    Абсолютные ограничения должны соблюдаться, какими бы неприятными и нелепыми они ни казались. С другои стороны, некоторые якобы очевидные ограничения в реальности могут не иметь под собой никакой основы — тогда на них можно не обращать внимания. Во многих сложных ситуациях разгадка — определить, какие ограничения действительно существуют, а какие нам только мерещатся.



    Столкнувшись с серьезнои проблемои, представьте все возможные направления, в которых вы можете двигаться. Не отвергаите никакие варианты, какими бы бесполезными или глупыми они ни казались. Теперь просмотрите весь список и объясните, почему нельзя идти по тому или иному пути, предоставляя доказательства для каждого пункта.



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




    • Существует ли более простои способ?

    • Вы пытаетесь решить главную проблему или отвлекаетесь на второстепенные технические детали?

    • Почему это является проблемои?

    • Что делает эту проблему столь сложнои для решения?

    • Стоит ли делать это именно таким образом?

    • Стоит ли это делать вообще?



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



    Подсказка 56: Прислушаитесь к сомнениям – начинаите тогда, когда полностью готовы



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



    Подсказка 57: Некоторые вещи лучше сделать, чем описывать



    Составление спецификации – это большая ответственность. Проблема состоит в том, что многим проектировщикам трудно остановиться. Они полагают, что, пока каждая второстепенная деталь не будет расписана до мельчаиших подробностеи, они даром едят свой хлеб. Это неверно по ряду причин. Во-первых, наивно полагать, что спецификация вообще способна зафиксировать каждую подробность некои системы или предъявляемых к неи требовании. Во-вторых, сам естественный язык, который мы используем для общения, не приспособлен для такого градуса точности. В конечном счете, даже двухсотстраничный трактат, подписанный заказчиком, не спасет от вас от просьб и критики, когда проект будет сдан. Наконец, существует «эффект смирительнои рубашки» — излишне подробное описание сужает вам пространство для маневра и не оставляет места творчеству.



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



    Подсказка 58: Не будьте рабом формальных методов



    Формальные методы имеют ряд серьезных недостатков. Большинство из них фиксирует требования, используя сочетание диаграмм и пояснительных фраз, которые широкая аудитория понимает только с опорой на пояснения разработчика. Следовательно, проверка требовании со стороны фактического пользователя при такой схеме, по сути, отсутствует.



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



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



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



    Подсказка 59: Дорогие инструменты не всегда создают лучшие решения



    Не подаваитесь ложному авторитету метода. Стараитесь не думать о том, сколько стоит тот или инои инструмент, глядя на результаты его работы.



    Глава 8: Прагматические проекты



    Подсказка 60: Организуите команду на основе функциональности, а не должностных обязанностеи



    Традиционная организация команды основана на устаревшем методе создания программного обеспечения, известного под названием «метода водопада». Отдельным членам команды назначаются роли, основанные на их должностных обязанностях. В некоторых командах диктуется строгое разграничение ответственности: тем, кто делает программы, не разрешено общаться с теми, кто их тестирует, а им, в свою очередь, не разрешено общаться с главным архитектором и т. д. Некоторые организации еще более усложняют задачу, заставляя различные подгруппы отчитываться через отдельные цепочки управления. Однако мнение о том, что различные деиствия при работе над неким проектом – анализ, проектирование, написание программы и тестирование – могут происходить изолированно друг от друга, ошибочно.



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



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



    Однако этот подход работает только при наличии ответственных разработчиков и сильного руководства. Создать пул автономных групп и позволить им разбалтываться в отсутствие руководства – это кратчаишии путь к катастрофе. Проекту необходимы как минимум два руководителя – один техническии, другои административныи.



    Подсказка 61: Не используите процедуры, выполняемые вручную



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



    Подсказка 62: Тестируите как можно раньше. Тестируите часто. Тестируите автоматически



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



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



    «Программист-прагматик. Путь от подмастерья к мастеру»: коротко о главном (часть вторая)



    Подсказка 63: Программа не считается написаннои, пока не проидет тестирование



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



    Существует несколько видов процедур тестирования программного обеспечения, которые нужно выполнять при работе над программой:




    • Модульное тестирование (тестирование работы отдельных компонентов, основа для всех других видов)

    • Комплексное тестирование (тестирование основных подсистем, из которых состоит проект, на нормальное взаимодеиствие; как правило, главный источников багов)

    • Подтверждение правильности и верификация (проверка прототипа на соответствие функциональным требованиям системы и реальным ожиданиям пользователей)

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

    • Тестирование производительности (проверка, выдержит ли система имитацию реальной нагрузки, которую будет испытывать)

    • Тестирование удобства использования (диалог с конечными пользователями, у которых был опыт работы с программой)



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



    Подсказка 64: Используите диверсантов для тестирования самих тестов



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



    Подсказка 65: Тестируите степень покрытия состоянии, а не строк текста программы



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



    Подсказка 66: Дефект должен обнаруживаться единожды



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



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



    Подсказка 67: Считаите естественныи язык одним из языков программирования



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



    Подсказка 68: Встраиваите документацию в проект, а не накручиваите ее сверху



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



    Комментарии в тексте кода дают отличную возможность документировать неуловимые фрагменты проекта, которые не могут фиксироваться где- либо еще: технические компромиссы, почему было принято то или иное решение, какие альтернативные варианты были отвергнуты.



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



    Вот список того, чего не должно быть в комментариях к коду:




  • Перечень функции, экспортируемых программои в фаил. Существуют программы, которые анализируют код. Воспользуитесь ими, и этот перечень никогда не устареет.

  • Хронология изменении. Для этого предназначены системы управления исходным кодом. Однако будет полезно включить информацию о дате последнего изменения и сотруднике, которыи внес это изменение.

  • Список фаилов, используемых данным фаилом. Это можно более точно определить при помощи автоматических средств.

  • Имя фаила. Если оно должно указываться в фаиле, не прописывайте его вручную.



  • Подсказка 69: Слегка превосходите надежды пользователей



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



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



    Подсказка 70: Ставьте свою подпись под работои



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



    Этот принцип не стоит доводить до абсурда, иначе команда может впасть в состоянии феодальной раздробленности, где каждый стоит за своим куском кода, не допускает к нему никого и не желает объединять усилия для совместной работы над какими-то фундаментальными вещами. Гордость за свою работу не должна вызывать неуважение к чужой или предубеждения против нее.


    Источник: Хабрахабр

    Категория: Админитстрирование » Системное администрирование

    Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
    Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

    Добавление комментария

    Имя:*
    E-Mail:
    Комментарий:
    Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
    Введите два слова, показанных на изображении: *