7 ошибок джуна

Опыт — сын ошибок трудных.

А.С. Пушкин

Чтобы научиться программировать, необходимо программировать. Здесь так же как в детстве, когда мы учились ходить: встаешь, падаешь, затем снова встаешь и снова падаешь до тех пор пока не пойдешь. Почему так? Потому что просто не знаешь, что значит ходить, отсюда постоянные ошибки. Учиться кодить, все равно что ходить. Даже слова отличаются только одной буквой. Ошибки неизбежны. Но это не важно. Важно лишь отношение к ним. Ошибка — это результат определенной последовательности действий. Изменишь действия — избежишь ошибки, или получишь новую ошибку, повезет, если во время компиляции. Когда я только начал свой путь в мире Java, да и программировании вообще, у меня была привычка записывать все свои ошибки. Здесь я оставлю самые первые 7 ошибок, с которыми так же может столкнуться начинающий разработчик, а так же как с ними справиться.

Ошибка 1: someObject.equals(«Igor»)

Результат: NullPointerException.
Что пошло не так? Объект someObject может оказаться null, и тогда фактически вызов будет выглядеть как null.equals(«Igor»). Подобный вызов невозможен, он и приводит к ошибке.
Решение. В данном примере метод equals() принимает параметром уже инициализированный объект класса String, поэтому можно поменять местами someObject и «Igor» — “Igor”.equals(someObject). В таком случае, если даже someObject=null исключения не произойдет, т.к. в реализации метода equals() класса String есть проверка с помощью оператора istanceof является ли входящий параметр объектом класса String, а результатом выполнения будет false. Так же можно использовать метод Objects.equals(someObject, «Igor»).

Ошибка 2: Вызов метода get() у List

Результат: IndexOutOfBoundsException.
Что пошло не так? Список заполнялся во время выполнения программы из разных источников. Была 100% уверенность, что в списке точно есть 1 элемент, он то и был нужен. Но в некоторых случаях список оставался пустым и вызов list.get(0) приводил к возникновению исключения.
Решение. Не быть уверенным на 100%, а узнать список пустой или же в нем действительно что-то есть? Для этого достаточно поместить вызов get() в блок if (!list.isEmpty())

Ошибка 3: Недостаточное количество проверок и тестов

Ошибка: не одна ошибка.
Что пошло не так? Много изменений на прод пошли не так.
Решение. Если данные приходят извне (считываются из баз данных, файловой системы, холодильника, стиральной машины) нужно понимать, что их попросту может не быть. Да, всегда были, а именно сегодня не будет, потому что отец выкинул холодильник. Поэтому для более стабильной работы приложения необходимо делать проверки на пустоту списка, null и прочие. Стоит понимать, что данные могут быть, но их корректность может сильно отличаться от ожидаемой. И речь идет не только о «крайних случая», а о самых «фантастических». В данном случае поможет тестирование вашего кода под самыми разными углами. Например, эта запись в моем журнале ошибок появилась после того, как я не внес одно исключающее условие в запрос к БД. В результате нагрузка на сервер БД возросла в несколько раз. Нашли проблему только через неделю. Один маленький тест и этого можно было избежать.

Ошибка 4: наименование полей, методов, переменных

Результат: непонимание коллег.
Что пошло не так? Например, в коде появляются «магические» числа, которые используются в некотором алгоритме. Пока ты пишешь этот код, то помнишь, что значит магическое число «4». Далее комит -> пуш -> прод. Хорошо, если спустя короткий промежуток времени к тебе подойдет коллега и спросит: «Что такое 4?». В худшем, спустя месяц другой тебе придется самому править свой алгоритм, и этот вопрос ты будешь задавать себе сам. 
Решение? Прочитать книгу Роберта Мартина «Чистый код» и использовать лучшие практики наименования. Или прочитать мою статью на тему наименований здесь.

Попробуйте понять что делает этот код

Этот же код, после переименований

Ошибка 5: снова метод get()

Результат: NullPointerException.
Что пошло не так? Спасибо выводам из ошибки 2, мы уже можем вызывать метод get() не из пустого массива. Но, оказывается, null может лежать и в самом массиве. 
Решение. Как вариант можно сделать проверку на null так же в условии if. 

NullPointerException

С проверкой на null

Ошибка 6: делать SQL-запрос с условием WHERE по неиндексируемому полю

Результат: Долгое выполнение запроса.
Что пошло не так? Нужно получить некоторый набор данных из таблицы по определенному условию. Сделав SELECT с WHERE по неиндексируемому полю, можно сильно замедлить выполнение программы.
Решение. Установить индекс для этого поля. В моем случае, запрос вместо 17 секунд стал выполняться меньше одной.

Ошибка 7: isEmpty()=null

Результат: NullPointerException.
Что пошло не так? Проблема как и в сценарии с ошибкой 1. Список ссылается на null, вызов метода isEmpty() приводит к исключению.
Решение. Чтобы избежать NPE, список нужно сразу инициализировать в месте объявления, или в месте, где будет происходить обращение к потенциально опасному вызову, например, get(), в условии if нужно записать конструкцию if (list!=null && !list.isEmpty()) причем последовательность важна. Если ее не соблюсти, то в случае list=null, мы так же получим исключение NPE.

NullPointerException

Инициализация поля

Проверка на null в условии

Заключение

Так или иначе большинство ошибок начинающего разработчика на java (у меня точно) крутится вокруг NullPointerException и работой с этим самым null. Можно читать много статей, книг и исследований посвященных тому как с этим работать, но чтобы понять этого зверя просто необходимо «сломать копья о «пустоту». Делитесь своими ошибками и уроками в комментариях к этой статье!

Оставить комментарий:

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

Site Footer