Когда «правильное» программирование больше не имеет значения?

49

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

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

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

for(int i = 0; i < items.length; i ++)
{
    // do something
}

Я знаю, что он оценивает item.length на каждой итерации. Тем не менее, я также знаю, что предметов никогда не будет больше, чем 15-20 предметов. Так стоит ли мне оценивать items.length на каждой итерации?

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

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

Кай Цин
источник
4
Это вопрос величин. Попробуйте создать мультитерабайтные базы данных, предназначенные для реального мира, с поиском и агрегацией за секунды, с тысячами запросов в минуту. Ваша проблема недостаточно велика. Хотя ваш подход хорош, если вы идете по этому пути к его неизбежному выводу, он является болезненным и требует времени.
Джимми Хоффа
8
Если бы у вашего языка был настоящий цикл FOR, такой проблемы с множественной оценкой не было бы. К сожалению, синтаксис C требует этого, потому что на самом деле это не цикл FOR; это петля WHILE в парике и очках с большим носом, и для завершения петли требуется принять любое произвольное условие (или его вообще нет).
Мейсон Уилер
2
Я вижу ваши изменения, но если вы пытаетесь доказать, что пьянство и безрассудство - это нормально в любом контексте, кроме вечеринок в пятницу вечером с назначенным водителем, вы, вероятно, лаете не на то дерево.
Роберт Харви
17
Откуда вы знаете, что он «оценивает» item.length на каждой итерации? Компиляторы довольно умные. И даже если он многократно выбирает item.length, ну и что? Я бы не хотел видеть код вроде 'int itemsLength = items.length; for (; i <itemsLength; ...) ', если не было проблемы с измеренной производительностью.
Кевин Клайн
6
Ваша вещь items.length абсолютно не связана с «правильным программированием». Это микрооптимизация, и хорошие программисты знают лучше, чем тратить время на них, пока не запустят профилировщик и не поймут, где реальные проблемы с производительностью. Микро-оптимизации и хороший стиль программирования часто являются противоположностями, а не одним и тем же.
Майкл Боргвардт

Ответы:

65

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

Вот и все.

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

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

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

Так что, как и во многих других аспектах разработки программного обеспечения, все зависит от ситуации.

Роберт Харви
источник
1
Я склонен согласиться. На работе я не задаю вопросов, это перечеркнуто и усеяно. Но учтите, что многие вещи, которые я делаю для работы, - это те вещи, которые действительно не нужно поддерживать. Проходящий тренд, такие вещи. Приложения на день рождения, вещи, которые приходят и уходят. Все правильно, но они действительно не должны быть.
Кай Цин
21
Можно привести аргумент в пользу того, что дисциплина в любое время облегчает дисциплину, когда вам нужно. Некоторые люди задают вопросы о переполнении стека, даже не нажимая клавишу Shift, используя обоснование того, что они могут адекватно передать свои идеи без него, и что английский язык в любом случае изменчив и развивается. Я не нахожу ничего более раздражающего, кроме, возможно, авторов вирусов, которые думают, что мое процессорное время свободно.
Роберт Харви
2
@KaiQing Кто-то должен передать вам унаследованное приложение 5mloc, которое было создано на языке паскаль и перенесено вперед с тех пор, как при первой попытке добавить или изменить какие-либо функции в этом приложении вы сразу поймете, почему существуют лучшие практики, и просвещаетесь.
Джимми Хоффа
5
@KaiQing, Angry Birds должен работать на нескольких платформах, и если игра зависает на 2 секунды, x% аудитории откажется от нее, что означает, что у людей из Angry Birds будет меньше долларов. Бьюсь об заклад, это было написано очень, очень тщательно. Может быть, это отвечает на ваш вопрос. Если код только для вас, кого волнует, что вы делаете? Если на карту поставлено время или деньги других людей, то лучше быть очень, очень осторожным.
Чарльз Э. Грант
2
@ KaiQing Никто не может сказать вам порог для этого, он меняется от проекта к проекту и по каждому проекту с течением времени. Число переменных, которые влияют на порог между обслуживаемостью системы и не зависят от нее: LOC, База пользователей, База разработчиков, Тип приложения (криптография против Crud против драйверов), Надежность функций, Требования к резервированию, Критичность программного обеспечения (сервер электронной почты и устройство жизнеобеспечения и виджет часов), поддерживаемые платформы, технологический стек, объем передаваемых или анализируемых данных, исторические ограничения аудита и многие другие факторы влияют на то, насколько плохим может быть код
Джимми Хоффа,
18

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

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

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

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

