пятница, 15 мая 2015 г.

Книжная полка. Джоэл Спольски "Джоэл о программировании"

Благодаря акции books.ru "Книги по свободной цене" в апреле прошлого года, я пополнил Книжную полку тремя классическими книгами по программированию, управлению и дизайну. Часть первая обзоров Books.ru - книга Джоэла Спольски "Джоэл о программировании и разнообразных и иногда родственных вопросах, которые должны быть интересны разработчикам  программного обеспечения, проектировщикам и менеджерам, а также тем, кому посчастливилось или не повезло в каком- то качестве работать с ними".


Технико-тактические характеристики:
Год издания: 2008 (Символ)
Страниц: 352
Скорость чтения - выше среднего
Время на прочтение:  6-8 часов
Полезность - высокая

Книга представляет собой сборник статей-эссе, опубликованных Джоэлом Спольски на своем сайте в 2000-2003 годах. Статьи разнообразные, от исследований программиста по вопросу оптимизации памяти в С и С++, до размышлений Джоэла на тему стратегии развития компании. Статьи-главы книги имеют взаимосвязь, но можно приступать к чтению с любой части, главы без опасения упустить цепочку рассуждений. Но я рекомендую читать ее от начала до конца любому, даже не техническому специалисту, потому что чистых технических тонкостей и примеров кода немного, в ней нет листингов программ на целые страницы, зато есть куча полезных вещей для любого ИТ-специалиста: программиста, тестировщика, менеджера, бизнес-аналитика.

Некоторые вещи, описанные Джоэлом, например, ежедневная сборка, автоматический отчет о баге у пользователя, создание прототипов на бумаге - сейчас относятся к "best practices" создания ПО, о которых должен знать тестировщик, претендующий хотя бы на уровень Senior, не говоря уже выше.

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

