Между «работающим кодом» и «качественным кодом» есть существенная разница. Это действительно сводится к тому, как вы хотите тратить свое время (и деньги). Вы можете быстро написать код в начале, но изменения и ошибки будет сложнее исправить в дальнейшем. Или вы можете инвестировать время в самом начале и иметь проект, который будет стабильным и пригодным для использования в течение длительного времени.
Полная расшифровка ниже:
Крис:
В чем разница между работающим кодом и высококачественным кодом?
Коди:
Несомненно, одну и ту же работу можно выполнять несколькими способами.
Крис:
Принимая во внимание, что код, который работает, больше похож на "Он работает, но как долго?"
Коди:
Кто это написал, кто это написал? Это был я.
Крис:
Да.
Крис:
Коди, рад снова видеть тебя в студии.
Коди:
Всегда. Рад вернуться.
Крис:
Да. Итак, сегодня мы поговорим о высококачественном коде.
Коди:
Ох, ладно.
Крис:
Да. Так в чем же разница между работающим кодом и кодом высокого качества? Потому что я думаю, что это разные вещи, и почему это важно?
Коди:
Определенно да. Итак, если вы инженер, давайте посмотрим на это с точки зрения инженера-программиста: определенно часто существует более одного способа выполнить одну и ту же работу.
Крис:
Хорошо.
Коди:
Чтобы достичь определенной бизнес-цели, написать функцию, реализовать страницу. Часто существует много различных качественных различий в различных способах, которые вы можете выбрать для фактического выполнения такой задачи. И разница между идеей высокого качества и противоположной идеей, которую я бы назвал быстрой или исторически известной как «ковбойское кодирование», заключается в том, что реализованная высококачественная функция будет одновременно ориентированной на будущее и ориентированной на будущее. мышление, и я думаю, что основной термин будет поддерживаться.
Коди:
Итак, когда мы перейдем к тому, что это означает с точки зрения качественных областей в коде, это будут комментарии, хорошая структура, сохранение простоты, даже в сложных областях. Иногда, даже если вы можете написать что-то очень сжатое, и с вашей точки зрения это очень аккуратно и лаконично, иногда это может повредить читабельности для того, кто не имеет контекста инженера, вступающего позже в игру.
Коди:
Итак, говоря о том, как это выгодно и почему нас это должно волновать, скажем, для кого-то, кто является владельцем продукта или заинтересованным лицом в компании:
Крис:
Итак, заинтересованные стороны, это похоже на то, о чем они, вероятно, захотят позаботиться. Им нужен качественный код, а не код, который работает.
Коди:
Да.
Крис:
Итак, как заинтересованные стороны приходят к этому и почему, по вашему мнению, они будут заботиться о такого рода вещах?
Коди:
Я думаю, главная причина заключается в том, что вы можете быстро выполнять задачи с помощью быстрого и грязного кода, именно к этому мы и пришли. Потому что, очевидно, мы хотим, чтобы все было сделано настолько быстро, насколько это возможно. Но причина, по которой вы хотите, по крайней мере, немного подумать и немного вложиться в этот аспект качества кода, а именно в комментарии, хорошую структуру и все вышеперечисленное, заключается в том, что ваш код должен быть рассчитан на будущее. для собственных инженерных команд.
Коди:
И, скорее всего, когда-нибудь в будущем вам придется сказать своим ребятам, чтобы они вернулись к области кода. И когда они это сделают, если это было сделано быстро в начале без комментариев, это просто слеплено вместе, это займет экспоненциально больше времени для каждой функции, которую вы накладываете поверх этой области.
Коди:
Так что вы будете часто, и я видел это много раз как в контрактах, так и в проектах, которые мы унаследовали, когда кому-то нужно выполнить простую, простую задачу. Типа: «Эй, ты можешь отредактировать заголовок на этой странице?» Или что-то похожее на это. Ничего особенного.
Крис:
Конечно.
Коди:
И из-за устаревших решений, вещей, которые произошли до того, как текущая команда разработчиков программного обеспечения коснулась этого, и все было собрано воедино, это в конечном итоге занимает гораздо больше времени, чем ожидалось, и никто этому не рад.
Крис:
No.
Коди:
Потому что, очевидно, это что-то вроде: «Ну что, программисты плохие?» Или: «Это из-за причин XYZ?» И в конечном счете, это потому, что быстрые решения по коду были приняты раньше, и теперь вы платите ему за это позже. Таким образом, вы можете выбрать большую стабильность продукта, зная: «Да, эти вещи займут немного больше времени, потому что у нас есть некоторые методы, которые мы должны использовать для поддержания высокого качества», но это будет предсказуемый процесс для реализации. на протяжении всей жизни проекта.
Коди:
Принимая во внимание, что вы можете сделать это быстро, и у вас будет более быстрый результат в начале, но он будет экспоненциально увеличиваться по мере того, как вы приближаетесь к долгосрочным аспектам проекта. И это становится непредсказуемым в том, как вы на самом деле будете планировать и учитывать время даже для самых простых функций.
Крис:
Попался. Итак, возвращаясь, похоже, что мы начали с кода, который работает, а не качественный код.
Коди:
Да.
Крис:
Этот качественный код, есть гораздо больше параметров, которые сопровождают выполнение качественного кода, в то время как код, который работает, это скорее «Он работает, но как долго и как далеко в будущем?» Очевидно, мы немного поговорили о множестве этих разных, я думаю, описательных факторов, которые встраиваются в качественный код, но давайте их изложим. Что именно вы ищете в коде качества? Мы коснулись их повсюду, но давайте составим маркированный список. Что вы ищете в качественном коде?
Коди:
Да. Итак, здесь будет несколько разных подразделов. Во-первых, это общие практики кода. Что было бы, вам нужны комментарии, очевидно. Вам нужна документация. Запишите, что происходит, и не ждите, что код будет документировать сам себя, потому что мы можем подумать, что даже инженеры-программисты попадают в эту ловушку, и я тоже виноват, но мы должны дисциплинировать себя, чтобы документировать то, что мы делаем. что мы делаем, особенно в сложных областях, потому что мы забудем наш собственный контекст. И я знаю, что возвращался к проектам спустя годы, и мне нужно было что-то коснуться и спросить: «Кто это написал?»
Крис:
«Кто написал этот материал?»
Коди:
"Это был я."
Крис:
Да.
Коди:
И оттуда вам нужно много документации, чтобы избежать этих сценариев. Так что это первая большая вещь, документация. Это очень просто.
Коди:
Следующая часть, очевидно, чистая, и большая ее часть — это краткое фактическое структурирование кода. И внизу в том же подразделе, но очень большом, я называю его нечеткой областью, находится архитектура. Иметь кого-то, кто имеет опыт работы с любой парадигмой или платформой, которую вы используете; Python, Django или Node.js, что-то в этом роде, иметь кого-то, у кого есть опыт, чтобы знать, что может пойти не так, если вы спроектируете что-то неправильно в начале, и как этого избежать — невероятно важный аспект. Пожалуй, самый важный аспект.
Крис:
Хорошо.
Коди:
Потому что небольшие изменения кода, документация — это вещи, которые со временем можно исправить, если они были сделаны неправильно в начале. Архитектура иногда означает полную перестройку, означает повторение всего проекта, и никто не хочет участвовать в этом сценарии.
Крис:
Нет, определенно нет.
Коди:
Да. Итак, это всего лишь пара-тройка моментов о том, как поддерживать достойный код в первом разделе. Но второй подраздел — практики разработки.
Крис:
Хорошо.
Коди:
Такие вещи, как непрерывная интеграция, то есть каждый раз, когда кто-то делает какую-то функцию, немедленно тестирует ее. Не ждите, пока эта веха будет пройдена, протестируйте ее сейчас. Как можно чаще, как можно чаще, чтобы мы знали, что происходит, и могли решить это, пока проблема невелика.
Крис:
Попался. Хорошо.
Коди:
И затем следующей функцией, которая будет связана с непрерывной интеграцией, будет автоматическое тестирование. Это всегда отличный аспект улучшения кода. Пишите вещи, которые подтверждают, что это работает. Это довольно хороший аспект, и, вероятно, одна из наиболее важных частей этого.
Коди:
И, наконец, последнее одеяло, опять же, еще один качественный нечеткий аспект, очень похожий на то, что было в первом разделе для разработчиков, просто общая дисциплина разработчиков, идея ведения согласованных журналов коммитов, точного маркирования веток функций, документирования в тикетах в ваш пакет управления проектами. Именно такие вещи приводят к хорошему коду, что кажется нелогичным, потому что это метаинформация кода, а не код.
Крис:
Конечно.
Коди:
Но иметь все это в качестве основы и лесов, поддерживающих проект, который в противном случае был бы просто чем-то вроде голых лесов, повторяю это слово, это невероятно важный аспект. И я думаю, что это зависит от управления проектом, от разработчиков, от всех участников. И, конечно же, инженеры-программисты должны выполнить обещание этой дисциплины и на самом деле выполнить ее. Это действительно важный аспект.
Крис:
Это классно. Так что, очевидно, мы много коснулись этого. Любые заключительные мысли и закрытие на этом? Стандарты кода, PEP8? Я ничего не знаю о…
Коди:
Я думаю, что важно не упоминать слишком много конкретных деталей, потому что, в конечном счете, каждый проект уникален и отличается, и это то, что, я думаю, может быть получено от любого, кто будет старшим разработчиком или техническим директором, у которого есть некоторый опыт в реальной работе над проектом. , за проект.
Коди:
Кроме того, все это не является конкретным. Нет стопроцентного списка, которому должен следовать каждый проект. Это зависит от того, как быстро вам нужно ехать. Если это проект, в котором вы не заботитесь о его долгосрочных аспектах, и вам просто нужно что-то вроде быстрого и грязного микросервиса, потому что вам нужно временное решение, многие из этих вещей не будут применяться.
Крис:
Понятно.
Коди:
Но это очень масштабируемо. И если вам нужно что-то надежное корпоративного уровня, вы захотите следовать этим методам. Итак, просто подытоживая все вышесказанное, скажу, что когда речь идет о качественном коде по сравнению с быстрым кодом, вы можете либо заплатить позже, либо заплатить сейчас, но время будет оплачено за код-
Крис:
Несмотря ни на что.
Коди:
Несмотря ни на что, да. Будь то быстро или качественно, в конечном итоге все будет очень похоже. Разница в том, что высококачественный код будет иметь предсказуемый путь выполнения и завершения…
Крис:
И финансовый.
Коди:
И финансовый, конечно.
Крис:
Предсказуемость.
Коди:
Потому что время - деньги, верно?
Крис:
В конечном счете.
Коди:
И быстрый код запустится быстро и со временем будет увеличиваться. И это просто природа планирования и выполнения чего-либо сложного. Если у вас был инженерный проект, и вы не обязательно планировали и только начали собирать двигатель, к тому времени, когда вы все соберете вместе, это, вероятно, будет очень сложно.
Крис:
Это будет очень плохо.
Коди:
Да. Итак, следует той же идее. И с этим, это все, что у меня есть.
Крис:
Прохладный. Я люблю это. Ну, цени свое время, Коди. Я думаю, что это имело большой смысл и выдвинуло действительно хороший аргумент, почему то, что ваш код работает, не обязательно означает, что он имеет высокое качество.
Коди:
Правильный.
Крис:
Ага.
Александра:
Большое спасибо, что присоединились к нам в этом выпуске Bixly Tech вторник, где Коди и Крис говорили о том, как вы определяете качественный код? Что вы ищете, и каковы некоторые из атрибутов помимо Это работает? этот код должен быть частью вашего продукта для конечных пользователей. И не забудьте проверить специальные ссылки, которые у нас есть для вас в описании ниже. Вы можете найти ссылку на наше Руководство по бесплатному пользовательскому программному обеспечению, которое проведет вас через этапы планирования вашей собственной идеи пользовательского приложения, будь то для Интернета или мобильных устройств, или для того и другого, как бы ни выглядело ваше решение. Вы также можете посетить наш веб-сайт Bixly.com. А в самом верху нашего веб-сайта есть кнопка с надписью Подтвердить идею вашего приложения. Если вы нажмете на нее, вы сможете запланировать бесплатную встречу с Крис. 60 минут на обсуждение идеи вашего приложения, и мы укажем вам правильное направление. До следующего раза, это был эпизод Bixly Tech вторник вторник.
Первоначально опубликовано на https://blog.bixly.com 31 августа 2021 г.
