JS fwdays conference — React, Vue, Node.js, Webpack plugins and more. Kyiv, March 14
×Закрыть

Основные ошибки в Java программировании

Всем привет

Хочу предложить вашему вниманию цикл статей «Основные ошибки в Java программировании». Идея цикла возникла давно, когда я только начал работать преподавателем на Java курсах и постоянно встречал одни и те же ошибки у разных групп студентов. Материализовалась идея недавно, и на данный момент готово 19 статей, охватывающих различные аспекты программирования на Java SE.
Еще одно название цикла — «Анти-паттерны Java программирования».

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

Вся информация будет публиковаться здесь:
it-simulator.com/...-Java-programmirovanii-53

Обо мне:
Сергей Моренец, опыт коммерческой разработки с 2000 года, программирую на Java c 2004 года.
3 года работаю преподавателем Java(курсы «Java Elementary» и «Java Advanced»).
Более 15 раз выступал на Java конференциях(Java User Group, JEEConf, JavaDay и другие).

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Довольно бурная дискуссия в этом топике о названии моей книги заставила меня написать отдельную главу, которую я так и назвал «Что такое ошибка программирования?» Надеюсь, после этого стало чуть понятнее.

Похоже на Clean code

Да, возможно в чем-то похоже. Но Clean code в основном об ООП и дизайне, поэтому в принципе подходит под любой ОО-язык. Я же хочу сфокусироваться на особенностях Java

Clean code не столько об ООП и дизайне, даже совсем не, а конкретно о кодировании. И хоть и не явно, но основной упор на Java. Боюсь, прочитавшему Clean Code будет сложно уловить отличия достаточно быстро чтобы не соскочить.

Я не собираюсь отбивать читателей у Роберта Мартина :) Но я уже описал много кейсов, которых нет в его книге. А я планирую довести их число до 100.

Я считаю, что ошибка — это когда программа не корректна, не удовлетворяет спецификации. А вы описываете, как я понял, плохой стиль. Ошибка объективна, качество стиля субъективно. Советую убрать слово «ошибка» из названия, а то создаётся впечатление, что это критично и обязательно, а на самом деле нет.

а кто вообще писал, что это ошибка программы? тут же речь не о программе, а о программировании. когда вы суете пальцы в розетку и вас бьет током — это ошибка системы электрификации? вроде бы всё работает как должно, но вас бьет током и это ваша ошибка

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

Я считаю, что идеального кода не существует, так как оценка стиля субъективна. То есть не

код идеален с точки зрения программирования
а код идеален с точки зрения некоторого программиста.

Идеального не существует, но наверное есть код, который просто нельзя улучшить. Его можно назвать совершенным, чистым и т.д. То же самое если объединить best practices программирования.

Спасибо всем за комментарии. Приглашаю завтра и послезавтра на JEEConf, где можно продолжить обсуждение будущего книг и обучения по ним

тема избитая и не новая и все это знают или читали хоть раз. Проблема в основном организационная — отсутствие практики ревью и рефакторинга из-за того что заказчик считает это низко приоритетным.

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

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

Лучший способ объяснить, как не надо писать код — это дать почитать чужой код. Лучше если с задачей исправить «маленькую ошибку», «немного доработать» — и дедлайном соответственно «тут всего на 5 минут дела».

PS. Лично мне хватило программ под Linux в исходных кодах. Когда вроде всё есть, но как дело доходит до установки — там скобочку забыли, там опечаточка, и всё это автор бы нашёл сам если бы не ниндзя-кодил.

Спасибо за ваше мнение. Если не секрет, какие книги по Java вы прочли за последние пару лет?

Могу поделиться опытом работы преподавателем. Большинство Java студентов очень тяжело понимают чужой код и могут в нем быстро разобраться. Наверное, это приходит с годами. Поэтому «дать почитать чужой код» можно, но не для всех это сработает.

Пониманию чужого кода невозможно научиться. Можно ли понять код — зависит от автора, а не от читателя.

Я предлагаю давать читать код именно как вакцину от написания плохого кода. Ведь свой код всем кажется хорошим. А чужой — «надо всё переписать». Встретив тут и там какой-нибудь fSCPsuperimportantproprietaryhandler типа String и попытавшись понять за что что же он возвращает ошибку MRZVyoureuluckytoday студент быстро усвоит красоту правильных имён.

