Введение
В данной статье я хочу поделиться основными мыслями, которые я почерпнул из книги “Программист прагматик” (авторы Эндрю Хант, Дэвид Томас).
Книга помогла мне ответить на ряд немых внутренних вопросов, на которые раньше я не мог дать себе ответа, а также выделила и структурировала в вопросы то, что раньше самостоятельно формализовать не получалось.
Прагматическая философия
- для несостоятельных или трудных задач следует предлагать варианты решения, а не варианты отговорок
- одноразовое допущение беспорядка порождает глобальный процесс ухудшения качества кода и приложения в целом (“теория разбитого окна”)
- масштабные изменения следует предлагать небольшими шагами, вовлекая узкий круг лиц
- нужно следить за общей картиной проекта, чтобы не пропустить вялотекущих, но деструктивных изменений (“вареная лягушка”)
- решение в пользу качества почти всегда наиболее приоритетно
- портфель собственных знаний - важная инвестиционная составляющая профессии, требует регулярного пересмотра и реинвестирования
- чтобы получить ответ, вопрос нужно сформулировать максимально четко и прозрачно
- нужно учитывать способ и канал коммуникации, формировать стиль сообщения и общения так, чтобы это было удобно собеседнику и отвечало тематике общения.
Прагматичный подход
- принцип DRY является основополагающим, как непосредственно в кодовой базе, так и при хранении данных
- важна ортогональноть модулей программы (слабое зацепление, сильная связность)
- в проектировании следует учитывать, что не существует окончательных решений
- прототип программы поможет выявить скрытые проблемы и получить обратную связь от заказчика, а также стать базой для дальнейшей разработки
- программирование ближе к предметной области повышает качество кода и улучшает поддержку
- если это уместно, то можно реализовать встроенный интерпретатор для языка доменов, с которым будет работать приложение; тем самым код программы будет разделен на поддержку интерпетатора, а бизнес-логика останется скриптуемой и легко-изменяемой.
- оценка - важная составляющая договоренностей перед стартом работ.
Подходящий набор инструментов
- конфигурационные файлы должны быть максимально простыми и не являться интерпетируемыми (yml, ini, xml)
- следует выбрать и настроить один текстовый редактор, но по-максимуму
- во время отладки программы не следует тратить время на проверку “фантастических случаев”
- при поиске проблемы важно уделить внимание среде выполнения, а также внешним условиям
- если это возможно, то следует попробовать генерировать текст программы автоматически.
Прагматическая паранойя
- используется формальные способы проверки корректности программы: построение инвариантов, предусловий и постусловий
- программа должна завершиться как можно раньше (“мертвые программы не лгут”)
- если код пишется исходя из предположения, что что-либо никогда не произойдет, не следует лишний раз проверять данное условие (обременение кода)
- используемые ресурсы следует открывать и закрывать в одном контексте.
Гибкость против хрупкости
- лучше совершать настройку, а не интеграцию (с помощью метаданных программы)
- программа должна содержать абстракции, а детали - в метаданных
- следует учесть возможность параллельного выполнения ряда функций на этапе проектирования.
Пока вы пишете программу
- не стоит рассчитывать на стечение обстоятельств и удачный контекст выполнения программы
- действуйте по плану, по приоритету
- документируйте ваши предположения
- не будьте рабами прошлого
- рефакторинг следует отделять от добавления нового функционала
- проектируйте с учетом тестирования.
Перед тем, как начать проект
- требования не собирают, а выискивают
- следует вести глоссарий проекта
- при решении проблемы рассматривайте все доступные варианты (“не размышляйте вне ящика - найдите этот ящик”)
- проблему нужно пытаться решить простым способом
- важно найти баланс между сбором сведений и началом прототипирования
- следует использовать разные способы изложения информации (блок-схемы, графики, текст, списки).
Прагматические проекты
- команду следуют организовывать исходя из функциональных ролей, а не административных
- тестируйте исходя из возможных состояний программы
- дефект следует устранять
- документацию следует стараться встроить в проект
- ставьте вашу подпись под работой.