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

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

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

164 голоса | спросил Karl Bielefeldt 1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

21 ответ


99

Возможно, код неправильный.

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

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

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

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

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

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

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
238

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

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
103

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

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

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

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

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
84

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

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

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

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

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

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
33

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

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

  

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

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
15

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

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

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
11

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

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

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

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
9

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

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

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

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


Вот еще несколько.

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

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
7

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

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

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

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
6

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

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

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
5

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

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

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
5

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

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

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

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
5

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

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

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

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

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

Конечно, поскольку это изображение демонстрирует, никто не должен недооценивать опасность быстрого и грязного кода! введите описание изображения здесь>> </p></div>
					 
						<div class=

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
4

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

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
4

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

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

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

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
3
  

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

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

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

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
3

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

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

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

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
2

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

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
2

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

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

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
0

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

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

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

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

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28
0

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

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

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

ответил Greg 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 00:17:28 +0300 2016, 00:17:28

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132