Можно ли или нельзя ли научиться читать код — это наверное вопрос к психологам. Но я здесь имел в виду, что в чтении кода важны и знания, и опыт. А их маловато у студентов

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

А для того бы украинцу прочитать Омар Хайяма в подлиннике, нужно быть поэтом ? :) Наверное нет, нужно хорошо знать арабский язык. Я и имел в виду, что без знаний и опыта новичкам тяжеловато

Пониманию чужого кода невозможно научиться. Можно ли понять код — зависит от автора, а не от читателя.

Вранье. Обычный навык, быстро прокачивается на рефакторинге быдло кода и ревью индусикам. Другой вопрос что всегда найдется еще более «одаренная» личность что дешевле покрыть end-to-end тестами, выкинуть и написать заново.

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

Пониманию чужого кода невозможно научиться. Можно ли понять код — зависит от автора, а не от читателя.

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

«Основные ошибки в Java программировании» звучит понятнее, чем «Анти-паттерны Java программирования».

Согласен, хотя «анти-паттерны» заманчивее. Если посмотреть на существующие проекты, неизвестно, что чаще используется — паттерны или анти-паттерны.

Проблема только в том, что речь идёт не об ошибках в программах, а о стиле.

Речь идет не об ошибках в программах, а ошибках в программировании — то есть в написании программ. Стиль программирования — это нечто, присущее каждому отдельному разработчику. И он не может быть правильным или нет, как например не может быть неправильной прическа или деталь одежды, та же рубашка. Моя задача — рассказать о том, как делать рубашки, какие есть стандарты при их производстве, что должно быть обязательно два рукава и т.д. А вот делать кармашки или нет- это уже решает программист

Интересный мануал!
Правда, непонятно, почему автор в конце 10 главы не захотел по-человечески оформить заголовок цикла for, imho это был бы самый наглядный вариант — сразу видно, с чего начинаем и чем заканчиваем.
Но в целом — понравилось, буду советовать знакомым джунам.

Проглянул — неплохо. Напомнило Фаулера с его «Совершенный код», токо проще и лаконичней. Хорошее дело делаете!

P. S. и да Optional усложняет код ;-).

Напомнило Фаулера с его «Совершенный код», токо проще и лаконичней.

Сильно-сильно извиняюсь, но не могу удержаться.

Спасибо. Если Optional усложняет код, то почему его добавили в Java 8? Кстати, в Scala есть аналог — Option. Не слышал, чтобы на него ругались.
А «Совершенный код» — отличная книга, которую я всем рекомендую.

Если Optional усложняет код, то почему его добавили в Java 8?

А почему Set наследуется от Map хотя делает меньше и хавает столько же памяти? А почему clone() - protected, а Clonable — без clone()? А почему Serializable без методов?

Ну вы поняли =)...

Да, это известные факты, но все же это особенности Java 1.0 — 1.2. Мне казалось, что к Java 8 инженеры Sun/Oracle должны извлечь уроки из своих ошибок

в Scala есть аналог — Option. Не слышал, чтобы на него ругались.

В скале оптион наоборот, облегчает код. Но там своя специфика...

А в чем же разница между Option and Optional ?

Я с 8-кой не работал, потому не скажу. Ваша заметка о том как работать с оптионал пока что явно не дописанна =)

Спасибо за замечание, переделал. Несмотря на то, что Java 8 появилась больше года назад, постоянно открываю для себя что-то новое в ней.

При существовании и БиттерДжавы, и ДжаваПаззлерс — плохо понятно зачем вы этим занимаетесь :-)

Честно говоря, «Bitter Java» не читал, но теперь обязательно прочту. Я посмотрел, что она была издана в 2002 году, с тех пор многое изменилось. Появились новые фитчи, на некоторые вещи стали по-другому смотреть. Ну а вообще сейчас, в эпоху конкуренции, чем больше книг — тем лучше. Каждый выберет себе по душе. А у меня еще бесплатно :)

Если у вас есть темы (анти-паттерны), в которых вы хотели бы лучше разобраться, пишите их здесь. Я постараюсь их раскрыть в новых статьях.

Подписаться на комментарии