Написание вторичного кода

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

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

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

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

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

1. Стать мастером организации

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

2. Помните о том, что является «конкретным приложением», а что «общим»

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

3. Отдельный код от значений

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

4. Старайтесь не кодировать никакие значения, которые не обязательно должны быть

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

5. Избегайте ставить пробелы в именах файлов

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

5. Комментируйте все подробно

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

6. Избегайте создания зависимостей

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

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

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

7. Отформатируйте весь ваш код действительно аккуратно

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

8. Каждый кусок кода имеет определенную цель

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

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

изображение заголовка любезно предоставлено DKNG

Богдан Рэнца

Богдан является одним из основателей Inspired Mag, накопив за этот период почти 6-летний опыт. В свободное время он любит изучать классическую музыку и изучать изобразительное искусство. Он тоже одержим исправлениями. У него уже есть 5.