Будущие системы, долговечность кода и города-призраки

расшифровка

Тим:

Эй, как дела, все это Тим Эвко …

Дэвид:

… а это М. Дэвид Грин …

Тим:

… и вы слушаете девятый эпизод подкаста версий.

Дэвид:

Это место, где мы собираемся, чтобы обсудить индустрию Интернета от разработки до дизайна — с некоторыми из людей, которые делают это сегодня, и планируют, к чему это приведет в следующей версии.

Тим:

Сегодня это только Дэвид и я, и мы будем говорить о программном обеспечении. В частности, когда вы создаете программное обеспечение, как долго оно должно продолжаться?

Итак, мы собираемся погрузиться в это. Мы собираемся поднять некоторые интересные перспективы и моменты, и да, жизненные циклы.

Итак, давайте продолжим и начнем эту версию.

Дэвид:

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

Тим:

Да, и это немного сложно сделать.

Дэвид:

Вместо этого, поскольку мы собираемся поговорить на эту тему: Тим, ты поднял эту тему. Мне любопытно, что напомнило вам об этом.

Тим:

Да. Так что, конечно, у меня есть работа на полную ставку. Я работаю над созданием команды определенного программного обеспечения. Это платформа электронной коммерции. Это веб-сайт, и вы идете и покупаете у него продукты.

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

Часто, работая с другими и просто работая с собой, я склонен думать, что я хочу создать эту вещь, которая будет работать вечно и работать на каждом устройстве. И это сложная модель, в которую нужно вложить голову — строить на будущее, делать вещи на будущее. Я часто спрашиваю себя не только о том, как правильно поступить, но и о том, какой правильный настрой для каждой конкретной вещи, над которой я работаю?

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

Дэвид:

Я думаю, что в 2100 году люди должны будут выяснить, как получить доступ ко всему этому. Я только недавно слушал подкаст. Они говорили о ситуации, в которую попала НАСА, когда она отправила все данные с оригинальных лунных зондов.

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

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

Идея о том, что что-то будет длиться вечно, начинает казаться несколько сомнительной, когда мы понимаем, что некоторые из самых сложных технологий, которые мы внедрили для хранения и извлечения данных только за последние 20, 30 лет, уже невозможны чтобы получить.

Тим [3:48]:

Это и очень интересная история, и отличный момент, потому что технология через 10, 20, 30 лет — может быть, даже через 5 лет — может показаться кому-то совершенно чуждой. Прямо сейчас мы пишем на JavaScript, и, возможно, это изменится через 20 лет. Может быть, все эти библиотеки и вещи, которые мы строили, просто не будут такими через определенное время.

Итак, я думаю, мой вопрос становится, для чего вы строите? Поскольку у меня есть это врожденное чувство, я хочу, чтобы вещи длились столько, сколько им нужно . Если я что-то строю, и десять других людей вдруг решают, что мы тоже хотим поработать над этим, в каком настроении я должен быть с самого начала, с самого начала. Прежде чем я напишу свою первую строку кода, какой должна быть цель на весь срок службы этого проекта?

Дэвид:

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

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

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

Тим:

Это очень верно. Итак, я думаю, давайте начнем с того, что мы имеем в виду проект. У нас есть то, что мы хотим построить. Что-то, о чем мы оба можем договориться — независимо от цели или предполагаемого использования вещи — важно с точки зрения срока службы проекта или организации? Я бы сказал, что важно было бы, хорошо, да, если по какой-то причине я снова столкнусь с этим кодом через год, по крайней мере, я хочу, чтобы он приписывал определенный шаблон проектирования, чтобы обеспечить его удобочитаемость и организацию.

Дэвид:

Это имеет смысл.

Тим:

Тогда я бы сказал, потому что шаблоны проектирования меняются, и поэтому некоторые люди скажут: «О, это десятилетие — все о процедурном коде, а это десятилетие — о функциональном коде». По крайней мере, даже если это действительно изменится, я Я могу распознать процедурный, объектно-ориентированный и функциональный паттерн, когда я его вижу.

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

Дэвид:

Забавно. Просто даже шаблон дизайна фразы начинает заставлять мою кожу ползать. Я начинаю вспоминать времена, когда я работал на Java (и я никогда больше не работаю на Java, поверьте мне), я думаю, что это была Банда четырех, которая делала эти шаблоны проектирования, и я помню много чего В ранние годы я учился на инженера, который пришел из мышления по шаблонам.

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

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

Тим [8:08]:

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

