Недавно начал читать блог highload++ и наткнулся на фразу "highload, это когда перестает хватать железа". Вспомнил "Стиль, разработка, эффективность, отладка и испытание программ" Ван Тассела и удивился, насколько книга 1985 года перекликается с современностью. Автор рассуждает, что 156 кб памяти должно хватить для всех необходимых операций, но оптимизация кода нужна частным машинам с меньшим объемом памяти. Так и в современном "хайлоаде" мы живем в эпоху суперкомпьютеров и квантового превосходства, но часто это не поможет при плохой реализации приложения и ограниченных мощностях в момент тестового вывода продукта. Однозначно, многие моменты посвященные фортрану или коболу не очень волнуют современных программистов, но многие идеи, касающиеся общего подхода к работе, стоит записать и периодически перечитывать. (так и появился этот конспект:)
Советы могут показаться очевиднейшими, и они в основном отражают структурный подход к программированию, но почему-то мы все до сих пор периодически о них забываем:
- Перед тем как приступать к кодированию, опишите основную задачу. Декомпозируйте её на подзадачи. Делайте так до тех пор, пока не дойдет до задач, вмещающихся в один модуль.
- Задачи модуля как правило можно описать одной фразой.
- Сначала напишите программу на естественном языке. Переписать формулировку задачи гораздо проще, чем код. Многие проблемы всплывают уже на этом этапе. Это достаточно сильно перекликается с принципом "Исполнитель понимает задачу" и применимо не только к программистам, а в принципе к управлению проектам. Ван Тассел очень много пишет о понимании задачи, это круто.
- Тестовые данные для программы нужно определить на этапе проектирования.
- Общая сложность программы складывается из 3 основных факторов:
- Функциональная сложность - количество выполняемых функций
- Распределенная - распределенность ресурсов по модулям
- Сложность связи - использование модулями общих данных
- Для уменьшения общей сложности программы, её следует разбивать на модули. Каждый модуль должен решать одну задачу, быть небольшого размера и по возможности ограничивать вход и выход данных.
- Примерная разбивка проекта по времени:
- 1 часть - проектирование
- 1 часть - написание кода
- 4 части - отладка
- 1 часть - тестирование
- При отладке, практически такую же эффективность как и автоматическое тестирование может дать "ручная" вычитка кода. От себя добавлю, что периодически замечал этот эффект. Вычитка, если код написан +- читаемо, позволяет расставить абстракции в голове в нужном порядке и начать буквально "видеть" нестыковки на глобальном уровне. А постоянное отслеживание traceback'ов наоборот захламляет и опускает на уровень "исправления приляпками".
- Затраты на отладку-тестирование больших проектов в среднем составляют 30-60% от общих затрат. Поэтому очень важно думать о тестировании еще на этапе составления спецификаций.
- Если ваша программа принимает неверные данные и падает или еще хуже, обрабатывает их и дает неверный результат, то это и ваши проблемы тоже а не только людей предоставивших неверные данные.
- Сюда же можно отнести тезис "не надейтесь на конечного пользователя, он далеко не всегда будет делать все правильно".
Книга легко читается, и с радостью могу посоветовать её всем тем, кто находится в начале пути и хочет концептуально представить работу программиста. Несмотря на огромный разрыв по времени многие моменты остались абсолютно нетронутыми) Из этого же направления подойдет "Чистый код" Р.Мартина, его интересно читать сразу после, сравнивая как изменился подход, структурную и объектно-ориентированную парадигмы. Чистому коду у меня посвящено сразу несколько постов, переходите в блог)
