Транскрипт подкаста: Философия разработки программного обеспечения с Джоном Остерхаутом

Влияние ИИ на разработку программного обеспечения

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

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

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

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

О карьере в академической среде и индустрии

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

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

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

Различия между индустрией и академической средой

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

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

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

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

О "тактических торнадо" в разработке

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

Джон считает, что это просто определенный тип личности. Есть люди, которые очень сосредоточены на деталях и хотят, чтобы всё было абсолютно правильно, и они завершают всё. А есть люди, которые любят начинать проекты и делать первые 80 или 90%, но последние 10 или 20% для них не так важны.

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

О глубоких и поверхностных модулях

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

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

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

Об обработке ошибок

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

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

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

О проектировании программного обеспечения

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

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

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

О разработке через тестирование (TDD)

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

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

О комментариях в коде

Роберт Мартин (Дядя Боб) говорит, что в коде должно быть как можно меньше комментариев, код должен говорить сам за себя. Джон не полностью согласен с этим.

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

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

Роберт также утверждал, что если ты работаешь над проектом, над которым работаешь ты и другие разработчики, тебе не нужны никакие комментарии, потому что у всех всё загружено в голове. И опять же, Джон просто не согласен с этим. Может быть, ум Роберта лучше, чем ум Джона, но Джон не может держать всё в голове и забывает код в течение нескольких недель после того, как написал его. Так что ему нужны эти комментарии.

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

О текущем проекте Джона

Один из аспирантов Джона, Бен Монтазери, в рамках своей докторской диссертации шесть или восемь лет назад разработал новый транспортный протокол под названием Homa, который предназначен для использования в центрах обработки данных. Результаты, которые Бен получил в своей диссертации, действительно потрясающие. Протокол Homa в 10-100 раз быстрее TCP для множества интересных случаев. И вместо того, чтобы позволить этому просто прийти и уйти как проекту PhD, о котором никто никогда не заботится, Джон взял в качестве своего личного проекта выяснить, действительно ли возможно внедрить это в широкое использование и заменить часть трафика TCP в центрах обработки данных.

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

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

О проектировании дважды

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

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

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

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

Лучший пример, который Джон может вспомнить за всю свою карьеру, был, когда он проектировал инструментарий TK, который является частью системы Tickle TK. Он пытался выяснить, каким должен быть API для программирования графических виджетов. Он потратил, кажется, в основном долгий авиаперелет, и в основном сделал два дизайна для этого. Он сделал первую идею, которая пришла в голову, а затем сказал: "Хорошо, предположим, я собираюсь выбросить это. Что было бы чем-то действительно другим, что я мог бы сделать?" Он сделал второй вариант. И после сравнения он выбрал вторую идею. И честно говоря, это была одна из лучших идей, которые у него были в его профессиональной карьере.

О дизайн-документах и обсуждениях

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

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

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

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

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

О коротких методах и методах, делающих только одну вещь

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

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

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

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

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

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

О будущем программного обеспечения

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

О второй редакции книги

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

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

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

Одна вещь, на которую Джон надеялся, когда писал книгу, это то, что люди придут к нему с новыми идеями, о которых он не думал, и что он будет учиться на этом, а затем получать больше идей и постепенно добавлять всё больше и больше материала в книгу. Но этого не произошло в большой степени до сих пор. Он был бы рад, если бы люди пришли и сказали: "Ты полностью неправ. Эта идея здесь, в книге, полностью неверна. Вот почему. Вот как ты должен делать это вместо этого." И на самом деле не было столько этого, как он надеялся, когда писал книгу.

Уникальность класса Джона по проектированию программного обеспечения

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

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

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

О преподавании проектирования программного обеспечения

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

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

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

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

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

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

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

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

Заключение

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

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