Затем это становится немного мутным, потому что наш код структурирован особым образом, но тогда никто не пишет код, как просто, хорошо, мы начинаем с машинного кода, а затем мы пишем все, и у нас есть все, что нам нужно, просто разобрано здесь. Люди используют библиотеки, фреймворки и разные инструменты. Это означает, что он действительно начинает, сразу же, зависеть от (по крайней мере для меня), он начинает зависеть от цели проекта. Потому что, если я пишу что-то, что — я не знаю — пользовательский интерфейс для коммунальной компании, я, вероятно, хочу, чтобы это длилось как можно дольше.

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

Да, у меня есть шаблон проектирования, или способ, которым я хочу структурировать свой код так, чтобы он был читабельным, но после этого, когда он начнет действовать, хорошо, теперь, если я собираюсь обратиться к этой библиотеке, тогда Я должен подумать, будет ли это то, что больше не имеет смысла или будет пригодно для использования в ближайшие пару лет? Или, если я использую этот конкретный инструмент для сборки, если мне придется вернуться к этому через несколько месяцев или через несколько лет, мне придется отряхнуть старую машину, чтобы я мог запустить эту версию Node, которая эта вещь только работает?

Да, если вы планируете эти вещи, вы должны начать обдумывать это сразу. Я подумал, что мы могли бы перечислить некоторые вещи, с которыми мы бы согласились. Мы могли бы быть настроены, вплоть до тех пор, пока нам не пришлось решать, какова цель проекта. Но кажется, что почти сразу ты должен это сделать.

Дэвид:

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

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

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

Я имею в виду, например, индустрию медицинского страхования, правительственные контракты, банковскую индустрию, многие из этих областей. У Microsoft были проблемы с тем, чтобы заставить эти компании обновить старые версии своих операционных систем, потому что они были привязаны к этим старым версиям. В итоге возникла ситуация, когда, как я помню, все кричали, чтобы Microsoft наконец-то завершила работу Internet Explorer 6 с истекшим сроком эксплуатации. Microsoft не могла этого сделать, потому что многие из их клиентов были заблокированы этими версиями программного обеспечения, которые им пришлось бы перепроектировать все свои платформы для поддержки новой операционной системы.

Тим:

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

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

Давид [12:21]:

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

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

Тим:

Да, так и должно быть. Я искал код запуска Apollo, который был на GitHub. Я думаю, что на этой неделе он был выпущен на GitHub. Это было потрясающе . Это было просто удивительно, просто посмотреть — эта вещь приземлилась на Луну. Это восхитительно.

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

Дэвид:

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

Тим:

Я думаю, что мы обнаруживаем здесь кое-что очень интересное: когда вы спрашиваете себя: «Как долго должно работать это программное обеспечение?», Ответ заключается в том, что оно никогда не будет длиться вечно, конечно. Я думаю, мы также поняли, что когда вы спрашиваете себя: «Как долго должно продолжаться это программное обеспечение?», Это действительно зависит не только от того, какое программное обеспечение предоставляет, но и от того, какое программное обеспечение оно представляет. Если мы говорим о чем-то для внешнего интерфейса, это будет иметь другое время жизни, чем ОС или браузер.

Дэвид:

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

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

Тим [16:00]:

Да, особенно в отраслях с высоким уровнем безопасности, таких как банковское дело и страхование. Это интересно. Итак, создавая программное обеспечение, спрашивая себя, как долго это должно продолжаться, я начинаю думать, что две вещи, а) это никогда не будет очень длинным, но б) если вы хотите, чтобы это длилось очень долго, вы должны быть обеспокоены зависимостями и инструментами.

Дэвид:

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

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

Тим:

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

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

Дэвид:

Я собираюсь сказать, что я согласен с вами, потому что я думаю, что это имеет значение в отношении вашего второго пункта. К вашему первому замечанию, я думаю о том, какой уровень абстракции мы получаем от того, что на самом деле производится, и того, что мы пишем. Вы упоминали ранее о транспилировании, и транспилирование — это только одна часть этого, потому что мы не только транспилируем, мы тянем библиотеки, мы тянем фреймворки.

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

Тим:

Да.

Дэвид:

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

Тим:

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

Дэвид [19:50]:

Это определенно то, что люди должны иметь в виду. Я думаю, что если бы я сейчас разрабатывал новый проект для крупного клиента, это был бы один из ключевых вопросов, которые я бы задал. Потому что вам нужно выбирать из доступных технологий, и вы должны быть совместимы со всеми доступными средами, которые имеют отношение к конкретному проекту. Чтобы сделать это, вам нужно строить поверх этой огромной инфраструктуры, и вам нужно знать, насколько вы контролируете это и насколько это важно для любой компании, в которой вы работаете.

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

Тим:

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

Дэвид:

Хэштег!

Тим:

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

