Ссылка: Программист-прагматик: от подмастерья до мастера
- Заботьтесь о своем ремесле
Зачем тратить свою жизнь на разработку программного обеспечения, если вы не заботитесь о том, чтобы делать это хорошо?
- Считать! О вашей работе
Выключите автопилот и возьмите управление в свои руки. Постоянно критикуйте и оценивайте свою работу.
- Предлагайте варианты, не придумывайте неубедительные оправдания
Вместо оправданий предлагайте варианты. Не говорите, что это невозможно; объясните что можно сделать.
- Не живите с разбитыми окнами
Исправьте плохой дизайн, неправильные решения и плохой код, когда увидите их.
- Будьте катализатором перемен
Вы не можете заставить людей измениться. Вместо этого покажите им, каким может быть будущее, и помогите им участвовать в его создании.
- Помните общую картину
Не увлекайтесь деталями настолько, чтобы забыть проверить, что происходит вокруг вас.
- Сделайте качество проблемой требований
Вовлекайте своих пользователей в определение реальных требований к качеству проекта.
- Регулярно инвестируйте в свой портфель знаний
Сделайте обучение привычкой.
- Критически анализируйте то, что вы читаете и слышите
Не поддавайтесь влиянию продавцов, шумихи в СМИ или догм. Проанализируйте информацию с точки зрения вас и вашего проекта.
- Это и то, что вы говорите, и то, как вы это говорите
Нет смысла иметь отличные идеи, если вы не доносите их эффективно.
- СУХОЙ — не повторяйся
Каждая часть знаний должна иметь единственное, недвусмысленное, авторитетное представление в системе.
- Упростите повторное использование
Если это легко повторно использовать, люди это сделают. Создайте среду, поддерживающую повторное использование.
- Устраните эффекты между несвязанными вещами
Создавайте автономные компоненты. независимы и имеют единую четко определенную цель.
- Окончательных решений нет
Ни одно решение не высечено в камне. Вместо этого рассматривайте каждое из них как написанное на песке на пляже и планируйте изменения.
- Используйте трассирующие пули, чтобы найти цель
Трассирующие пули позволяют вам наводиться на цель, пробуя разные предметы и наблюдая, как близко они приземляются.
- Прототип для обучения
Прототипирование — это опыт обучения. Его ценность заключается не в коде, который вы создаете, а в уроках, которые вы извлекаете.
- Программа, близкая к проблемной области
Дизайн и код на языке вашего пользователя.
- Оценка, чтобы избежать сюрпризов
Оцените, прежде чем начать. Вы заметите потенциальные проблемы заранее.
- Итерация расписания с кодом
Используйте опыт, полученный при реализации, для уточнения сроков проекта.
- Храните знания в виде простого текста
Простой текст не устареет. Это помогает повысить эффективность вашей работы и упрощает отладку и тестирование.
- Используйте мощь командных оболочек
Используйте оболочку, когда графические пользовательские интерфейсы не подходят.
- Хорошо используйте единый редактор
Редактор должен быть продолжением вашей руки; убедитесь, что ваш редактор настраиваемый, расширяемый и программируемый.
- Всегда используйте контроль исходного кода
Контроль исходного кода — это машина времени для вашей работы — вы можете вернуться назад.
- Устраняйте проблему, а не вину
На самом деле не имеет значения, виноват ли баг по-вашему или по чьей-то еще — это все равно ваша проблема, и ее все равно нужно исправлять.
- Не паникуйте при отладке
Сделайте глубокий вдох и ПОДУМАЙТЕ! о том, что может быть причиной ошибки.
- «выбрать» не сломано.
Редко можно найти ошибку в ОС или компиляторе или даже в стороннем продукте или библиотеке. Баг скорее всего в приложении.
- Не предполагай — докажи
Подтвердите свои предположения в реальной среде — с реальными данными и граничными условиями.
- Изучите язык текстовых манипуляций.
Вы проводите большую часть дня, работая с текстом. Почему бы не позволить компьютеру сделать часть этого за вас?
- Пишите код, который пишет код
Генераторы кода повышают вашу производительность и помогают избежать дублирования.
- Вы не можете написать идеальное программное обеспечение
Программное обеспечение не может быть идеальным. Защитите свой код и пользователей от неизбежных ошибок.
- Дизайн с контрактами
Используйте контракты для документирования и проверки того, что код делает не больше и не меньше, чем заявлено.
- Ранний сбой
Мертвая программа обычно наносит гораздо меньше вреда, чем поврежденная.
- Используйте утверждения, чтобы предотвратить невозможное
Утверждения подтверждают ваши предположения. Используйте их, чтобы защитить свой код от неопределенного мира.
- Используйте исключения для исключительных проблем
Исключения могут страдать от всех проблем с читабельностью и ремонтопригодностью классического спагетти-кода. Оставьте исключения для исключительных вещей.
- Заверши начатое
Там, где это возможно, процедура или объект, который выделяет ресурс, должен нести ответственность за его освобождение.
- Сведите к минимуму связь между модулями
Избегайте связывания, написав «застенчивый» код и применяя Закон Деметры.
- Настраивайте, а не интегрируйте
Реализуйте выбор технологий для приложения в качестве параметров конфигурации, а не путем интеграции или проектирования.
- Поместите абстракции в код, детали в метаданные
Программируйте на общий случай, а конкретику вынесите за пределы скомпилированной кодовой базы.
- Анализ рабочего процесса для улучшения параллелизма
Используйте параллелизм в рабочем процессе вашего пользователя.
- Дизайн с использованием сервисов
Дизайн с точки зрения сервисов — независимые, параллельные объекты за четко определенными, согласованными интерфейсами.
- Всегда проектируйте параллелизм
Допустите параллелизм, и вы создадите более понятные интерфейсы с меньшим количеством допущений.
- Отделить представления от моделей
Получите гибкость при низких затратах, разработав свое приложение с точки зрения моделей и представлений.
- Используйте доски для координации рабочего процесса
Используйте доски для координации разрозненных фактов и агентов, сохраняя при этом независимость и изоляцию участников.
- Не программируйте по совпадению
Надейтесь только на надежные вещи. Остерегайтесь случайной сложности и не путайте счастливое совпадение с целенаправленным планом.
- Оцените порядок ваших алгоритмов
Прежде чем писать код, почувствуйте, сколько времени это может занять.
- Проверьте свои оценки
Математический анализ алгоритмов не скажет вам всего. Попробуйте синхронизировать свой код в целевой среде.
- Рефакторинг рано, рефакторинг часто
Точно так же, как вы пропалываете и перестраиваете сад, переписывайте, перерабатывайте и перестраивайте код, когда он в этом нуждается. Устраните корень проблемы.
- Дизайн для тестирования
Начните думать о тестировании до того, как напишете строчку кода.
- Протестируйте свое программное обеспечение, или ваши пользователи
Тестируйте безжалостно. Не заставляйте пользователей находить ошибки за вас.
- Не используйте код мастера, который вы не понимаете
Мастера могут генерировать множество кода. Убедитесь, что вы понимаете все это, прежде чем включить его в свой проект.
- Не собирайте требования — ищите их
Требования редко лежат на поверхности. Они похоронены глубоко под слоями предположений, заблуждений и политики.
- Работайте с пользователем, чтобы думать как пользователь
Это лучший способ получить представление о том, как на самом деле будет использоваться система.
- Абстракции живут дольше, чем детали
Инвестируйте в абстракцию, а не в реализацию. Абстракции могут пережить шквал изменений из разных реализаций и новых технологий.
- Используйте глоссарий проекта
Создайте и поддерживайте единый источник всех конкретных терминов и словарей для проекта.
- Не мыслите нестандартно — найдите стандарт
Столкнувшись с неразрешимой проблемой, определите реальные ограничения. Спросите себя: «Нужно ли это делать именно так? Нужно ли это делать вообще?»
- Начни, когда будешь готов.
Вы накапливали опыт всю свою жизнь. Не игнорируйте назойливые сомнения.
- Некоторые вещи лучше сделать, чем описать
Не впадайте в спираль спецификаций — в какой-то момент вам нужно начать программировать.
- Не будьте рабом формальных методов.
Не применяйте слепо какую-либо технику, не рассматривая ее в контексте ваших методов и возможностей разработки.
- Дорогостоящие инструменты не позволяют создавать лучшие проекты
Остерегайтесь ажиотажа поставщиков, отраслевых догм и ауры ценника. Судите инструменты по их достоинству.
- Организуйте команды вокруг функциональности
Не отделяйте дизайнеров от программистов, тестировщиков от специалистов по моделированию данных. Создавайте команды так же, как вы создаете код.
- Не используйте ручные процедуры
Сценарий оболочки или пакетный файл будут выполнять одни и те же инструкции в том же порядке раз за разом.
- Ранний тест. Проверяйте часто. Тестировать автоматически
Тесты, которые запускаются с каждой сборкой, намного эффективнее, чем планы тестирования, лежащие на полке.
- Кодирование не завершено, пока не будут выполнены все тесты
'Достаточно.
- Используйте саботажников для проверки вашего тестирования
Внесите ошибки специально в отдельную копию исходного кода, чтобы убедиться, что тестирование их обнаружит.
- Покрытие тестового состояния, а не покрытие кода
Идентифицируйте и тестируйте значимые состояния программы. Просто протестировать строки кода недостаточно.
- Найдите ошибки один раз
Когда человек-тестер находит ошибку, это должен быть последний раз, когда человек-тестер находит эту ошибку. С этого момента автоматические тесты должны проверять его.
- Английский — это всего лишь язык программирования
Пишите документы так же, как пишете код: соблюдайте принцип DRY, используйте метаданные, MVC, автоматическую генерацию и так далее.
- Создавайте документацию, а не прикручивайте ее
Документация, созданная отдельно от кода, с меньшей вероятностью будет правильной и актуальной.
- Осторожно превзойдите ожидания ваших пользователей
Приходите к пониманию ожиданий ваших пользователей, а затем предлагайте чуть больше.
- Подпишите свою работу
Ремесленники более раннего возраста с гордостью подписывали свои работы. Ты тоже должен быть.