Вот признаки, которые я использовал, чтобы выявить плохих разработчиков Java

Вы работали с плохими разработчиками Java.

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

Давайте назовем этого плохого разработчика Джимом.

Джим: "Приятных каникул, я исправлю ошибку 403".

Я: "Хорошо, это другая роль в конфигурации, после того, как вы включите ее, вы должны решить проблему с ролью".

Вернувшись из отпуска, обнаружил ошибку 404.

Я: «Привет, Джим, почему я сейчас вижу эту ошибку 404? Вы добавили ожидаемую роль?»

Джим: "Я удалил всю конфигурацию, поэтому теперь мы получаем 404. Не пробовал добавлять эту роль".

Мы потеряли еще неделю и отложили поставку функции.

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

Я бы не доверил ему код. Поскольку у него не было чувства собственности, его код был мусором. Код работал, и этого было достаточно по его меркам.

Коллега Джима тоже ушел. Я не знаю, почему, но его код тоже был мусором. Он скопировал кучу кода и ушел. Этот код не работал, и я решал эту проблему в течение недели.

Когда я ушел из компании, меня заменил другой парень. Даже он бросил через несколько недель.

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

Как бы вы определили плохого разработчика Java? Каковы плохие черты Java-разработчика?

Я бы прибегнул к просмотру кода. Вот где вы видите качество разработчика. Вот что нужно искать в код-ревью.

Хорошие разработчики Java ценят ясность

Хорошие разработчики Java прибегают к новым функциям Java.

Он знает Optional и как работает Optional. Я видел много злоупотреблений и злоупотреблений Optional. Только от плохих инженеров.

Хороший разработчик не злоупотребляет Optional.

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

Я также видел, как orElse использовался с методом. Метод в блоке orElse выполнялся и преследовал вас. Еще одно неправильное использование, которого вам следует остерегаться, — это использование isPresent и get, причем не в этом конкретном порядке.

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

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

Они не злоупотребляют лямбдами

Плохие Java-разработчики не ценят функциональные интерфейсы.

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

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

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

"Здесь можно использовать лямбда-выражение или ссылку на метод". – распространенный комментарий PR о плохом PR разработчика.

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

Плохое знание исключений

Плохие разработчики Java не знают, как обрабатывать исключения. Игра слов.

Они не знают о проверенных или непроверенных исключениях. Они добавляли блок catch и теряли трассировку стека. Или они не используют проверенные исключения для перевода исключения. В любом случае, происходит что-то плохое, и вы глубоко…

Я бы сказал, что обработка исключений — важный аспект разработки Java.

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

Понимание перевода исключений. Джеймс Гослинг утверждает, что это лучший способ показать ошибки. Вот что он говорит о переводе исключений.

Джеймс Гослинг: это место, где перевод исключений может быть полезным. Если у вас есть что-то, что должно читать базу данных, и где-то глубоко внутри нее оно может получить MalformedURLException, вероятно, не имеет смысла распространять это наружу как MalformedURLException .

Лучше подумать о том, какие исключения являются действительно частью интерфейса, а не просто артефактом реализации лежащего в основе метода. В механизме исключений Java исключения могут иметь ссылку на другие исключения в качестве причины. Итак, вы создаете новый IOExceptionи устанавливаете его причину для этого MalformedURLExceptio. А вы их сложите вместе. Это было очень эффективно.

Не повторяйте мою ошибку. Оцените свою рабочую среду. Не тратьте свое время. Поднимите флаги плохого качества кода на код-ревью. Не позволяйте качеству кода заставить вас ненавидеть свою работу.

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