Дисклеймер. Этот пост всесторонне вдохновлен каким-то древним видео в интернете, автора которого я благополучно забыл. Если автор сейчас читает это - респект тебе и увага, бро!
Итак.
Помойму программисты сильно перегибают палку.
Засрали всю джаву мусором.
Хотите вы бин, и что-то в нем хранить тупо, сделайте все поля public! Вместо лесов геттеров-сеттеров.
Боитесь, что такой класс (с пабликами) будет не thread-safe и хомяки не смогут писать с ним хороший многопоточный код? Да побойтесь б-га, хомяки вообще не напишут хорошего многопоточного кода, всё это миф. Дайте среднестатистическому человеку треды и локи, и он напишет код в миллион раз более медленный, чем аналогичный на готовом TransferQueue. Вот и пишите свой продюсер-консумер на TransferQueue, не выпендривайтесь.
ООП, и конкретно механизм наследования, очень плохо подходит для увеличения реюзабельности кода. Глупому заказчику можно втирать рекламу ООП=реюзабельность, но мы тут все грамотные люди, линуксоиды, как минимум с 8 классами образования, мы же все понимаем как оно на самом деле. Трейты/миксины и препроцессор и то с этим лучше справляются иногда.
Но сидят сумрачные гении, и ночами напролет пишут какие-то иерархии классов, чтобы одну строчку копипасты сэкономить. Всё это фигня! В такой надуманной иерархии классов еще сложней разобраться, чем отрефакторить копипасту. И уж точно ее сложнее модифицировать. Мой совет: копипастите смело и открыто! Если коллеги будут придираться, спокойным голосом, глядя на правое ухо поциента, говорите: «вот сам и поправь», 90% что коллега посинеет от страха и сдрыснет в ужасе, в остальные 10% можно утешаться тем, что эту лажу писать пришлось хотя бы не тебе.
Никто не заставляет писать Factory которые производят Factory, которые производят Factory! Хочешь посмотреть, откуда берется объект, а там целый стектрейс на 50 этажей, можно блуждать пока не умрешь от голоду. Хотите сделать объект - ставите new и поехали. Сразу понятно - вот тут делается объект. Фактори нужно изничтожать безбожно (только если это не Spring, Spring надо пожалеть).
И вообще, дизайн паттерны - сплошной хлам. Получается говно вместо результата - давайте нафигачим дизайн паттерн! На каждую проблему есть свой дизайн паттерн! И получается, одна строчка смысла, всё остальное мусор, костыли как они есть. Это стрёмно, господа. Почитаешь какой-нибудь код, и так вымажешься в дизайн-паттернах с ног до головы, что потом по улице стыдно идти, на людей смотреть.
Никаких фреймворков! Ехал фреймворк через фреймворк, и все - говно. Каждый день кто-то еще производит новый фреймворк. Потом набигают ПМы-хипстеры и такие, а что у нас популярно? Ахххаха, гороскоп показывает, что в эту фазу луны популярен Wicket, давайте нафигачим на нем гуй для Международной Космической Станции. Потом где-то там эта чушка не распарсила XML, свалилась в корку обосравшись стектрейсами, и все космонавты сварились. Отлично! Зато фреймворк!
Особенно радуют люди, которые боятся эти фреймворки чинить. Ололо, всё работает через задницу, но трогать не будем. Потому что - потом поддерживать же свой «форк» надо! Лучше нагородим еще костылей вокруг кривого фреймворка! Мотивируется это тем, что «на дальней дистанции» хомякам проще будет писать костыли, чем фиксить фреймворк. Но это ложь, через пару лет развития проекта уже совсем в этих костылях не разобраться. Совет тут такой: не использовать фреймворков, а если использовать - то понимать как они работают, и чистой душой фиксить их, а коммиты стараться засылать в апстрим.
Это всё от другой болезни, называется «Архитектура». Ее нужно долго придумывать, и потом всех насиловать. Можно сказать, архитектура передается половым путем, как сифилис и гангрена. Кто-то из великих говорил, что архитектура - это самая стрёмная, самая зачерствевшая и неизменяемая часть кода, то что фиг изменишь. Нормальный код должен легко меняться. Но во все времена были люди, поклоняющиеся говну. И вот тут, обязательно найдутся поклонники архитектуры. Совет тут такой: шлите архитектуру в зад, пишите гибко изменяемый код, так чтобы (если такая возможность потребуется) двумя легкими движениями рефакторинга текстовый процессор превращался в графический редактор и наоборот. Софт - это не паравоз, нельзя взять три семьнадцать колес, паровой бачок, сложить их по чертежу(архитектуре) и получить паровоз. Софт - это непрерывный процесс рефакторинга.
Никаких лесов комментариев! Пишут, значит, целые поэмы там. А кто эти поэмы потом апдейтить будет? Потому что понапихали своих дизайн-паттернов и фреймворков, отформатировали в кривую архитектуру, ничего уже не понятно, что код делает! Надо пояснить суть поэмой! Резюме тут такое: в коде должно быть написано ровно то, что он делает. Если строчки кода расходятся со смыслом, этот код нужно переписать, а не подпирать комментариями.
Самая жуть, это всякие ынтерпрайзные сервера, портлеты, фигеты, шушпанчики. Вот притащил ты себе в проект WebLogic или еще какой-нибудь архитектурно-окаменевший кусок, и что изменилось? Кстати, вы видели чтобы на одном реальном хайлоадном сервере запускалось больше одного приложения? Обычно бывает как раз наоборот - на куче серверов запускается ОДНО приложение! А сколько бед от этой псевдофункциональности по огранизации шаред хостинга! Что ынтерпрайзные сервера лучше делают, чем Jetty запущенная прямо из функции main? Собственно в этом и совет, запускайте джетти откуда-нибудь руками, или из мавена, и не парьте мозг.
Надо писать так, чтобы код отражал СУТЬ. Чтобы деплой отражал СМЫСЛ. Посмотрел на код - и сразу понятно, что там написано. Запустил сервер - и сразу понятно, что и как он обслуживает, где скачать его исходники и пофиксить, если чо.
Если вы последовали перечисленным советам, но вас никто не понимает, скажите что 
stevejobs с лора разрешил.
В общем, идея понятна, теперь можно приступать к критике :)
Привет.