Книга разбита на 3 части. Строгого деления между частями нет, они связаны между собой. К каждой из частей я прикрепляю ценные мысли и идеи, высказанные автором, с своими замечаниями с точки зрения тестирования (курсивом):
  1. Биты и байты: практика программирования. Самая техническая часть.
    • по возможности избегайте "Алгоритмов маляра Шлемиля" с нелинейной сложностью (пример со строками в разных языках программирования).
      Для находжения таких "алгоритмов" тестировщики используют граничные значения, очень большие входные данные, нагрузочное тестирование.
    • "Тест Джоэла: 12 приемов написания лучшего кода".
      Актуальные вопросы и с точки зрения тестирования. Проверьте, на какие из вопросов по вашему проекту вы ответили "да". Ответы "нет" - потенциальные области для улучшений.
    • "Отсутствие спецификации – это самый крупный и совершенно ненужный риск, который вы берете на себя, принимаясь за программный проект"
    • 3 правила составления спецификации: Пишите занимательно, Спецификация должна напоминать код, предназначенный для выполнения мозгами; Пишите проще, Исправляйте и перечитывайте текст по нескольку раз, Шаблоны бывают вредны
    • Обязательно составляйте график работы
    • Ежедневная сборка необходима для сокращения цикла REP - «Read, Eval, Print»: для программирования - чем быстрее выполняется цикл, тем выше производительность разработчика, для работы в команде - чтобы сократить цикл между регистрацией ошибки и повторным тестированием.
    • "Исправлять ошибки необходимо только тогда, когда сохранение ошибки обходится дороже, чем ее исправление."
      Звучит как памятка для тестировщика-перфекциониста и взгляд "с другой стороны баррикад". Но при этом автор справедливо говорит, что "в большинстве случаев исправление ошибок экономически оправданно. Но иногда можно получить более высокую прибыль иными способами, не занимаясь тотальным истреблением ошибок."
    • "Существуют разные сферы разработки программ, и в каждой из них действуют свои законы: коробочные продукты, внутрифирменное ПО, встроенное ПО, игры. одноразовые программы".
      Соответственно, стратегии тестирования программ из разных сфер будут различными. Но даже и для двух, например, игр, стратегии тоже будут отличаться, хотя и иметь общего больше, чем с тестированием встроенного ПО.
    • "Не дайте астронавтам от архитектуры запугать себя. Помните, что эти архитекторы решают те проблемы, которые, как им кажется, они могут решить, а не те проблемы, которые было бы полезно решить. Лучше расскажите мне,
      что я теперь смогу сделать нового, чего не мог сделать раньше."
      Памятка тестировщику: не бойтесь сложных архитектурных терминов, а задавайте вопросы, какую именно задачу решает данная архитектура. Это вам позволит понять проблему и лучше вникнуть, какие возможные уязвимости есть у данного решения.
    • Путь к продуктивности - "огонь и движение: Если вы не движетесь, то развитие
      событий станет определять противник, а это нехорошо. Если вы не ведете
      огонь, противник станет вести огонь по вам и уложит вас."
      Ежедневно тестируйте, продвигайтесь вперед, и совершенствуйте ваши "инструменты огня".
    • "Иногда исправление 1 процента неисправностей требует 500 процентов усилий." Иногда и тестирование 1 строки исправлений может потребовать большого объема регрессионного тестирования.
  2. Руководство разработчиками. Менеджерская часть.
    • "Как же определить, что этого человека надо принять? В принципе просто. Искать надо тех, кто: 1. Умен. 2. Доводит дело до конца."
    • Типичный план собеседования с программистом:
      1. Знакомство.
      2. Вопрос о последнем проекте, над которым работал кандидат.
      3. Вопрос, не имеющий ответа.
      4. Вопрос о программировании.
      5. Вы удовлетворены?
      6. У вас есть вопросы?
      Меняем программирование на тестирование, и план тот же.
    • "Советую избегать всеми силами разных оценок продуктивности, поощрительных премий и дурацких конкурсов на лучшего работника месяца."
      Глава про то, почему не работает система "если-то" в творческих коллективах, к которым относится любая проектная команда. Основной посыл книги Дэниела Пинка "Драйв", о которой я уже писал.
    • "То, чего делать нельзя - Они решили переписать весь код заново."
      Относится и к тестированию. Да, есть соблазн выкинуть старые тест-кейсы, чек-листы и написать новые. Но выкидывая старые тесты, мы рискуем потерять знания об ошибках программы, которые мы вносили в тест-кейсы. С точки зрения процесса, тоже легко сказать, что давайте делать теперь вот так, не вникнув, почему именно так раньше был построен процесс тестирования. У коренных изменений больше шансов "прорасти" (и то не факт), если вы сумели доказать неэффективность старого подхода и оценить, что новый подход будет лучше. Не попадайте в ловушку "Читать код труднее, чем писать его."
    •  "Программное обеспечение обычно похоже на айсберг: в нем есть милый интерфейс пользователя, который требует процентов 10%, а 90% программистского труда скрыто от глаз."
      Тестируем не только верхушку айсберга, но и то, что "под кулисами". В частности, пирамида автоматизации поможет с составлением автотестов для нижней части айсберга.
    •  "Если показать непрограммисту экран с интерфейсом пользователя, который на вид готов и красиво выглядит, то он решит, что программа почти готова."
      Вывод для тестировщика: не надейтесь, что одним тестированием интерфейса программа почти протестирована.
    •  "Закон дырявых абстракций означает, к сожалению, что абстракции не так сильно упрощают нашу жизнь. Единственный компетентный способ залатать дыры абстракций - выучить, как работают абстракции, и какие подробности они скрывают. Итак, абстракции экономят наше рабочее время, но не экономят учебное время."
      Способ найти дыры абстракций тот же: разобраться, как работают абстракции и какие у них могут быть проблемы.
  3. "Мысли Джоэла: случайные высказывания по не столь случайным поводам"
    • "Идиома to eat one's dog food (есть корм своей собаки) в компьютерной
      индустрии означает, что разработчик использует собственное ПО."
      Отличный классический способ тестирования.
    • "Как делать дело, если вы всего лишь рядовой. Стратегия:
      1. Просто делай
      2. Воспользуйся силой вирусного маркетинга
      3. Создай оазис качества
      4. Нейтрализуй дураков
      5. Избавься от отвлечений
      6. Стань незаменимым"
    • "1. Чтобы действительно хорошо делать некоторые вещи, нужен талант.
      2. Талант трудно масштабировать.
      3. Один из способов масштабирования таланта – предложить его носителю написать инструкции, которые должны выполнять те, у кого таланта нет.
      4. Качество получаемого продукта очень низкое."
    • "Слабые системы могут казаться вполне безопасными, пока не сломаются
      какие-нибудь смежные системы."
Вывод. Книга must-read всем тестировщикам и не только для общей ИТ-грамотностии обращения к "классике". Читается легко, не перегружена техническими деталями, затрагивает все аспекты разработки ПО. Из-за того, что это "классика" и статьям более 10 лет, некоторые вещи могут показаться слишком очевидными. Но автор аргументированно объясняет, почему он приходит к тем или иным действиям и выводам.

Комментариев нет:

Отправить комментарий