Как быстрые и грязные программисты знают, что они поняли это правильно?

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

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

Код, вероятно, не прав.

Однако это может не иметь значения.

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

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

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

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

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

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

Ладно, рискуя быть приманкой, я собираюсь «защищать дьяволов» противоположной точки зрения.

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

Любой, кто был в этом бизнесе некоторое время, вероятно, согласился бы, что можно было бы возиться с частью программного обеспечения более или менее бесконечно. Duke Nukem Forever, мои друзья. Наступает время, когда эту замечательную функцию или такую ​​срочную работу по рефакторингу просто необходимо отложить и эту штуку следует называть ГОТОВО.

Я боролся с коллегами по этому поводу много раз. ВСЕГДА есть еще один твик, что-то еще, что «должно» быть сделано, чтобы оно было «правильным». Вы всегда можете найти это. В какой-то момент в реальном мире достаточно хорошего, просто должно быть достаточно хорошо. Никакое реальное, актуальное, отгрузочное программное обеспечение не является идеальным. Никто. В лучшем случае это достаточно хорошо.

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

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

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

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

И давайте посмотрим правде в глаза, скорее всего, вы не. Я сам знаю, что нет. У меня были редкие моменты течения - и бесчисленные часы скорби и печали, обычно вызванные моими собственными ошибками. Лучше быть честным и реалистичным. На самом деле, я считаю, что величайшие программисты полностью осведомлены о своих ошибках и прошлых ошибках, поэтому они сознательно выработали привычку дважды проверять свои предположения и писать эти маленькие модульные тесты, чтобы держать себя в безопасности. ( «Я не большой программист - просто хороший программист с хорошими привычками». - Кент Бек.)

Модульные тесты . Это единственный способ быть уверенным в любом коде (грязном или нет).

На боковой ноте;

короткие сокращения делают для длительных задержек (Пиппин)

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

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

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

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

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

Вот история о быстром и грязном программисте, которого я знаю.

Я знал человека, который считает, что юнит-тесты - пустая трата времени. После долгих споров он наконец написал один. Он состоял из одного длинного метода, посыпанного && и || и вернул логическое значение assertTrue. Заявление охватывает 20 строк. Затем он написал класс, в котором у каждого метода была одна строка, а у основного - более 1000 строк без пробелов. Это была стена текста. Когда я просмотрел его код и вставил несколько новых строк, он спросил «почему». Я сказал «Из-за читабельности». Он вздохнул и удалил их. Он положил комментарий сверху "Не трогай это, это работает!"

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

Кроме того, он считает, что чтение книг и блогов по программированию бесполезно. Он говорит: «Просто начни программирование». Он сделал это в течение 12 лет, и он думает, что он отличный программист. / Facepalm

Вот еще немного.

В другой раз мы писали класс DatabaseManager для нашего веб-приложения. Он положил все вызовы базы данных в нем. Это был урок Бога с более чем 50 методами для всех мыслимых вещей. Я предложил разбить его на подклассы, потому что не каждый контроллер должен знать о каждом методе базы данных. Он не согласился, потому что «просто» было просто иметь один класс для всей базы данных, и «быстро» было добавлять новый метод всякий раз, когда он нам нужен. В конце концов, в DatabaseManager было более 100 открытых методов от аутентификации пользователя до сортировки мест расположения археологических раскопок.

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

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

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

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

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

Продукт поставляется.

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

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

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

Лично я бы не стремился развить навык «написания грязного кода» и быть уверенным в его правильности. Я предпочел бы написать правильный код в первый раз.

Откуда они знают, что поняли это правильно? Тестирование - это простой ответ.

Если их код был тщательно протестирован хорошей командой QA, и он прошел, то я бы сказал, что они правильно поняли.

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

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

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

Конечно, как показывает этот образ, никто не должен недооценивать опасность быстрого и грязного кода!

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

На мой взгляд, научиться оценивать правильность кода Q & D не стоит развивать навык, потому что это просто плохая практика. Вот почему:

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

Изучение исходного отчета CHAOS ясно показывает, что Q & D не очень хорошая идея, и это приведет к сокращению бюджета позже (либо в процессе обслуживания, либо во время расширения). Научиться оценивать правильность кода Q & D - пустая трата времени. Как сказал Питер Друкер: «Нет ничего более бесполезного, чем эффективно делать то, чего не следует делать вообще».

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

«Грязный» означает разные вещи для разных людей. Для меня это в основном означает полагаться на вещи, на которые вы, вероятно, не должны полагаться, но на которые вы также знаете, что можете рассчитывать на работу в ближайшем будущем. Примеры: предполагается, что кнопка имеет высоту 20 пикселей вместо вычисления высоты; жесткое кодирование IP-адреса вместо разрешения имени; рассчитывает на массив, который будет отсортирован, потому что вы знаете, что это так, хотя метод, который предоставляет массив, не гарантирует этого.

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

Рискуя казаться немного спорным, я бы сказал, что никто по-настоящему НЕ ЗНАЕТ, что их код на 100% правильный и на 100% без ошибок. Даже если у вас действительно хороший охват тестированием и вы строго применяете хорошие практики BDD / TDD, вы все равно можете разработать код, содержащий ошибки, и да, который может даже содержать побочные эффекты!

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

Важным моментом является то, что хорошо продуманный и хорошо протестированный код позволит ДРУГИМ быть уверенными в вашем коде, что в большинстве случаев важнее, чем ваша собственная уверенность.

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

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

Так почему же существуют так называемые программисты Quick & Dirty? Моя гипотеза - дарвиновский отбор. Программисты, которые быстро отправляют работоспособный код, иногда отправляют до того, как отправят соревнования, или бюджет заканчивается, или компания обанкротилась. Поэтому их компании все еще работают, нанимая новых программистов, чтобы жаловаться на беспорядок, который необходимо устранить. Так называемый «чистый код» также поставляется, но не настолько дифференциально, чтобы привести к исчезновению кодеров Quick & Dirty.

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

1-) Проект становится больше, а мотивация команды снижается, работая над кодом, полным «стежков». В этом случае проект, скорее всего, переместится в сторону хаоса.

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

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

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

Мы также должны принять решение на основе времени + вместимости + приоритетов в списке. Хорошее обсуждение в команде с пожилыми людьми или людьми с более высоким опытом может помочь принять решение, которое наилучшим образом соответствует команде и ее результатам.

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