Удивительная связь между оркестровкой музыки и разработкой программного обеспечения
Я должен быть честным: я не думал, что стану инженером-программистом. Когда я переехал в Лос-Анджелес после окончания школы, я надеялся писать музыку для фильмов. Хотя мое стремление проникнуть в индустрию действительно принесло мне пару кредитов (и мою собственную страницу IMDb), это была техническая работа, которая оплатила счета. Работающие композиторы предупреждали меня, что когда хобби становится занятием, ты рискуешь потерять любовь к нему. А работа над сочинением может быть долгой и изнурительной. Я находил утешение в том, что мое образование было таким же разнообразным, как и мои интересы, и только задним числом мой извилистый путь начал обретать какой-то смысл.
Теперь, когда я провел последние, сколь угодно много лет, изучая программирование, изучая системную архитектуру и оптимизируя алгоритмы, я могу признать, что лучшее образование, которое я получил для этих задач, было получено не из какого-либо учебного курса или руководства O'Reilly, а из изучения оркестровки в музыкальная школа. То есть, благодаря чистому пониманию философии ремесла, Могучая пятерка говорила со мной с большей ясностью, чем Банда четырех. Извините за это достойное стона сравнение — мне просто нужно было перейти к примерам.
Функция перед формой
В одном музыкальном злоключении я стремился написать фортепианное трио (фортепиано, скрипка и виолончель). Я продолжал зацикливаться на том, что должны делать другие инструменты, в то время как мое музыкальное внимание было сосредоточено на том, что было в центре внимания. Я забежал вперед, даже не подозревая об этом. В конце концов мой профессор хлопнул меня по голове и сказал: «Хватит пытаться написать это наизнанку!»
Он имел в виду, что я не смог сначала установить основную идею, то есть мелодию, припев, музыкальную основу. Без этого предварительного условия не имело смысла тратить время на то, как это музыкальное выражение должно быть разделено между n числом исполнителей. Как будто я пригласил группу друзей помочь мне с переездом, но вместо того, чтобы помочь мне загрузить коробки в грузовик, они сидели и вертели пальцами, потому что я даже не упаковал свои сумки.
Вывод
При создании программных приложений постоянно возникает одна и та же проблема «повозка впереди лошади». Подобно тому, как ребенок упаковывает сумку на выходные к бабушке со всеми мыслимыми нелепыми безделушками, собранными с пола в игровой комнате, разработчики склонны использовать любую доступную технологию просто потому, что она есть. Доступные технологии — это решения, просто напрашивающиеся на проблему, и это неправильный способ управления архитектурой вашего программного обеспечения.
Вместо этого основные задачи должны быть четко определены заблаговременно, чтобы решения могли правильно решать их. В противном случае ваши «решения» в итоге окажутся «решениями» воображаемых проблем, и вы получите накладные расходы и путаницу. Вам нужно сохранять состояние во времени и пространстве? Если нет, то зачем вам база данных? Вам вообще нужно приложение или простой модуль подойдет? Если вам нужны простые и эффективные решения, первым шагом всегда является четкое определение ваших проблем.
Другой вариант этой ошибки допущен руководством. Это происходит, когда бизнес плохо определен, и компания ошибочно полагает, что если они будут продолжать добавлять достаточное количество умных людей, спонтанно появится четко определенный продукт. Эта идея так же абсурдна, как играть концерт без партитуры. Неважно, есть ли у вас Йо-Йо Ма или Джошуа Белл в струнной секции: если вы не поняли, что играете, это будет неряшливая какофония.
Быть идиоматичным
Однажды, торопясь закончить оркестровую партитуру, я скопировал и вставил мелодию со струнных на деревянные духовые, когда фраза разошлась по всему оркестру. «Вы упускаете суть», — выругался мой профессор, увидев это. Конечно, на высоком уровне версии мелодии раздаются по разным оркестровым секциям. Но это не выдвигает на первый план личностей различных инструментов. Не существует универсального решения. Например, пианино не может играть длинную устойчивую ноту. Труба не может легко войти на высокой ноте — лучше, если она войдет на более легкую ноту и продвинется вверх. И так далее.
Хороший вопрос, который следует задать при передаче музыкальной идеи конкретному инструменту: «Что уникального может предложить этот инструмент? Что этот инструмент может сделать такого, чего не могут другие инструменты?» Другими словами, части должны быть идиоматическими. Когда вы правильно откалибровали свои мелодии, ваши музыкальные строки должны быть написаны таким образом, чтобы подсказывать, какие инструменты должны их играть. Вы не просто копируете и вставляете: вы сосредотачиваетесь на идиоматических личностях, например. добавление трелей к партиям флейты или глиссандо для тромбонов.
Вынос
Что касается программного обеспечения, слишком часто мы тянемся к «дьяволу, которого мы знаем» — то есть к языку или технологии, с которыми мы знакомы, — не задумываясь серьезно о том, подходят ли они для решения конкретной проблемы. Вы легко можете оказаться в токсичных отношениях: вы отдаете свое время, а оно не отвечает вам взаимностью. Иногда, когда рекрутер или менеджер по найму описывает стек технологий, используемый в их организации, я спрашиваю: «Почему вы используете X?» И часто у них нет хорошего ответа, и это красный флаг. У вас может быть туба, играющая высокие вычурные щебетания, но на самом деле туба не для этого. Если компания заставляет своих тубистов вот так прыгать через пылающие обручи, ответ на вопрос «почему?» должно быть что-то вроде «мы отчаянно ищем пикколо», иначе ясно, что они злоупотребляют своей технологией и, безусловно, тратят время и деньги людей, пытаясь получить кровь из камней.
Для более глубокого понимания парадигм разных языков я рекомендую посмотреть несколько видео Джесси Дрелика на эту тему.
Изолировать бизнес-правила: DRY
Может показаться, что в музыке нет «правил бизнеса», но в ней есть всевозможные правила и условности, влияющие на ее течение и структуру. Одна простая ошибка, которую я допустил во время оркестровки, заключалась в том, что я разделил ноты аккорда: я дурачился, когда диктовал, кто играет тонику, а кто — квинту и терцию. Я непреднамеренно удвоил терции в нескольких разделах. Результат звучал ужасно, и снова мой профессор был рядом, чтобы объяснить, почему.
Все аккорды будут иметь тонику и квинту, но именно терция определяет, является аккорд мажорным или минорным. У вас может быть целый оркестр, играющий корни и квинты на полную мощность, а один-единственный инструмент, тихо играющий в углу, может придать аромат всему происходящему, просто сыграв терцию. Если вы попытаетесь удвоить эту ответственность, становится трудно настроиться. Ваша интерпретация третьего может быть немного выше или ниже, чем у кого-то другого, и результат, как решительно заключил мой профессор, «звучит как дерьмо».
Вынос
Мы больше знакомы с этой поговоркой в сфере программирования, но ясно, что те же самые правила влияют на музыку: а именно, должен быть один источник правды. Не повторяйтесь. Если ваш бизнес требует индивидуального расчета SKU или стоимости доставки, то за эту задачу должен отвечать один модуль, служба или приложение, иначе вы рискуете получить несогласованные результаты.
Я все больше благодарна за свое музыкальное образование. Во всяком случае, чем больше я узнаю о программном обеспечении, тем больше я понимаю, что это искусство, а не наука, и важно прислушиваться к оркестру (или техническому стеку), чтобы гарантировать, что объединенный результат воплощает в себе согласованные качества. Мы все хотим хорошего исполнения и запоминающейся мелодии, и чем больше вы будете узнавать об оркестровке, тем надежнее будут ваши усилия.