Но если бы это даже было возможно, я чувствую, что идея прогрессивного улучшения очень помогает. Потому что, если я сейчас создаю что-то для устройства с наименьшими возможностями, это означает, что я не собираюсь полагаться на конкретную основополагающую вещь, работающую точно так, как сейчас. Вместо этого я полагаюсь на то, что Интернет делает то, что у него получается лучше всего, и это то, что действительно способствует тому, что я создаю. Тогда все остальное помимо этого — просто еще один уровень удобства.

Дэвид:

Это поможет, если вы не пишете для Commodore Amiga .

Тим:

Я думаю, что если вы начнете задавать себе вопрос: «Как долго должно продолжаться программное обеспечение?», Вы хотите убедиться в двух вещах. Дело номер один, организация — чтобы каждый раз, когда вы возвращались и смотрели на это, вы могли на самом деле знать, что вы делали в то время. Я буду первым, кто скажет, что если бы я посмотрел на код, который я написал даже три года назад, я бы, наверное, — я не знаю — упал или что-то в этом роде, потому что мы все смотрим на код, который мы написали давным-давно и просто ненавидим себя за это.

Дэвид:

Абсолютно.

Тим:

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

Дэвид:

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

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

Тим [23:39]:

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

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

Как вы это объясняете? Как вы учитываете изменение жизненного цикла продукта?

Дэвид:

Я собираюсь сказать, что это другой вопрос.

Тим:

Это честно.

Дэвид:

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

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

Тим:

Это как группа, чьи первоначальные участники уже ушли.

Дэвид:

Это правда, но они все еще играют те же песни.

Тим:

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

Дэвид:

Как инженеры, я думаю, что мы хотим писать таким образом. Конечно, более приятно писать чистый код — код, который вы можете показывать кому-либо, не смущаясь. И что кто-то станет вами через шесть месяцев, так что вам лучше не смущаться.

Тим:

Да. Я поднял этот вопрос, потому что чем больше у меня опыта в разработке и разработке, тем больше я спрашиваю себя: «Хорошо, каковы намерения для этой вещи, которую я строю? Это будет существовать через шесть месяцев? »Кажется, что в большинстве случаев оно действительно существует какое-то время, и мои намерения могут остаться прежними. Они могут измениться, но в целом есть те основные принципы, которые необходимо применять к тем вещам, которые вы создали, на случай, если вы захотите пойти немного дальше.

Дэвид:

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

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

Тим:

Это очень хорошо, потому что, насколько я заметил, код никогда не выживает. Код подобен мутантному ДНК-вирусу, который постоянно меняется и выглядит по-другому. Когда я помогал создавать адаптивные изображения в WordPress , я сначала написал оригинал — я не знаю, — три версии этого, с момента, когда это была просто идея в файле PHP в Sublime Text, для Криса Койера и я работал над этим, чтобы раздвоить WordPress с нашим репозиторием RICG, чтобы получить что-то похожее на репозиторий WordPress.

И затем мы начали говорить: «Хорошо, давайте работать над плагином. Осталось 50% моего кода ». Затем мы говорим:« Хорошо, теперь плагин одобрен для использования в качестве функции WordPress в следующей версии 4.0 ». Тогда есть 25% моего кода. И как раз перед тем, как мы на самом деле нажали кнопку публикации, и WordPress выпустил нашу функцию, в ней осталось, возможно, 1% или половина 1% моего кода!

Дэвид [28:06]:

Я напечатал эту точку с запятой. Я сделал, я сделал!

[Смех]

Тим:

Да, это в значительной степени, где это сейчас. Это как: «Вы видите этот комментарий? Я написал этот комментарий.

[Смех]

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

Дэвид:

Абсолютно. Я думаю, что различие между тем, как долго живет код и как долго живет программное обеспечение, полезно для размышлений об этом.

Тим:

Определенно.

Дэвид:

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

Тим:

Легко, легко, да. Потому что даже сейчас, когда вы смотрите на код год назад, и это выглядит так: «Ну, я использовал кучу операторов var , и я мог бы использовать константы». Константы тогда еще не существовали, так что вы идете.

Да, я определенно думаю, что это отличное различие, как долго должен длиться код? И затем, конечно, даже с JavaScript все ваши XMLHttpRequest превратятся в запросы Fetch, а AppCache превратится в Service Worker, и так далее, и тому подобное. Если мы напишем код с идеей, что это всего лишь шаг в лестнице, он может не существовать через десять дней, но он немного продвинет нас вперед, это поможет улучшить работоспособность программного обеспечения.

Дэвид:

«Ко всему — повернись, повернись, повернись».

Тим:

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

Дэвид:

