Полезные конспекты книг и авторские заметки по информационным технологиям. Без формул

Упростите вложенные if с помощью повторной проверки части условия.

Упростите вложенные if с помощью блока с выходом do{…break…} while (false);.

Преобразуйте вложенные if в набор if-then-else.

Преобразуйте вложенные if в оператор case.

Факторизуйте глубоковложенный код в отдельный метод.

Используйте более объекто-ориентированный подход.

Перепроектируйте глубоко вложенный код.

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

Методики поиска дефектов лучше применять в комбинации.

Обзор кода эффективнее тестирования.

Ошибки в требованиях или архитектуре обычно имеют более широкие следствия, чем ошибки конструирования.

Повышение качества системы снижает расходы на ее разработку.

Средняя производительность труда программистов эквивалентна 10—50 строкам кода на одного человека в день.

Устранение дефектов – самый дорогой и длительный этап разработки ПО.

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

Разработчики допускают в среднем от 1 до 3 дефектов в час при проектировании и от 5 до 8 дефектов в час при кодировании.

Каждый час инспекции кода предотвращает около 100 часов аналогичной работы (тестирования и исправления дефектов).

Поддерживайте парное программирование стандартами кодирования.

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

Не используйте парное программирование для реализации простых фрагментов.

Регулярно меняйте состав пар и назначаемые парам задачи.

Объединяйте в пару людей, предпочитающих одинаковый темп работы.

Убедитесь, что оба члена пары видят экран.

Не объединяйте в пары людей, которые не нравятся друг другу.

Не составляйте пару из людей, которые ранее не программировали в паре.

Назначьте лидера группы.

Инспектор может проанализировать за час около 500 строк.

Тестирование – самая популярная методика повышения качества.

Тестирование – средство обнаружения ошибок.

Отладка – средство поиска и устранения причин уже обнаруженных ошибок.

Тестированию, выполняемому разработчиками, следует посвящать от 8% до 25% общего времени работы над проектом.

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

Структурированное базисное тестирование – протестировать каждый оператор программы хотя бы раз.

Проверяйте код тестов.

Планируйте тестирование программы так же, как и ее разработку.

Храните тесты.

Встраивайте блочные тесты в среду тестирования.

Используйте генераторы случайных данных.

Изучите программу, над которой работаете.

Изучите собственные ошибки.

Изучите качество своего кода с точки зрения кого-то, кому придется читать его.

Изучите используемые способы решения проблем.

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

Формулируя гипотезу, используйте все имеющиеся данные.

Детализируйте тесты, приводящие к ошибке.

Проверяйте код при помощи блочных тестов.

Используйте разные инструменты.

Воспроизведите ошибку несколькими способами.

Генерируйте больше данных для формулирования большего числа гипотез.

Используйте «мозговой штурм» для построения нескольких гипотез.

Составьте список подходов, которые стоит попробовать.

Сохраните подозрительную область кода.

С подозрением относитесь к классам, которые содержали дефекты ранее.

Проверьте код, который был изменен недавно.

Расширьте подозрительный фрагмент кода.

Выполняйте интеграцию инкрементно.

Проверяйте наличие распространенных дефектов.

Обсудите проблему с кем-то другим.

Отдохните от проблемы.

Установите лимит времени для быстрой и грязной отладки.

Составьте список методик грубой силы.

Не полагайтесь на номера строк в сообщениях компилятора.

Не доверяйте сообщениям компилятора.

Не доверяйте второму сообщению компилятора.

Разделяйте программу на части.

Грамотно ищите неверно размещенные комментарии и кавычки.

Прежде чем браться за решение проблемы, поймите ее.

Подтвердите диагноз проблемы.

Расслабьтесь (не поддавайтесь соблазну сэкономить время).

Сохраняйте первоначальный исходный код.

Устраняйте проблему, а не ее симптомы.

Изменяйте код только при наличии веских оснований.

Вносите в код по одному изменению.

Добавляйте в набор тестов блочные тесты, приводящие к проявлению имеющихся дефектов.

Поищите похожие дефекты.

Выбирайте во время конструирования имена, ясно отличающиеся от других имен.

Используйте утилиты сравнения исходного кода.

Задайте в компиляторе максимально строгий уровень диагностики и устраняйте все ошибки и предупреждения.

Рассматривайте предупреждения как ошибки.

Стандартизуйте параметры компилятора в масштабе всего проекта.

Используйте утилиты расширенной проверки синтаксиса и логики.

Профилируйте код для поиска ошибок.

Даже в хорошо управляемых проектах требования изменяются на 1—4% в месяц.

Современные подходы снижают предсказуемость кодирования.

Факторинг – максимальная декомпозиция программы на составляющие части.