Майкл Шоу
источник
Я бы не сказал, что предпочитаю второе. Кто-то отредактировал мой пост, чтобы удалить часть о том, что я делаю эту игру для Android почти полностью пьяной (просто для удовольствия), и в результате я удивлен, увидев, что мой пьяный выбор не повлиял на производительность. Я заменил некоторые странные классы на подходящие для тестирования. Я согласен с тем, что знать, что правила существуют, важнее, чем знать, что это за правила ...
Кай Цин
Кроме того, моя идея «правильного» программирования является кульминацией повторяющихся мнений сообщества stackoverflow, а также набора программистов, которые приходят и уходят в фирме, в которой я работаю. Некоторые со степенями CI, некоторые самоучки. Существует общее мнение, на котором основываются вещи, и я склонен согласиться с тем, что все говорят вместе, прежде чем просто решить, что один путь правильный, а другой - неправильный. Спасибо за участие.
Кай Цин
1
Если это звучало так, как будто я говорил вам, что вы нарушаете правила, то я плохо сформулировал это. Ничто из того, о чем ты говорил, не является тем, против чего я бы возражал. Я пытался указать, что «дух закона» важнее, чем «буква закона».
Майкл Шоу
Хех, нет, я не думал, что ты мне это рассказываешь. Я просто общался. Я задал этот вопрос по причине, и я рад, что многие ответили, не проголосовав, он был закрыт.
Кай Цин
10

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

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

Можете ли вы сделать экономическое обоснование для items.lengthвыхода из forцикла? Экономически, может ли это изменение оправдать время, потраченное на его оправдание? Поскольку пользовательский интерфейс не имеет различий, вы никогда не получите ничего даже за время, потраченное на измерения (кроме полезного урока для запоминания). Пользователям не понравится программа больше, чем они, и больше копий не будет продано, в результате этого изменения.

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

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

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

Kaz
источник
Очень хорошо написано. В моем случае никогда не было запланированного возвращения. Любое возвращение может быть случайным, но не должно быть отклонено, так как я думаю, что некоторые из самых больших успехов начались как случайности. С точки зрения клиентской работы, когда на карту поставлено не так много денег, как возможное обострение, если приложение зависает или что-то становится незначительным неудобством, это более толстый порог. Если тесты выглядят хорошими, но код, как известно, не самый эффективный, то никто никогда не придет, чтобы провести его аудит до наступления времени выполнения кода и, возможно, потребовать какой-либо миграции ... трудно сказать по этому поводу.
Кай Цин
На самом деле. Мы не всегда можем сделать что-то объективное. Не все оценивают программу одинаково. Предположим, что основной утилитой программы является удовольствие от работы над ней. Это может быть бесполезно ни для кого другого, и никто не будет платить за улучшения (даже если есть пользователи, кроме программиста), но этого достаточно, чтобы оправдать его улучшение каким-либо образом.
Каз
Два полезных слова, которые нужно добавить к своему очень хорошо написанному ответу - «Спекулятивные инвестиции» - вы делаете это, потому что вы предполагаете, что в будущем будет возвращение.
Mattnz
@mattnz - то, что вы говорите, правда в том, что никто не делает что-то без возврата, даже если возвращение - хороший смех. Почти все мои личные проекты сделаны для юмора. Почти все они зарабатывают достаточно, чтобы оправдать свои требования. Ни один из них не позволил мне выйти.
Кай Цин
Точно, все. Итак, сначала мы определяем, что мы надеемся получить от написания этой программы или продолжения этого. Это может быть что-то вроде «скоротать время так, что это весело». Но даже тогда мы можем подумать: работать над такими-то и такими-то вещами в такой-то и такой-то программе - лучший способ добиться наибольшего удовольствия, или мы тратим время на что-то другое.
Каз
3

