Andrei Solntsev
Что на самом деле нельзя хардкодить
Хардкод
Но я утверждаю, что хардкод в привычном нам понимании вовсе не так уж страшен, и на самом деле гораздо страшнее, когда в коде прописывают кое-что иное.
Так что же на самом деле нельзя хардкодить?
Классический хардкод
Все обычно считают, что
Давайте разбираться в причинах
А почему плохо прописать в коде “23”?
Обычно называют две причины. Их втирают нам в сознание ещё с университетской скамьи.
Почему эти причины не катят?
Эти причины настолько нам привычны, что мы даже не задумываемся, насколько они актуальны в наше время. Вы удивитесь, но не очень-то актуальны. Прямо скажем, они устарели. Смотрите сами.
Да, “23” плохо читается. Но часто при вынесении в константу оно не становится более читаемым. Да, название константы MINIMUM_LOAN_AGE говорит о том, что это минимальный возраст, с которого можно брать кредит. Но и выражение if (age >= 23) в методе canRequestLoan() говорит ровно о том же ничуть не хуже.
Ладно, ладно
Я знаю, вас переполняют эмоции. Вы хотели бы вбить мне в грудь осиновый кол за такую ересь. Но потерпите, сейчас мы дойдём до главного.
Конечно, всё-таки выносить такие штуки в константы иногда полезно.
Но самое страшное, что в коде могут быть и выражения вида
и даже такие места, которые совсем нереально обнаружить:
Что же делать?
И все остальные места должны использовать этот метод. Кажется тривиальным? О нет. Если это знание действительно в одном месте, зачем вы так рьяно хотите вынести “23” в константу?
Упростим
Всё ещё кажется тривиальным? Ок, давайте упростим пример. Забудьте 23. Пусть будет 0.
Я уверен, в вашем коде миллион таких мест:
И я таких видел миллион. if balance > 0 прописан и на странице платежей, и на странице кредитов, и депозитов, и т.д.
Но однажды приходит новое требование: клиент не может сделать платёж, если на его счёт наложен арест. Нам приходится добавить условие типа такого:
Я не придумываю, это абсолютно реальный пример.
Юнит-тесты
Поначалу этот тест кажется даже избыточным и даже бесполезным:
Но всё меняется, как только добавляются ньвые требования:
Пэдж обжекты
Всё ещё кажется, что для разумных людей это очевидные вещи?
Что такое хардкод
– Алло, это хардкор?
– Алло, это харткот?
– Техническая поддержка, здравствуйте!
Время пришло. Пожалуй, да, настало время и этот одноименный анти-паттерн программирования, послуживший основой для названия нашей компании стал достоин отдельной статьи. Проведя небольшой опрос среди наиболее осведомленных клиентов, коллег, соискателей, что же они понимают под термином Хардкод (Hard coding), я получил множество самых неожиданных ответов. Удивительно, но оказалось даже сами разработчики не всегда понимают глубинный смысл хардкода, бывает, даже считают его некачественным кодом и более того путают с “говнокодом”.
Не будем отбирать хлеб у википедии, копируя определение хардкода (hard coding (англ.)), а поговорим о его практическом смысле и применении. Статья предназначена для людей далеких от программирования, поэтому на мой взгляд, проще всего понять смысл термина на простом пример (на котиках), насколько это возможно, не погружаясь в технические детали.
Речь, конечно же, пойдет о сайтах, решении повседневных задач. Но для начала, давайте определимся с критериями качества задач, чтобы разница в подходах была максимальна заметна. Ниже минимальный список требований, актуальный для любого проекта/задачи.
Стоимость разработки
Нет, здесь мы не будем говорить о ценообразовании, видах контрактов – это отдельная история. Сегодня я ваш капитан очевидность и со всей ответственностью заявляю: “Цена – это критерий номер раз”!
Сроки выполнения работ
Достойным продолжением в списке требований является конечно же – дедлайн. Задача должна быть выполнена в срок, пока ее не реализовали конкуренты или того хуже — идея морально не устарела и стала никому не нужна. Итог один – можно расходиться.
Результат должен в точности выполнять поставленную задачу в заранее оговоренных условиях. Иными словами, корректно работать.
Дальнейшая поддержка кода
Как говорится last but not least (последний, но от этого не менее важный), и к несчастью, чаще всего самый недооцененный фактор. А говорит он нам о возможности через полгода/год, без особого труда, продолжить работу с проектом и, что не менее важно, с новыми сотрудниками/техподдержкой/командой, в общем людьми, не принимавшими участие в разработке первых версий. Этот фактор актуален для более или менее объемных задачах, разработка которых, ввиду затраченных усилий, сроков и стоимости не позволяет выбросить результат в помойку, не задумываясь.
Хардкод «на котиках»
Представьте, у вас есть интернет-магазин, где все расчеты (купоны, акции, налоги, прайсы поставщиков, услуги доставки, т.д.) ведутся в рублях. И вот появляется задача проверить спрос на ваш ассортимент в ближайших странах-соседях, куда проще всего осуществить доставку. Для этого цены в магазине должны быть как минимум в долларах и евро.
Вы встречаетесь с рабочей группой для обсуждения деталей технического задания. Оказывается система управления вашего магазина не имеет готовых решений для использования нескольких валют и банк не предоставляет данные курсов валют в удобном формате, что обеспечивает многократное увеличение сроков и стоимости разработки. Что делать, надо спешить, пока никто еще не поставляет эти уникальные товары на зарубежные рынки, ведь так важно оказаться первым.
И вот, условно говоря, через два месяца, с новым магазином или доработанным старым вы получаете:
Но, к сожалению, слухи о высоком спросе на данный ассортимент разлетелась очень быстро и ваш магазин встал в очередь из ему подобных, да еще с ценой выше средней по рынку, т.к. появились дополнительные расходы на разработку.
Искренне сочувствую, если эта история вам знакома и напомнила о былых неудачах. Это как раз тот самый случай, где оптимальным решением может стать хардкод. А именно, конкретно в данном примере достаточно жестко, можно сказать прямо “в лоб”, прописать курс валюты непосредственно в коде или максимум с одним единственным полем для его ручного редактирования по мере необходимости, без автоматической интеграции.
Сплошная польза и очевидный профит.
Технически такое решение занимает на порядок меньше строк кода, задача выполняется в разы быстрее, стоит дешевле.
Очевидно для посетителей нет разницы, как это работает внутри, если они, как и прежде могут совершать покупки.
Дальнейшее сопровождение, доработки
Ввиду того, что мы говорим не о халатности, а об одном из вариантов подхода к решению задачи, я не рассматриваю случай, когда разработчик поленился оставить комментарии к внесенным изменениям после чего не понятно, с какой стороны подойти к еще недавно полноценному интернет-магазину. Значит ничто не мешает в случае успеха проверки вашей бизнес-гипотезы заменить несколько строк кода, обозначенных комментариями, для пересчета стоимости товара на более гибкое, функциональное решение.
В этом весь смысл правильного хардкода – когда его используют во благо. И как бы странно это не прозвучало, но хардкод может быть действительно качественным и эффективным решением. Если вы ограничены по времени или существует риск, что функция не будет востребована, то такой подход сэкономит вам значительное количество сил и средств. Ведь главное – это своевременно ответить на вопрос конечного потребителя, выполнить поставленную задачу, оправдать его ожидания.
3 греха программиста: Хардкодинг, Говнокодинг и Шизокодинг
Есть 3 проблемы кода, с которыми встречаешься в программировании: Хардкод, Говнокод и Шизокод.
Давайте поговорим об этом.
Хардкод
Это известная всем проблема, когда программист из-за спешки или лени пишет код без учета переменных. Пожалуй самый частый случай — домен сайта. Он может меняться от окружения к окружению и часто доставляет массу хлопот. Тут все просто. В разных платформах это решается по разному. Главное соблюдать соглашения и правила принятые в рамках платформы.
Обычно проблемы этого класса быстро обнаруживаются и легко лечатся.
Говнокод
Это более сложная проблема. Часто субъективная. Грубо говоря — это нарушение стиля кода, принятого в голове, команде или сообществе.
Есть разные стили кода в зависимости от платформы и даже иногда внутри платформы:
Это из мира php. В других сообществах ситуация похожая. Сюда же можно отнести истории про таб, таб через 2 пробела или таб через 4 пробела и т. д.
Здесь же возникает проблема чистого кода… например длинные функции на 3-4 страницы, что критикуется. Это не всегда конечно плохо, но часто можно такие функции сделать короче, разбить на ряд коротких функций, каждая из которых решает свою задачу.
Обычно эти проблемы легко лечатся через софт и контроль принятых стандартов в конкретной команде.
Высший пилотаж, когда разработчик может переключаться между разными стилями кода в зависимости от проекта.
Плохо когда разработчик нарушает стиль кода принятый в команде или считает свой любимый (часто единственно выученный) стиль кода единственно правильным.
Не бывает правильных стилей кода. Бывают утвержденные стили в команде или общепринятые стили.
Тоже относительно простая проблема и легко решаемая.
Шизокод
Вот это менее популярная проблема, но часто наиболее дорогостоящая.
Шизокод — происходит от понятия шизофрении. Выжимка из Википедии:
Шизофрени́я (от др.-греч. σχίζω «расщеплять», «раскалывать» + φρήν — «ум, мышление, мысль»), ранее лат. dementia praecox («слабоумие преждевременное») или схизофрени́я — эндогенное полиморфное психическое расстройство или группа психических расстройств, связанное с распадом процессов мышления и эмоциональных реакций.
Тут 2 важных тезиса: раскалывание и слабоумие. Которые являются причинам шизокода.
Идеальный код — тот который не написан. Шизокодеры не знакомы с этим понятием.
Если коротко то шизокод, это код, который нарушает принцип Бритвы Оккама.
Выжимка из Википедии:
«Бритва (лезвие) О́ккама» — методологический принцип, получивший название по имени английского монаха-францисканца, философа-номиналиста Уильяма Оккама. В упрощенном виде он гласит: «Не следует множить сущее без необходимости»
Выражается в том что разработчики начинают усложнять код и архитектуру без веских на то причин. Или вескость причин существует только в их воображении.
Есть 2 основных симптома: изобретение велосипедов на костылях и размножение слоев абстракции.
Изобретение велосипедов на костылях
Выражается в том что разработчики ввиду плохой способности обучаться вместо поиска оптимальных решений/методов в рамках платформы и существующей архитектуры начинают изобретать велосипеды/костыли.
Бесконтрольное размножение слоев абстракции: лишние классы, наследования, методы
Внимательный читатель мог заметить конфликт с говнокодом. В одном случае проблем в том что функция или класс слишком длинный, а тут проблема в том что возникает наоборот избыточное дробление сущностей.
Тут нужно отметить что это одна из крайностей, границу которой не всегда просто соблюсти.
С одной стороны плохо все пытаться решать одной функцией на 3 страницы или класс который содержит в себе HTML и механики шаблона и где-то выгоднее разбить код на несколько функций/классов/компонентов, каждый из которых решает свою задачу. Это одна крайность.
С другой стороны плохо простой код разбивать на 5 классов в каждом из которых 3-4 метода по 3-4 строки, со множеством бесполезных наследований, когда можно обойтись одним или двумя с минимальным наследованием или даже без наследования если этого можно избежать.
Последствия лишних и плохих абстракций
Размножение методов, классов, наследований без веских причин — это лишний код и рост слоев абстракции.
У всего есть цена, как и у лишних абстракций:
Проблема конечности мыслетоплива
Чем больше слоев абстракции, наследований, методов, тем больше нужно мыслетоплива для изменений, улучшений и диагностики проблем.
А рабочий объем мыслетоплива конечен и часто его нехватка влечет очень большие затраты на разработку.
Каждый разработчик, который делал диагностику и изменение шизокода упирался в дефицит мыслетоплива. Но не все это осознавали.
Видео, в котором объясняется что такое мыслетопливо и дается простое упражнение на 1 минуту, которое позволяет вспомнить ощущение дефицита мыслетоплива на простом примере:
Это наезд на ООП, классы и наследование?
Отнюдь. Однако доля правды в этом есть. В функциональном стиле проще наговнокодить, но шизокодить там сложно. ООП же с одной стороны дает множество преимуществ, но и открывает простор для шизокода.
ООП, классы и наследование — это не плохо и не хорошо. Это инструменты. Я лично их использую.
Однако у меня есть ряд собственных правил:
Резюме
Мы много говорим о хардкоде и говнокоде т.к. они понятны и легко осязаемы. А вот шизокод часто остается безнаказанным, птм что его сложнее выявить и понять объем вреда от него. А объем вреда от него возможно больше чем можно представить с наскоку.
Мой манифест простой:
Ну и буду рад комментариям как в поддержку манифеста, так и его критике.
ТОП-10 признаков плохого кода: хардкод и спагетти-код в примерах на JavaScript
Многие программисты не знают, что пишут плохой код.
Скорее всего, конкретно вы уже заходили на GitHub, сохранить свой код, посмотреть на чужой. А теперь посмотрите на собственные старые проекты, написанные годом ранее — вы удивитесь, насколько лучше стали ваши навыки с того момента.
Большинство младших программистов (и даже некоторые более опытные) не знают, как отличить хороший код от плохого. Когда программа заработает — они сразу идут дальше. К тому же, если они работают в одиночку, то никогда даже не узнают, что пишут плохой код.
Хорошо, что дост у пны возможности сознательно стать лучше, приложив немного усилий. Но сначала нужно правильно оценить и понять уровень качества собственного кода.
В руководстве пойдет речь о некоторых признаках, выдающих плохие практики в разработке программного обеспечения. Давайте же разберемся!
1. Повсюду скопированный код
Подобное случается с каждым программистом, стоит только перестать стараться писать чистый код.
Предположим, внутри класса или функции вы написали десять строк кода. Все в порядке. Теперь, в другом классе или функции того же проекта, вам нужно заново выполнить похожую задачу. Какова мгновенная реакция? Вместо написания отдельной функции для выполнения схожей задачи, вы скопируете десять строк кода и вставите их в новое место, словно заплатку.
Конечно, ведь всегда проще скопировать-вставить, чем написать функцию. Но вопрос состоит в том, когда подобный метод применим, а когда — только навредит кодовой базе?
Каждый раз, когда блок кода пригодился вам дважды — пишите с ним функцию. Подобный подход характеризуется рядом существенных преимуществ:
2. Одинаковые функции, но разный интерфейс
Постоянство — качество хорошего программиста: старайтесь следовать шаблону, ведь вам придется написать еще очень много функций.
Например, если в одном и том же проекте хранятся две одинаковые функции с разным поведением, то следующим программистам будет очень трудно читать ваш код. Предположим, что вы написали функции проверки некоторых данных профиля. Первая функция проверяет дату рождения пользователя, а вторая — его фотографию.
Приведенный пример достаточно прост, но то же самое относится ко всем функциям и методам вашего проекта. Если вы пишите непоследовательный код, то знайте, что это не профессионально. Пожалуйста, убедитесь, что коллегам-разработчикам легко прочесть ваш код!
3. Хардкод
Все ненавидят жесткий кодинг, “хардкод”. Хорошо, что его появление легко заметить и предотвратить. Проанализируйте следующий фрагмент кода:
Действительная необходимость в жестком кодинге случается крайне редко, так как все изменчиво, каждый аспект программы при желании можно изменить. В любой момент просто инициализируйте новую переменную, присвойте ей значение. Например:
Динамические приложения всегда лучше статических. Когда нужно менять какую-либо часть статического решения, то приходится каждый раз обновлять приложение.
Большинство проектов подключаются к облачным сервисам. Если ваши проекты синхронизированы с какими-либо из них, то лучше сразу получать данные из облака согласно его стандарту.
Некоторые программисты оставляют в кодовой базе хардкод на этапе тестирования, а потом ленятся исправить его на этапе производства из-за сроков и некоторых других причин. Но, пожалуйста, не поступайте так! В дальнейшем каждый экземпляр хардкода в проекте добавит вам еще больше давления и задач.
4. Слишком длинные и сложные условия
Определение достаточно абстрактное, так что же имеется в виду?
Во-первых, не стоит писать “ спагетти-код” — слишком конкретные и длинные условия со множеством проверок и категорий.
Тем не менее, второй совет — противоположность первого:
НЕ пишите сложные условия ради экономии в пару строк. Если вам придется написать две лишние строки, но код станет понятнее, то пишите эти строки с уверенностью. Проанализируйте следующие два примера:
Вложенные условия легко читаются (не всегда, но чаще всего). Применяемый с умом, такой подход поможет избежать неожиданного поведения функций и, следовательно, множества ошибок.
5. Велосипед вместо встроенной функции
Непонятно, почему до сих пор далеко не каждый разработчик на земле применяет встроенные инструменты и функции.
Если вам действительно нужно тратить свое время лишь на то, чтобы работодатель нанял побольше сотрудников для переработки вашего кода, то займитесь чем-нибудь другим. Пожалуйста, не наказывайте проект и разработчиков, в дальнейшем читающих ваш код.
В 99 из 100 случаев ваши функции с течением времени станут менее эффективными в плане времени выполнения и требуемой памяти. Не смотря на это, многие программисты даже не знают, что есть хорошая встроенная функция, но уже пишут свои.
Вот почему большинство старших программистов советуют начинающим и младшим специалистам поискать в Интернете лишние пять минут, прежде чем написать собственную функцию.
Самое приятное, что даже если вы не найдете встроенных функций, то узнаете, как решили задачу другие разработчики. Всегда помните, что написание кода — лишь одна часть работы программиста, нельзя забывать про важность чтения публично доступных наработок.
6. Игра в загадочные имена
Об опыте программиста можно судить по тому, как он называет функции и классы в своих проектах.
Вы догадались, что делает метод? Никто не догадался. Следовательно, следующий программист, прочитавший код, наверняка проклянет вас. Потому что ему, вероятно, придется вчитываться в каждую строчку функции, долго и постепенно понимая, что она делает.
Один из преподавателей курса снизил оценку за неправильное написание названия функции в лабораторной работе по Java.
Он поступил так, чтобы студенты в будущем запомнили важность именования.
7. Сплошь глобальные переменные
Локальная переменная существует не просто так, верно? Пожалуйста, избегайте глобальных переменных всякий раз, когда задача решается через локальные переменные.
Почему? Много причин для превалирования локальных переменных над глобальными. Поговорим о некоторых основных:
Если везде только глобальные переменные, значит, вы плохой программист. Извините за обидное, но правдивое высказывание.
8. Запутанный код
Иногда программистам нравится писать код сложным способом. Поверьте, подобное не сделает вас лучшим программистом на свете, несмотря на то, что многие старшие разработчики занимаются каким-либо хобби в области компьютерных наук, где они нестандартным образом все усложняют.
Однажды программист ответил, что запутанный код делает компанию зависимой от него — работа ему обеспечена.
Но это очень неправильная концепция, крайне вредная идея. Гораздо лучше руководствоваться следующим:
“Загадочность” — плохо. “Легкость” — хорошо.
Пожалуйста, не заставляйте коллег и сослуживцев страдать из-за вашего хобби или попыток выделиться за счет сложности понимания вашего кода другими людьми. Вы сэкономите другим разработчикам часы, если просто напишите элементарный, читабельный код.
Кроме того, игнорирование комментариев или отсутствие документации затрудняет понимание вашего кода сильнее, чем что-либо еще. Переусложненный код, как и последствия интеллектуального хобби, куда легче понять, если они детально задокументированы.
9. Взаимозависимые функции
Код весьма плох, когда функции выполняются исключительно в строгом порядке. Рассмотрим пример:
Функции работают независимо друг от друга.
Решением “на каждый раз” послужит специальный метод-шаблон. Рассмотрим пример на языке программирования JavaScript:
10. Нет понимания сложности алгоритма
Начинающие программисты часто пишут лишние вложенные циклы. Тем более, когда менталитет “ достаточно выполнить работу и запустить код” превращает программиста в неэффективного лентяя. Правда, производительность приложения — скорее дело привычки:
Когда команда не ценит хороший код и не заботится о качестве, то программисты не заботятся о временной сложности алгоритма и сложности алгоритма по памяти
Если вы разбираетесь в оценке сложности алгоритмов и пишете эффективный код — он даст вам силы, а если не обращаете внимание на детали реализации, то не сможете изменить шаблоны, остановившись в развитии профессиональных навыков.
Многие программисты даже не знают про “ сложность алгоритма по памяти” или “memory complexity”. Если вы не знаете, пожалуйста, узнайте, ведь это поможет на собеседованиях.
Выводы
Потребуется время, чтобы стать хорошим программистом, но чем дольше вы следите за качеством собственных проектов, тем чище и лучше становится ваш код. Не говорите себе, что со временем все само по себе изучится, но и ученым-ракетостроителем быть не требуется, чтобы написать хороший код.
hardcode
Смотреть что такое «hardcode» в других словарях:
hardcode — UK US (also hard code) /ˈhɑːdkəʊd/ verb [T] IT ► to put information into a software program so that it cannot be easily changed by a user: »If you hardcode table cells white, remember to hardcode the text inside them to black ideally, don t… … Financial and business terms
Hard coding — (also, hard coding or hardcoding) refers to the software development practice of embedding input or configuration data directly into the source code of a program or other executable object, or fixed formatting of the data, instead of obtaining… … Wikipedia
Space system — A space system, in most cases, is a hardcode or softcode system for a game server, in some cases a patch that may be added to the game s hardcode. A space system such as HSpace, for Hemlock Space, used on a PennMUSH game server, generally… … Wikipedia
MUSH — which was fundamentally a social game. MUSH has forked over the years and there are now different varieties with different features, although most have strong similarities and one who is fluent in coding one variety can switch to coding for the… … Wikipedia
Deltora series — The Deltora book series is the collective title for three series of children’s fantasy books, written by Australian author Emily Rodda. It follows the adventures of three companions as they journey across the magical land of Deltora, endeavouring … Wikipedia
Subtitle (captioning) — For other uses, see Subtitle. Part of a series on Translation Types … Wikipedia
Call of Duty: Modern Warfare 2 — Разработчик Infinity Ward … Википедия
Darius (серия игр) — Darius Жанр Горизонтальный скролл шутер Разработчик Taito Издатель Taito Платформы Аркадный автомат PC Engine NES Sega Mega Drive Super Nintendo Gameboy … Википедия
C++11 — C++11, also formerly known as C++0x,[1] is the name of the most recent iteration of the C++ programming language, replacing C++TR1, approved by the ISO as of 12 August 2011.[2] The name is derived from the tradition of naming language versions by … Wikipedia
Datasource — is a name given to the connection set up to a database from a server. The name is commonly used when creating a query to the database. The Database Source Name (DSN) does not have to be the same as the filename for the database. For example, a… … Wikipedia
