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

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

Корректное завершение не может быть бесконечным ожиданием потока.

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

Протестировать программу с количеством потоков, превышающим число процессоров.

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

Сначала отлаживать основной код.

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

Убедиться, что сам код работает вне многопоточного контекста, созданием POJO-объектов, вызываемых из потоков.

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

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

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

JVM не гарантирует вытесняющей многопоточности.

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

Заставить поток исполняться по разным путям в тесте методами object. wait (), object.sleep (), object. yield (), object.priority () – инструментовка кода.

Автоматическая инструментовка с использованием Aspect-Oriented Framework, CGLIB, ASM, ConTest.

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

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

Типичные источники многопоточных ошибок: работа с общими данными из нескольких потоков, использование пула общих ресурсов.

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

Программирование ближе к ремеслу, чем к науке.

Спасать положение нужно именно сейчас.

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

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

Множество разных типов со сходными методами – причина выделить класс.

TDD: не вносить в систему изменения, нарушающие работоспособность системы.

Добавление теста или класса ничего не нарушит.

Удалять бесполезные функциии.

Тесты всегда должны хотя бы запускаться.

Прочитать последовательное очищение.

Переработка кода напоминает кубик Рубика.

Важный аспект хорошей архитектуры – логическое разбиение кода.

Плохой код тянет группу ко дну.

Открытый код требует смелости и доброй воли.

Полезные высказывания из книги «Отладка приложений для Microsoft. Net» Джона Роббинса

В разделе приведены цитаты из [4].

Большинство команд тратит в среднем 50% цикла разработки на отладку.

Отладка требует специального обучения.

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

Книги по программированию бывают посвящены менеджменту и технологиям.

Основные программы отладки. NET: VisualStudio и WinDBG.

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

[e-mail] – автор.

Ошибки помогают понять работу вещей.

Ошибки в ПО могут привести к смене работы.

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

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

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

Windows Error Reporting.

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

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

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

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

Тестировать приложения по сценариям, наиболее точно отражающим реальный мир.

Наборы данных из реального мира брать у клиентов.

Реальные данные должны быть модифицированы – удалена конфиденциальная информация.

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

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

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

Интерфейс приложения не должен противоречить интерфейсу среды.

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

«Designing web usability: the practice of simplicity» Якоб Нильсен.

«Don’t make me think! A common sense approach to web usability» Стивен Круг.

cnn.com – лучший пример дизайна.

joelonsoftware.com/articles.

Все члены команды должны посещать клиентов и наблюдать за использованием ПО.

Никогда не обещать того, чего не сможете дать, и всегда реализовывать обещанное.

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

Учитывать время на обучение, необходимое для того, чтобы реализовать какую-либо функцию.

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

Перед написанием кода хорошенько подумать об архитектуре.

Продумать все «что, если».

Определить все риски проекта.

Члены команды не должны отдавать контроль над конструированием системы не умеющим это делать людям.

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

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

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

Чем больше деталей будет обнаружено в ПО и продумано до начала кодирования, тем меньше будет ошибок.

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

Коридорное тестирование.

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

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

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

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

Лучший способ узнать что-то о технологии – сделать что-либо с применением этой технологии.

Все, о чем в действительности заботится ваш менеджер, – это возможность ежедневно сообщать своему боссу, чем вы занимаетесь день за днем.

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

Компании и люди с реальной приверженностью качеству демонстрируют множество общих черт: тщательное предварительное планирование, личную ответственность, жесткий контроль качества и отличные коммуникационные навыки.

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

Проводить ревизии эффективности работы ежемесячно.

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

«Software reliability: measurement, prediction, application» Джон Мьюз.

В среднем коде содержится одна ошибка на каждые 10 строк.

«Code complete» МакКоннелл.

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

Ускорять отладку и тестирование на этапе планирования.

Хороший отладчик = хороший разработчик.

Самая важная черта отладчика – интуиция.

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

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

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

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

Писать утилиты.

Показывать свой код интервьюерам – сразу попадаем в первые 20%.

Изучение кода других инженеров и добавление новых функций – хорошая практика.

Читать код framework.

Друзья и коллеги-инженеры – лучшие источники знаний о разработке и отладке.

Подход к отладке:

Воспроизведите ошибку.

Опишите ошибку.

Всегда предполагайте, что это ваша ошибка.

Разделяйте и властвуйте.

Думайте творчески.

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

Начните тяжелую отладку.

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

Извлеките урок и поделитесь им с другими.

Полезные высказывания из книги «Надежный код» Бруно

В разделе приведены цитаты из [5].

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

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

Разработка ПО – это не инженерия.

Настройка производительности и безопасности не должна откладываться на конец проекта.

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

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

Нереалистично тестировать ПО в конце цикла разработки.

agilealliance.org.

agilemanifesto.org/principles.html.

Сейчас используются Scrum (наиболее широко применяется в Microsoft), XP, TDD.

blogs.msdn.com/e7.

Шаги разработки:

– сбор сведений от заказчика, совместное обсуждение требований, детальное тестирование, описание параметров компонентов и общей архитектуры системы;

– процедуры контроля качества кода – стандарты, совместная разработка, оптимизация, модульное тестирование;

– обширное тестирование системы и сборки.

Методы контроля качества применять как можно раньше.

Чем больше кода написано, тем сложнее его тестировать.

Стремиться и сосредоточиться на качестве, надежности, безопасности.

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

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

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

Отказаться от модели водопада.

Создавать проверяемые модули.

Ежедневно запускать сборку и запускать автоматические BVT-тесты.

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

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

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

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

Факторы масштабирования – часть дизайна приложения.

Безопасность закладывается в дизайне приложения.

Тестеры гарантируют полное покрытие кода тестами.

Учиться эффективно управлять памятью.

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

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

Цикл разработки ПО:

– анализ требований;

– проектирование;

– спецификации;

– программирование;

– тестирование;

– развертывание;

– обслуживание.

Написанию кода обязательно должен предшествовать этап проектирования.

Дизайн приложения в идеале не зависит от особенностей реализации.

В ООП 40—50% времени разработчик тратит на проектирование кода.

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

Секрет успеха заключается в неизменности цели.

На устранение проблемы на этапе тестирования требуется в 4 раза больше времени, чем на этапе проектирования.

C# – прямой потомок C++.

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

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

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

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

Типы UML-схем см. в книге.

Изоляция классов друг от друга – один из принципов ООП.

В конструкторе классов VS изменения в схеме классов немедленно отражаются в коде и наоборот.

Один из способов повысить гибкость кода – писать его как можно меньше.

Метаданные хранить в xml-файлах конфигурации в корневом каталоге приложения (не использовать ini и реестр).

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

Настройки, применимые ко всем приложениям на данном компьютере, хранятся в machine.config.

Храните в метаданных настройки приложения.

Храните в метаданных данные приложения.

Управляйте поведением приложения при помощи метаданных.

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

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

Использовать сжатие данных, передаваемых по сети.

Не использовать множество маленьких статических избражений.

Стандарт HTTP/1.1 предполагает одновременную загрузку браузером только двух ресурсов с одного имени хоста (новые браузеры игнорируют это требование).

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

Примечания

1

Запрещён на территории РФ.