Когда вы не должны заботиться о том, чтобы ваш код был «правильным»

  • Если вам удастся ответить на поставленную бизнес-цель и сохранить ее с течением времени с минимальными накладными расходами. (пользователи не видят источник, пока не заплатят вам)
  • MVP / POC - Если написание правильного кода означает трату времени на концепцию, прежде чем вы узнаете, как заработать на ней деньги (если вы тратите годы и 45 миллионов долларов на написание своего приложения и заканчиваете тем, что закрываете магазин, потому что у него нет рынка, никого не волнует, как правильный был код)
  • Когда возникла опасная для жизни ситуация (например, прототип 1 железного человека был грязным хаком, но он вытащил его из пещеры, верно?)
  • или если вы просто не знаете, как писать надлежащий код (если Сомене удается зарабатывать на жизнь написанием ненадлежащего кода, я говорю, что при сегодняшней безработице лучше писать плохой код, чем быть бездомным)
  • если вы просто знаете, что делаете, или думаете, что можете сойти с рук, делая вид, что делаете

Когда писать правильный код

  • Если это окажет значительное влияние на бизнес, например, производительность повлияет на выручку или предотвратит продажи
  • Если это не правильно, то поддержание кода становится проблемой бизнеса (высокие затраты на обслуживание)
  • Если вы известный программист, работающий над большим проектом с открытым исходным кодом
  • То же самое для большой компании, которая вносит свой вклад в мир собственной библиотеки.
  • Если вы хотите показать свою работу в качестве портфолио в будущих интервью
Эран Медан
источник
1
К сожалению, есть еще один из них, который не заботится о том, чтобы составить правильный список, о котором многие люди не знают: когда клиент рвет старую систему на ваше попечение и говорит вам, что он должен сделать это через неделю. Иногда время и / или бюджет не поддаются правильному кодированию, и ваше внимание к проекту является скорее изяществом, чем бизнес-транзакцией. Например, если их код использует в значительной степени устаревшие методы, но нуждается в некотором исправлении (выступая в веб-сценарии). Не могу все исправить. Должен испачкаться.
Кай Цин
«Если это не так, то обслуживание кода становится бизнес-проблемой (высокие затраты на обслуживание)». Этот порог на самом деле значительно ниже, чем склонны верить большинству неопытных разработчиков. Написание твердого кода часто окупается в течение нескольких часов, а не дней или месяцев.
PeterAllenWebb
2

Является ли производительность вашей главной заботой? Это то, что вы пытаетесь максимизировать?

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

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

Это угадывание. Все это делают, но это не работает.

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

Вы видите разницу?

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

Ваш вопрос: "Пока работа выполнена, мне все равно?"

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

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

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

Дэн Перкинс
источник
1

Ответ в том, что это никогда не имеет значения, и это всегда имеет значение ....

Это никогда не имеет значения, потому что программирование, правильное или нет, это способ достижения цели, а не цель сама по себе. Если эта цель достигается без «правильного» программирования, это нормально (с точки зрения бизнеса часто лучше, если цель может быть достигнута без программирования).

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

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

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

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

jmoreno
источник
1
«никогда» и «всегда» отменяют друг друга. Делать ваш ответ и хорошим, и плохим.
Тулаинс Кордова
@ user1598390: их взаимное уничтожение было смыслом. Отмените догму, и вы останетесь с тем, что кажется полезным. И вы поймете это неправильно и извлечете уроки из этого.
Jmoreno
Я хочу сказать, что согласен с вами, но я бы не довел это до таких крайностей. Я не думаю, что некоторые из них часто просто выплевывают, избегая тестирования или отладки. Просто потому, что он не оптимизирован и идеально разработан, не делает его ничем менее продуктом, если на производительность и стабильность не влияет короткое время. В конечном счете, это моя точка зрения и почему я удивляюсь, почему все так воняют над примерами кодирования, которые не являются главными. Это часто случается в стеке.
Кай Цин
@KaiQing: тестирование и отладка происходят, конечно, но, как правило, ограничиваются тем, что существует в данный момент - например, если процесс может завершиться неудачей с файлом, который имеет кодировку UTF, и ни с одним из файлов, над которыми вы фактически работаете не проверяй Оптимизацию следует проводить, когда обнаружена проблема с производительностью. Что касается того, почему воняет не поверх примеров линейного кодирования на SO - я думаю, что это является функцией целей сайта. Он стремится быть постоянным ресурсом, поэтому код в ответах (и даже в вопросах) рассматривается так, как если бы они были шаблоном, который используют другие.
Jmoreno
1

