Программисты, как и все остальные, становятся жертвами тенденций и моды

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

Ежедневные схватки, объектно-ориентированное программирование, интерпретируемые языки, лямбды, оценка сюжетных точек, блокчейн, разработка через тестирование, библиотеки ORM, функциональное программирование, обобщения, шаблоны, обработка бэклога, блоки try / catch - были написаны миллионы слов, защищающих и жалуются на каждого.

Как прихоть превращается из временной тенденции в постоянную составляющую в разработке программного обеспечения? Есть ли способ отделить причуды программирования от хороших идей?

Что делает причуду?

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

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

int main()
{
  printf("Hello world"); // The old C way
  cout << "Hello world"; // The new C++ way
  return 0;
}

Я использую слово «ужасающий» выше не из-за самого примера, а из-за того, что должно было произойти. В конце 80-х - начале 90-х годов казалось, что каждый программист считал, что перегрузка операторов - это круто, и они записывали странные операторы в свои библиотеки только потому, что могли.

Перегрузка операторов может упростить некоторые вещи, например математические библиотеки для комплексных чисел. Это также может еще больше усугубить ситуацию. Библиотека scala-graph придумала десятки операторов для всевозможного синтаксиса.

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

  • Готовые программные компоненты в Visual Basic
  • «Фабрики» на языках, производных от Java и J2EE
  • Операторы LINQ в C #
  • Преобразование всего в лямбду

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

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

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

Командные методологии и причуды в управлении бизнесом

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

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

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

Волна книг с советами по бизнесу гарантирует, что ни хорошие, ни плохие идеи никогда не исчезнут полностью. XP определила свою эпоху, как и шаблоны проектирования; Сейчас мы живем во времена agile и scrum. Однажды они тоже исчезнут, и нам предстоит сохранить в живых лучшие части каждого из них.

Умеренность во всем

С таким количеством новых идей - и даже с таким количеством новых поколений новых идей - как мы можем справиться с наводнением? Сможем ли мы найти способы отбирать лучшие элементы каждого поколения, каждой прихоти менеджмента?

Столкнувшись с аналогичной проблемой в конце 1990-х годов, старшее поколение ИТ-менеджеров попробовало глупый подход:

  • Подождите, пока Microsoft выпустит первый пакет обновления.

Симпатично, но практично. Пакеты обновлений были выпущены спустя месяцы или годы после выпуска программного обеспечения. Ранние последователи уже взялись за это и нашли ошибки. Совместимые драйверы отправлены. Документация и учебные пособия были доступны.

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

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

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

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

Как вы помогаете своим командам внедрять новые идеи?