Причины выполнения рефакторинга:

Код повторяется.

Метод слишком велик.

Цикл слишком велик или слишком глубоко вложен в другие циклы.

Класс имеет плохую связность.

Интерфейс класса не формирует согласованную абстракцию.

Метод принимает слишком много параметров.

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

При изменении программы требуется параллельно изменять несколько классов.

Вам приходится параллельно изменять несколько иерархий наследования.

Вам приходится параллельно изменять несколько блоков case.

Родственные элементы данных, используемые вместе, не организованы в классы.

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

Элементарный тип данных перегружен.

Класс имеет слишком ограниченную функциональность.

По цепи методов передаются бродячие данные.

Объект-посредник ничего не делает.

Один класс слишком много знает о другом классе.

Метод имеет неудачное имя.

Данные-члены сделаны открытыми.

Подкласс использует только малую долю методов своих предков.

Сложный код объясняется при помощи комментариев.

Код содержит глобальные переменные.

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

Программа содержит код, который может когда-нибудь понадобиться.

Рефакторинги на уровне данных:

Замена магического числа на именованную константу.

Присвоение переменной более ясного или информативного имени.

Встраивание выражения в код.

Замена выражения на вызов метода.

Введение промежуточной переменной.

Преобразование многоцелевой переменной в несколько одноцелевых переменных.

Использование локальной переменной вместо параметра.

Преобразование элементарного типа данных в класс.

Преобразование набора кодов в класс или перечисление.

Преобразование набора кодов в класс, имеющий производные классы.

Преобразование массива в класс.

Инкапсуляция набора.

Замена традиционной записи на класс данных.

Рефакторинги на уровне отдельных операторов:

Декомпозиция логического выражения.

Вынесение сложного логического выражения в грамотно названную булеву функцию.

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

Использование оператора break или return вместо управляющей переменной цикла.

Возврат из метода сразу после получения ответа вместо установки возвращаемого значения внутри вложенных операторов if-then-else.

Замена условных операторов (обычно многочисленных блоков case) на вызов полиморфного метода.

Создание и использование «пустых» объектов вместо того, чтобы проверять, равно ли значение null.

Извлечение метода из другого метода.

Встраивание кода метода.

Преобразование объемного метода в класс.

Замена сложного алгоритма на простой.

Добавление параметра.

Удаление параметра.

Отделение операций запроса данных от операций изменения данных.

Объединение похожих методов путем их параметризации.

Разделение метода, поведение которого зависит от полученных параметров.

Передача в метод целого объекта вместо отдельных полей.

Передача в метод отдельных полей вместо целого объекта.

Инкапсуляция нисходящего приведения типов.

Рефакторинги реализации классов:

Замена объектов-значений на объекты-ссылки.

Замена объектов-ссылок на объекты-значения.

Замена виртуальных методов на инициализацию данных.

Изменение положения методов-членов или данных-членов в иерархии наследования.

Перемещение специализированного кода в подкласс.

Объединение похожего кода и его перемещение в суперкласс.

Рефакторинги интерфейсов классов:

Перемещение метода в другой класс.

Разделение одного класса на несколько.

Удаление класса.

Сокрытие делегата.

Удаление посредника.

Замена наследования на делегирование.

Замена делегирования на наследование.

Создание внешнего метода.

Создание класса-расширения.

Инкапсуляция открытой переменной-члена.

Удаление методов установки значений неизменяемых полей.

Сокрытие методов, которые не следует вызывать извне класса.

Инкапсуляция неиспользуемых методов.

Объединение суперкласса и подкласса, имеющих очень похожую реализацию.

Рефакторинг на уровне системы:

Создание эталонного источника данных, которые вы не можете контролировать.

Изменение однонаправленной связи между классами на двунаправленную.

Изменение двунаправленной связи между классами на однонаправленную.

Предоставление фабричного метода вместо простого конструктора.

Замена кодов ошибок на исключения или наоборот.

Сохраняйте первоначальный код.

Стремитесь ограничить объем отдельных видов рефакторинга.

Выполняйте отдельные виды рефакторинга по одному за раз.

Составьте список действий, которые вы собираетесь предпринять.

Составьте и поддерживайте список видов рефакторинга, которые следует выполнить позже.

Часто создавайте контрольные точки.

Используйте предупреждения компилятора.

Выполняйте регрессивное тестирование.

Создавайте дополнительные тесты.

Выполняйте обзоры изменений.

Изменяйте подход в зависимости от рискованности рефакторинга.

Не рассматривайте рефакторинг как оправдание написания плохого кода с намерением исправить его позднее.

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

Тратьте время на 20% видов рефакторинга, обеспечивающих 80% выгоды.