Или даже что-то тривиальное, как это:

for(int i = 0; i < items.length;i ++) {
     // do something 
}

Я знаю, что он оценивает item.length на каждой итерации. Тем не менее, я также знаю, что предметов никогда не будет больше, чем 15-20 предметов. Так стоит ли мне оценивать items.length на каждой итерации?

На самом деле в конечном коде items.length не будет оцениваться на каждой итерации, потому что компилятор оптимизирует его. И даже если это не так, длина является открытым полем в объекте массива; доступ к нему не стоит.

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

Это действительно зависит от того, что вы ожидаете от конечного продукта; разница между средним продуктом и отличным продуктом основана на деталях. Автомобиль, подобный Tata Nano, и автомобиль, подобный Mercedes S, «справляются с работой» - они доставляют вас из одного места в другое. Разница заключается в деталях: мощность двигателя, комфорт, безопасность и другие. То же самое с любым существующим продуктом, включая программные продукты; например, зачем кому-то платить Oracle, IBM или Microsoft за базу данных Oracle, DB2 или MS SQL Server, поскольку MySQL и Postgre бесплатны?

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

m3th0dman
источник
Я не думаю, что я согласен с этим, хотя В своем посте я не упоминаю никакой разницы в производительности. Это предполагает, что нет среднего или отличного продукта, но есть равный баланс, несмотря на недостатки одного. Однако я бы согласился с вашим утверждением, если бы был какой-то конкретный проект, имеющий большое значение, который мы все использовали для сравнения. Но абстрактно, общее наблюдение состоит в том, что в этом анонимном проекте решительно неэффективный класс работал в равной степени с оптимизированным. Так что же, нормально относиться к этому вяло или спорить о совершенстве каждый раз?
Кай Цин
@ Кай Цин Один класс не имеет (или не должен) иметь большое значение. Я сказал это: если вы ожидаете, что ваш продукт будет высококачественным, то обратите внимание на детали (даже если это означает возможную небольшую оптимизацию или тщательный дизайн); с другой стороны, если единственное, что вам нужно, - это функциональная система, то, вероятно, вам не следует обращать особого внимания на мелкие детали.
m3th0dman
Да, вы правы, это не должно иметь никакого значения, даже если в его дизайне уделяется немного внимания. Но это может иметь значение в зависимости от его цели или если вообще его цель изменилась со временем и стала чем-то, для чего она не была предназначена. Видел это раньше, но я просто собираюсь касаться здесь. Чтобы быть справедливым, продукт может быть высокого качества без необходимости быть более функциональным.
Кай Цин
1

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

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

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

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

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

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

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

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

Брайан Оукли
источник
Я сталкивался с примерами в программировании, когда код не нуждался в поддержке или выполнении вне потребностей. Как утилиты для киосков для торговых выставок или событий, которые очень специфичны и вряд ли будут использоваться повторно. В случае с моей собственной игрой - я единственный, кто ее поддерживает, поэтому этот аргумент может оказаться не самым подходящим. У меня все еще есть сомнения относительно общего взгляда на «лучшего программиста», потому что строгое соблюдение руководящих принципов, ремонтопригодность и правильное использование типов данных может быть достаточно разочаровывающим, чтобы не завершить проект. Если код работает должным образом, зачем его совершенствовать?
Кай Цин
Даже если программное обеспечение, которое вы создаете right_now , не нуждается в обслуживании, написание программного обеспечения, как будто оно укрепляет ваши навыки кодирования. Когда вам, наконец, придется писать поддерживаемый код, вы сможете сделать это проще.
Брайан Оукли
Я должен писать поддерживаемый код все время. Просто в некоторых случаях это не должно быть. Тем не менее, у меня достаточно опыта, поэтому я обычно знаю, когда и где срезать углы. Смысл этого поста состоял в том, чтобы просто разжечь разговор о пороге правильности и неаккуратности для каких-либо целей. Мой пример лишь слегка затрагивает его, поскольку приведенный пример в большинстве случаев безвреден. Однако, если бы я писал программное обеспечение для банка, я никогда не был бы таким беспечным.
Кай Цин