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

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

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

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

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

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

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

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

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

Вот и все.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 бесплатны?

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

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

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

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

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

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

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

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