Выполняйте рефакторинг при создании новых методов.

Выполняйте рефакторинги при создании новых классов.

Выполняйте рефакторинг при исправлении дефектов.

Выполняйте рефакторинг модулей, подверженных ошибкам.

Выполняйте рефакторинг сложных модулей.

При сопровождении программы улучшайте фрагменты, к которым прикасаетесь.

Определите интерфейс между аккуратным и безобразным кодом и переместите безобразный код на другую сторону этого интерфейса.

Простое задание явных целей повышает вероятность их достижения.

На 20% методов программы приходятся 80% времени ее выполнения.

Сокращение числа строк высокоуровневого кода не повышает быстродействие и не уменьшает объем итогового машинного кода.

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

Методики, повышающие производительность в одной среде, могут снижать ее в других.

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

Концентрация на производительности во время первоначальной разработки отвлекает от достижения других целей.

Корректность важнее быстродействия.

Частые причины снижения эффективности:

Операции ввода/вывода.

Замещение страниц памяти.

Системные вызовы.

Интерпретируемые языки.

Ошибки.

Повышение быстродействия исходит из замены дорогой операции на более дешевую.

Главная проблема оптимизации кода: результат любого отдельного вида оптимизации непредсказуем.

Замыкание цикла – принятие решения внутри цикла при каждой его интерации.

Разомкнутый цикл – принятие решения вне цикла.

Если два цикла работают с одним набором элементов, можно выполнить их объединение.

После частичного развертывания цикла при каждой его итерации обрабатывается не один случай, а два и более.

Вкладывайте более ресурсоемкий цикл в менее ресурсоемкий.

Минимизируйте число обращений к массивам.

Даже слепые белки иногда наталкиваются на орехи.

Назначьте двух человек на каждую часть проекта.

Рецензируйте каждую строку кода.

Введите процедуру подписания кода.

Распространяйте для ознакомления хорошие примеры кода.

Подчеркивайте, что код – это общее имущество.

Награждайте за хороший код.

«Я должен быть в состоянии прочесть и понять любой код, написанный в проекте».

Следуйте систематической процедуре контроля изменений.

Обрабатывайте затраты на каждое изменение.

Оценивайте затраты на каждое изменение.

Относитесь с подозрением к изменениям большого объема.

Учредите комитет контроля изменений.

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

Оценка графика конструирования:

Определите цели.

Выделите время для оценки.

Выясните требования к программе.

Делайте оценки на низком уровне детализации.

Используйте несколько способов оценки и сравнивайте полученные результаты.

Периодически делайте повторную оценку.

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

Наибольшее влияние на график программного проекта оказывает размер создаваемой программы.

Если вы отстаете:

Надеяться, что вы сможете наверстать упущенное.

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

Увеличить команду (если есть независимые задачи).

Сократить проект.

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

Причины, по которым стоит проводить измерение проекта:

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

Отдавайте себе отчет о побочных эффектах измерения.

Возражать против измерений означает утверждать, что лучше не знать о том, что на самом деле происходит.

80% работы выполняют 20% сотрудников.

Если вы хотите контролировать стиль программиста:

Вы вторгаетесь в область, требующую деликатного обращения.

Из уважения к теме используйте термины «предложения» и «советы».

Старайтесь обходить стороной спорные вопросы, предпочитая давать явные поручения.

Предложите программистам выработать собственные стандарты.

Просвещайте менеджеров.

Писать и тестировать маленькие участки программы, а затем комбинировать эти кусочки друг с другом по одному.

Преимущества этой инкрементной итерации:

Ошибки можно легко обнаружить.

В таком проекте система раньше становится работоспособной.

Вы получаете улучшенный мониторинг состояния.

Вы улучшите отношения с заказчиком.

Системные модули тестируются гораздо полнее.

Вы можете создать систему за более короткое время.

При нисходящей интеграции вы создаете те классы, которые находятся на вершине иерархии, первыми, а те, что внизу, – последними.

Систему можно разбить на вертикальные слои.

При восходящей интеграции вы пишете и интегрируете сначала классы, находящиеся внизу иерархии.

При риск-ориентированной интеграции вы решаете, какие части системы будут самыми трудными, и реализуете их первыми.

Еще один подход – интеграция одной функции в каждый момент времени.

Создавайте сборку ежедневно.

Проверяйте правильность сборок.

Выполняйте дымовые тесты ежедневно.

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

Автоматизируйте ежедневную сборку и дымовой тест.

Организуйте группу, отвечающую за сборки.

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

Требуйте, чтобы разработчики проводили дымовое тестирование своего кода перед его добавлением в систему.

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

Назначьте наказание за нарушение сборки.

Выпускайте сборки по утрам.

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

