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

  • Процедурный код для динозавров
  • Функциональное программирование — это путь
  • MongoDB — это «дерьмо»
  • Все реляционные базы данных — зло
  • Динамические языки делают вас быстрее
  • Статическая типизация — это просто бесконечные церемонии
  • TDD все вещи
  • ТДД мертв
  • SOLID — карго-культ
  • и Т. Д.

Но правда в том, что ни один инструмент не обязательно хорош или плох. (Хорошо, хорошо, Sharepoint следует избегать любой ценой, но вы поняли мою точку зрения.) У каждого инструмента есть свой контекст, стоимость и проблема, которую он должен решить. Наша работа, как инженеров, состоит в том, чтобы знать и распознавать ситуации, в которых можно использовать каждый инструмент или которого следует избегать. Испытывающий? — Черт, да. Требуется опыт? — Много. Но эй, это никогда не должно было быть легко. И, кстати, это почти буквальное определение инженерии, согласно ECPD (Американскому совету инженеров по профессиональному развитию):

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

Уход

Следовательно, ограничивать себя одним решением для всех проблем — это не инженерия, а хакерство. И не поймите меня неправильно, взлом — это не обязательно плохо! Это всего лишь инструмент, и как таковой он может быть полезен — например, когда вам нужно быстро доставить, и вы знаете, что проект не будет развиваться. Но это не «путь». Не существует «пути», и не тратьте время на его поиски. Вместо:

  • Получите опыт работы с различными парадигмами программирования: объектно-ориентированным, функциональным и даже процедурным программированием — все они полезны в одних случаях, но бесполезны в других.
  • Окунитесь в дивный новый мир NoSQL. Сегодня у нас есть множество семейств баз данных на выбор — хранилища документов, хранилища ключей/значений, индексы поиска, графы, хранилища столбцов, реляционные базы данных. К сожалению, ни один из них не идеален. У каждого есть свои сильные и слабые стороны. Или, как выразился Грег Янг, каждая база данных отстой по-своему. Поэтому научитесь эффективно применять различные типы баз данных.
  • Узнайте, для решения каких проблем предназначены различные архитектурные шаблоны: Layers, Hexagonal, CQRS, DCI. При правильном применении они управляют сложностью и абстрагируют ее на разных уровнях; при неправильном применении они приводят только к случайным сложностям.
  • И последнее, но не менее важное: изучите различные способы моделирования бизнес-доменов и бизнес-логики: активная запись, модель домена (ddd), модель домена с источником событий и сценарий транзакции. Каждый из этих шаблонов относится к разным уровням сложности. Использование правильного шаблона снизит общие затраты на разработку и затраты на внесение изменений в будущем.
  • и Т. Д.

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

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

Профилактика

В конечном счете, не влюбляйтесь в свою эвристику дизайна! Они также могут быть субъективными, и их использование может зависеть от дополнительных факторов, связанных с проектом:

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

P.S.

…Я уже упоминал, что разработка программного обеспечения — это не прогулка в парке?

Первоначально опубликовано на vladikk.com 29 января 2019 г.