Comments 20
Здравствуйте, автор, вы были добавлены в список говнокодеров!
Это такие люди, которые не умеют продумывать архитектуру и почему-то считают что надо это незнание распространять на других, ведь сложная архитектура это ненужно потому что... (смотрит в блокнотик) ...два сеньора долго спорили из-за какого-то поля в АПИ.
Присоединяйтесь к собратам по инфоцыганству:
https://habr.com/ru/articles/860656/
https://habr.com/ru/articles/877844/
https://habr.com/ru/articles/733400/
https://habr.com/ru/articles/892320/ <= ваша статья.
Так продумывать смотря для чего нужно) Или нужно на каждый микросервис, который из кафки в базу сохраняет (условно), особую архитектуру мозговым штурмом прорабатывать?
Видимо автор еще не знает, что именование переменной - это одна из двух ключевых проблем в программировании. На всякий случай вторая проблема: инвалидация кэша.
Неожиданное открытие: оказалось, что фронтенду вообще неважно, какой именно ключ ошибки вы присылаете. Главное — чтобы он не менялся со временем.
И будет это работать, если и состав фронтенд-команды не меняется со временем.
# дальше можно не читать, собственно
Выходит, все эти горячие дискуссии были просто борьбой вкусовщины, а не поиском технически обоснованного решения. Никакой реальной пользы от них — только потраченное время.
Замечу, что кроме "технически обоснованного" решения — существуют ещё и "организационно-стратегически обоснованные" решения. И чем крупнее проект (и команда разработки, соответственно), тем бОльшую роль начинает играть именно второй момент.
На масштабных задачах: "как лучше/удобнее" — далеко не всегда равно "как полезнее/эффективнее" (как бы парадоксально это ни звучало на первый взгляд). Будь нововведение хоть трижды обосновано "технически". Подобную роскошь могут позволить себе лишь разработчики-одиночки, в крайнем случае небольшие команды.
Вот у меня на нынешнем проекте тим лид, видимо, тоже считает, что следует писать "простой" код, без использования паттернов, DI возможностей и ООП подхода, и потому мы имеем в проекте отсутствие ломбока (потому что страшна, нипанятна, да и нафига нада, Idea сама генерит что надо), кучу Util классов с public static методами, повсеместное использование switch-case и instanceof, и как вишенка на торте: классы по 1000 строк кода и по 20 филдов
Тьфу
Посыл статьи в том, что не нужно городить то, что не требуется. Если требуется паттерн - применяйте. Но если в задаче "вывести на экран Hello, world!" программист оборачивает вызов System.out.println в метод printStr класса StringPrinter (наследуемого от AbstractPrinter) и создаёт PrinterFactory - это уже перебор. Помните, что все паттерны призваны упростить код и его дальнейшую поддержку, а не усложнить
В целом - это и хотел донести) Надо было с более четкими примерами поработать)
Посыл-то понятен. Но если выбирать между двумя крайносятми, то я бы предпочел абстрактные принтеры даже там, где это избыточно, чем instanceof и switch-case конструкции вместо ООП и DI. Разумеется, что любые крайности это плохо, но у меня просто больная тема это в данный момент
Тим лид ведь тоже искренне считает, что это он просто не переусложняет код, где это не нужно
Наверное, ревьюеры просто не поняли величия гениального подхода “пиши как нравится, а остальные потерпят”.
Действительно, странные люди, почему-то хотят, чтобы код был не только рабочим, но и хоть немного следовал каким-то стандартам.
:-) Мой "стандартный" вопрос к разработчику:
- Ты почему сделал так как сделал? Наверное ты понимаешь что у тебя был выбор из нескольких вариантов реализации? Вот такой, такой и такой. Так почему ты выбрал именно то как реализовал?
Ответ хорошего/правильного разработчика:
- Да рассматривал их все, но выбранный по сумме (перечисляет) критериев на мой взгляд наиболее оптимальный/эффективный (краткое описание причин выбора) .
Наиболее частые ответы "плохого" разработчика:
- Мне так просто захотелось и было проще, т.к. они же все решают поставленную задачу.
- Мне так сказали (руководство).
- А разве можно было "по другому"?
- Я услышал про новую/перспективную технологию и решил попробовать ее использовать.
Где подписаться под этим? Вопрос несогласным: если человек на ревью не может с технической точки зрения объяснить свое замечание, то это - личное мнение, которое стремиться к нулевой эффективности, как и любые бессодержательные комменты кодофаперов.
Скажу по секрету, без обид... 50% ныне существующего кода это говнокод, никому не нужный в реальном мире, эти 100500 библиотек и фреймворков "на разный вкус" не выполняют зачастую всех задач. И вы господа на столько хорошие кодеры тут собрались? Я в этом не уверен совсем...
А ещë есть пиар и реклама+журналистика, когда продукт преподносится в каком-то радужном ключе, но когда открываешь код и ужасаешься, и узнаëшь, что вся команда это два студента, то возникает много вопросов...
Почему все в ИТ стало так быстро устаревать?
возрастание мощности ЭВМ сулило огромные перспективы, но мы столкнулись, что вчерашний "Hello word" еле запускается на новом крутом железе.. Думаю виновата лень и нехватка реально хороших программистов, а так же программирование не на языке, а на фреймворках...
огромное количество проектов особенно в OpenSource это вариант дипломной работы или попытка занять кусок места под солнцем со своим велосипедом. Хорошо или плохо это?
Совершенный код — пустая трата времени?