время, затраченное на заточку топора, никогда не тратится впустую

vremya zatrachennoe na zatochku topora nikogda ne tratitsya vpustuyu?v=1656616449

от Harshdeep S Jawanda

reyNqYc029VmUHPxkd4UPZVZHVFw2N5ZCydB
Фото Феликса Рассела-Соу на Unsplash

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

Он недоверчиво спросил: «Как ты нарубил больше дров, чем меня!? Я работал непрерывно, пока ты совершал так много перерывов».

Его друг ответил: «Отдыхая, я точил свой топор, чтобы остальное время эффективнее рубить дрова».

Это то, что я подразумеваю под «Инструментом!»: оснастить себя нужными инструментами, чтобы сделать вас более производительными, обеспечивая при этом более качественную работу.

Нижеприведенное предназначено для разработчиков и использует Java для иллюстрации примеров. Но общий совет касается всех.

Быть разумным

Приведенный выше пример не имеет цели побуждать вас запустить вашу клавиатуру, чтобы начать выбивать классы/библиотеки вспомогательных программ, которые вам помогут. Вовсе нет! Будьте разумны относительно того, что именно вам нужно. Максимизируйте рентабельность своих (временных) инвестиций (ROI). Важная часть разумности означает, что вы…

Отдавайте предпочтение готовым решениям, чем развертыванию собственных

Для разработчиков правильным инструментом часто является библиотека, которая придает вам необходимую функциональность. Есть ли это Optional<;T> класс библиотеки Guava (для использования в коде к Java 8) or its ImmutableList, эти инструменты были разработаны для охвата многих случаев использования. Они также, как правило, обладают многими поколениями эволюции, и они были тщательно проверены как разработчиками, так и пользователями. Таким образом они предлагают преимущества хорошего дизайна и зрелого воплощения.

Помните: не изобретайте велосипед заново!

Используйте свои инструменты последовательно

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

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

Когда придет время сделать это самому

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

Немного может уйти далеко

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

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

Object listValue = myList.get(index)

Правда? Не так быстро! Эта простая строка кода потенциально может вызвать два разных исключения (можете ли вы понять, какие из них и почему?). Ладно, вы оборачиваете свой код некоторыми try-catch Боже, а теперь ты кончил, не правда ли? Какое значение вы собираетесь назначить listValue в случае исключения? Теперь ваш код начинает выглядеть примерно так:

Object listValue = null; // default value assignmenttry {    listValue = myList.get(index);} catch (Exception e) {    // Do nothing (if that is what you want to do)}

Простой, понятный код — но это не совсем красивое или очень удобное зрелище. Не говоря уже о том, что подобные фрагменты будут валяться по всему коду. Рано или поздно вы также забудете учесть все возможные случаи. И затем: бум!!

Сравните это с:

Object listValue = Lists.get(myList, index, null);

где Lists класс полезности содержит такой удобный метод:

public static <T> T get(List<T> list, int position, T defaultValue) {    if (null != list && position >= 0 && position < list.size())        return list.get(position);    return defaultValue;}

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

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

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

Ищите повторяющиеся узоры

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

  • громоздкая
  • имеют многократное использование
  • склонны к ошибкам

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

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

Смойте, повторите.

Не заставляйте это

Позвольте использовать/внедрять инструмент органично развиваться, когда вы боретесь со своими болезненными точками и узкими местами (Agile мышления?). Не устанавливайте жестко запрограммированный лимит в X часов, потраченных на неделю, чтобы удовлетворить какой-либо внешний показатель, являющийся «правильной практикой».

Принудительное использование инструментов иногда может быть контрпродуктивным: вы получите гораздо лучшие результаты, когда вы и ваши люди испытывать потребность в улучшении. Уровень мотивации и восприятия вознаграждения (когда происходит улучшение) гораздо выше.

Последнее, но не менее важное…

Практикуйте непрерывное обучение и самосовершенствование.

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

Наконец…

Если эта статья была вам полезна, не забудьте аплодировать ;-)!

Конструктивные дискуссии и исправления приветствуются.

Добавить комментарий

Ваш адрес email не будет опубликован.