Это интересная тема, и она противоречива. И мне действительно интересно, что слушатели подумают об этом, потому что они там, у них разные перспективы. Я знаю, что некоторые из них приходят с точки зрения бизнеса, некоторые из них с точки зрения инженерии. Некоторые из них могут исходить только с точки зрения пользователя, о том, как долго они ожидают, что их программное обеспечение будет работать, когда они получат часть программного обеспечения или когда они попадут на сайт. Как долго они ожидают, что этот сайт будет там и останется в узнаваемой форме?

Тим:

Это интересно, потому что мы утверждаем, что создаем материал для Интернета, и я даже не думал задавать этот вопрос. Я, конечно, знаю, что когда я использовал Rdio для прослушивания всей своей музыки, а Rdio потерял сознание, это было для меня как будто изменяющей жизнь вещью. Это было похоже на «Нет, моя музыка, что происходит?»

Мне пришлось создать еще один фальшивый плейлист 80-х, а затем я перехожу к Google Play Music , и я думаю, что я действительно надеюсь, что это будет длиться вечно. Я инвестировал в это программное обеспечение. Здесь я и получаю свою музыку. Когда я иду в спортзал утром, у меня есть то, что я просто знаю, как это работает. Я не должен думать об этом.

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

Дэвид:

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

Тим:

Определенно да. Это правда с редизайнами. Например, все мы знаем продукты, которые превратили себя в темную пещеру, где вы знаете продукты, которые изменили свою бизнес-стратегию и разделились на две части, а затем быстро умерли.

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

Дэвид [31:48]:

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

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

Тим:

Да. Я просто думаю о кладбище музыкальных вещей, которые я использовал. Первым был LimeWire, а потом — Pandora, но Pandora не позволяет выбирать разные песни, и я в конце концов устал от этого. Я добровольно перешел от этого. Я потерял целую кучу станций, которые я заплатил, потому что это была скорее бизнес-модель, чем инженерная, но в Pandora были зависания с ошибками, но я решил отказаться от этого.

Тогда это был Grooveshark. Я заплатил за Grooveshark на самом деле. Я был платным участником Grooveshark, и я мог слушать все мои песни, и у меня был миллион плейлистов. Все они были превосходны. И вот однажды Гровешарк исчез. Они как: «Извините, наши судебные процессы наконец-то настигли нас». Вот и все, все кончено. Вся моя музыка исчезла, ничего не было скопировано.

Затем я перешел прямо к Spotify — из которого я сразу же вышел, потому что я не мог вынести тот факт, что они привязали все к вашей учетной записи Facebook. Вы в значительной степени должны были пойти только для приложений, потому что их веб-интерфейс был просто пожаром мусорного контейнера. (Если вы работаете в Spotify, я искренне извиняюсь. Возможно, сейчас это лучшая вещь в мире, но в то время это была не моя вещь.)

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

Дэвид:

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

Тим:

Я также не хочу, чтобы надоедливые ошибки отгоняли меня от любви к продукту. Например, когда я думаю конкретно о Google Play Music, если я менял песню, а браузер обновлялся, а он просто забывал, что происходит, и это продолжало происходить, я был бы в ярости. Я был бы очень расстроен этим.

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

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

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

Я думаю, как разработчики, мы хотим, чтобы наше программное обеспечение было хорошим и работало столько, сколько нужно.

Давид [35:33]:

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

Трудно сказать: «Вы не можете сделать что-то такое прочное, если не будете постоянно адаптировать его и постоянно адаптировать».

Тим:

Очень верно. Прогрессивное улучшение действительно решает некоторые из этих вещей, но оно не решает все эти вещи.

Дэвид:

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

Тим:

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

Дэвид:

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

Тим:

Да. Пожалуйста, напишите нам письмо, включите твит, отправьте дымовые сигналы, что бы вы ни делали Мы определенно ответим, и мы с нетерпением ждем того, что вы все придумали.

Дэвид:

Что это был за хэштег?

Тим:

#webGhostTown.

Дэвид:

Веб-город-призрак. Все в порядке. Чирикать нам на Versioning Show или использовать хэштег #webGhostTown, и мы будем искать их.

Тим:

О, да. Я собираюсь сохранить это в Twitter, и я буду смотреть каждый день. Не подведи меня. Пожалуйста, только один из вас использует это!

Дэвид:

Здорово.

---

Спасибо всем за внимание, все. Нам всегда нравится говорить со всеми вами о технологиях.

Тим:

Мы также хотели бы поблагодарить SitePoint.com и наших продюсеров, Адама Робертса и Офели Лехат. Пожалуйста, не стесняйтесь, присылайте нам свои комментарии в Twitter — @versioningshow — и дайте нам оценку на iTunes, чтобы сообщить нам, как мы делаем.

Дэвид:

Увидимся в следующий раз и надеемся, что вам понравилась эта версия.