Под «непрерывной» понимается «по крайней мере, ежедневная» интеграция.

До 40% времени программист тратит на редактирование исходного кода.

Передовой набор инструментов позволяет повысить производительность более чем на 50%.

20% инструментария используются в 80% случаев.

Хорошее визуальное форматирование показывает логическую структуру программы.

Абзац кода должен содержать только взаимосвязанные операторы, выполняющие одно задание.

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

Оптимальное число пустых строк в программе – 16%.

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

Оптимальными являются отступы из 2—4 пробелов.

Формируйте блоки из 1 оператора единообразно.

В сложных выражениях размещайте каждое условие на отдельной строке.

Избегайте операторов goto.

Не используйте форматирование в конце строки в виде исключения для операторов case.

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

Используйте пробелы, чтобы сделать читаемыми обращения к массиву.

Используйте пробелы, чтобы сделать читаемыми аргументы методов.

Сделайте так, чтобы незавершенность выражения была очевидна.

Располагайте сильно связанные элементы вместе.

При переносе строк в вызове метода используйте отступ стандартного размера.

Упростите поиск конца строки с продолжением.

При переносе строк в управляющем выражении делайте отступ стандартного размера.

Не выравнивайте правые части выражений присваивания.

При переносе строк в выражениях присваивания применяйте отступы стандартного размера.

Располагайте каждое объявление данных в отдельной строке.

Объявляйте переменные рядом с местом их первого использования.

Разумно упорядочивайте объявления.

Делайте в комментации такой же отступ, как и в соответствующем ему коде.

Отделяйте каждый комментарий хотя бы одной пустой строкой.

Используйте пустые строки для разделения составных частей метода.

Используйте стандартный отступ для аргументов метода.

Если файл содержит более 1 класса, четко определяйте границы каждого класса.

Помещайте каждый класс в отдельный файл.

Называйте файл в соответствии с именем класса.

Отделяйте методы друг от друга с помощью хотя бы 2 пустых строк.

Упорядочивайте методы по алфавиту.

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

Используйте содержательные комментарии.

Избегайте комментариев, высосанных из пальца.

Не используйте комментарии в концах строк, относящиеся к нескольким строкам кода.

Используйте комментарии в концах строк для пояснения объявлений данных.

Не используйте комментарии в концах строк для вставки пометок во время сопровождения ПО.

Используйте комментарии в концах строк для обозначения концов блоков.

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

Во время документирования сосредоточьтесь на самом коде.

Придумывая комментарий абзаца, стремитесь ответить на вопрос «почему», а не «как».

Используйте комментарии для подготовки читателя кода к последующей информации.

Не размножайте комментарии без необходимости.

Документируйте сюрпризы.

Избегайте сокращений.

Проведите различие между общими и детальными комментариями.

Комментируйте все, что имеет отношение к ошибкам или недокументированным возможностям языка или среды.

Указывайте в комментариях единицы измерения численных величин.

Указывайте в комментариях диапазоны допустимых значений численных величин.

Комментируйте смысл закодированных значений.

Комментируйте ограничения входных данных.

Документируйте флаги до уровня отдельных битов.

Включайте в комментарии, относящиеся к переменной, имя переменной.

Документируйте глобальные данные.

Пишите комментарий перед каждым оператором if, блоком case, циклом или группой операторов.

Комментируйте завершение каждой управляющей структуры.

Рассматривайте комментарии в концах циклов как предупреждения о сложности кода.

Располагайте комментарии близко к описываемому ими коду.

Описывайте каждый метод одним-двумя предложениями перед началом метода.

Документируйте параметры в местах их объявления.

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

Проведите различие между входными и выходными данными.

Документируйте выраженные в интерфейсе предположения.

Комментируйте ограничения методов.

Документируйте глобальные результаты выполнения метода.

Документируйте источники используемых алгоритмов.

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

Опишите подход к проектированию класса.

Опишите ограничения класса, предположения о его использовании и так далее.

Прокомментируйте интерфейс класса.

Не документируйте в интерфейсе класса детали реализации.

Опишите назначение и содержание каждого файла.

Укажите в блочном комментарии свои имя/фамилию, адрес электронной почты и номер телефона.

Включите в файл тег версии.

Включите в блочный комментарий юридическую информацию.

Присвойте файлу имя, характеризующее его содержание.

Лучшие программисты создают программы в 10 раз быстрее коллег.

Изучите процесс разработки.

Экспериментируйте.

Читайте о решении проблем.

Анализируйте и планируйте, прежде чем действовать.

Изучайте успешные проекты.

Читайте.

Читайте другие книги и периодические издания.

Общайтесь с единомышленниками.

Постоянно стремитесь к профессиональному развитию.