4 совета по программированию при преодолении собственных психологических недостатков

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

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

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

См. также: Интернет вещей и кодирование - какие языки программирования самые популярные?

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

1. Напишите модульный тест для вашей же пользы

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

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

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

Также гордитесь написанными вами тестами. Посмотрите на все зеленые индикаторы, висящие над вашим кодом. Знайте, что ваша практика и этика превосходны. В этом нет ничего постыдного.

2. Сделайте код многоразовым во время работы

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

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

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

Усилия минимальны, а веб-представление Bit's Community Hub позволяет быстро просматривать документы, тесты, загружаемые файлы и многое другое, что дает немедленное удовлетворение от вашей работы, теперь доступной для всего мира. Вы также можете поделиться им со своей командой или сообществом.

3. Не копировать и вставлять. Только не надо.

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

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

Что мы можем сделать? ну, не копируйте код! Просто не надо. Вместо этого найдите / создайте / поделитесь повторно используемыми компонентами. Синдре Сорхус выпустил более 1000 крошечных упаковок. Пакеты - это сложно, а 1000 - это много.

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

4. Задокументируйте свой код, расскажите историю

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

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

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

Хорошие документы показывают, что вы полностью понимаете, что и как делаете. Если история не имеет смысла, лучше выяснить это через документацию, чем через сам код.

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

В конце концов, одного зефира за раз действительно недостаточно.