Pull to refresh
7
0
Владимир Беляков @Neki

Программист

Send message

А можно, не надо, подход с onMsg рекомендовать. Это примерно антипатерн «Божественный метод». Давайте нормальные абстракции для компонентов продумывать а не костыли, маскирующие проблему, городить. Всем добра.

Почему нельзя какие-то сборщики подключить. Чтобы читать и поддерживать это можно было нормально, а в итоге собирался огромный файл который может быстро работать?

Ну если человек хочет написать месиво, то отсутсвие JSX его вряд ли остановит)

Используйте JSX как шаблонизатор и будет добро)

Интересно, спасибо. IMHO однобординг палка о двух концах. Такие чаты часто становятся слишком раздутыми. Постоянно отвлекают. Содержат технические детали, не относящиеся к текущему таску большинства сотрудников и не откладываются в памяти даже на уровне «что-то такое было»

Ну вот например kotlin, почитайте там целая глава почему они отказались от проверяемых исключений. https://kotlinlang.ru/docs/exceptions.html

В swift, typescript тоже обошлись без них

Ну вроде все нормальные языки стараются избавиться от проверяемых исключений) А для непроверяемых это делать крайне странно IMHO

Забавно, джунов на собеседовании обычно такое спрашиваем. Очень надеясь услышать, что наследование нужно «когда есть общая абстракция», а не «когда есть общий код».

Но тут у человека другая проблема, как я понял. Он ставит под сомнение, полезность выделения абстракции, между модулями, аргументируя тем, что сложность архитектуры начинает перевешивать пользу, которую эта абстракция с собой несёт. И в этом даже есть доля здравого смысла.

Но я бы, в таком случае, усомнился в корректности разбиения приложения на модули. Если же архитектура корректна, то предложение автора, выделять некоторую абстракции в отдельный модуль («группировка по общему признаку»), звучит вполне здраво. Такие высокоуровневые абстракции выделять сложно. И заниматься этим должен человек, имеющий соответсвующий уровень, тот кто отвечает за архитектуру проекта, а не просто случайный разработчик. Когда абстракция выделена грамотно, то у других разработчиков не будет сильного желания поломать ее.

Управление сложностью — самый важный технический аспект разработки ПО. По-моему, управление сложностью настолько важно, что оно должно быть Главным Техническим Императивом Разработки” (с) Стив Макконнелл.

Но дело все, конечно, в реакте)

Что же Вы думаете, что плохой код пишут осознанно, чтобы навредить проекту? Разработчики получает моральное удовлетворение, когда считаю написанный код качественным.

"Просто сделать - сложно, а сложно просто"

Тешить свое самолюбие за деньги заказчика, разве не свинство?

Думаете это нормально заливать 92 бензин?

Ну а серьезно, я считаю что нормальным оценивать каждый случай отдельно.

Если ваш заказчик хочет "большой долгоиграющий проект" и готов оплачивать качество человеко-часов. То может быть и правда стоит искать каждый скрытый в DOM элемент и оптимизировать ресурсы, затрачиваемые на его отрисовку. Тут все еще очень сильно зависит, от того насколько корректно Вы можете обрисовать заказчику ситуацию.

Но если Ваш заказчик хочет простенький сайт визитку, и для его бизнеса важны каждые 100 рублей. Думаю ваше усердие не будет оценено должным образом.


В общем ничего нового. Каждой задаче - свое решение. Что не означает, что не нужно работать над своей квалификацией. 

Умеете писать код - это хорошо.

Умеете писать качественный код - просто отлично.

Умеете писать код, цена/качество которого соответствует потребностям - Вы великолепны


Не в обиду автору будет сказано, но статья конечно из разряда «Какой я молодец, как элегантно поправил глупые ошибки» ) 

А вот итоговые советы очень даже полезные. Плюсую. Ещё бы они находили тех, кому адресованы. А не тем у кого и так наболели.

Я наверное скоро трёхтомник «абсурдных кусков кода» кода смогу издать. И приведённые тут примеры, далеко не верх безрассудства. Бывает на code review и смеяться хочется и плакать.

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

Да и вообще, бывает даже самые матёрые ребята пишут глупости. Я убеждён, что жёсткая архитектура, и грамотное выделение шаблонных моментов - залог здорового кода)

Здорово, что начитают появляться статьи по ZeeBe. Полагаю у данного инструмента большое будущее.
Был бы рад увидеть больше статей по данной теме.
Мы не так давно начали работать с ZeeBe.
Camunda была восхитительна, но ZeBee даже лучше. Разработчики убрали кучу сложных/неочевидных возможностей, за счёт чего ZeeBe выглядит гораздо более простым и логичным инструментом, хотя задачи ставятся более амбициозные.


Скажите у Вас ZeeBe уже в продакшне крутится? Все же при всех положительных эмоциях, она не так давно из бэты вышла.

Клей оставшийся, после наклеек, скотча и т.п. мне больше всего нравится удалять мукой. Растворитель только размазывает его. А мукой он скатывается в маленькие шарики и отрывается

Можно и мне инвайт, пожалуйста) bl.vd собака yandex.ru

Абсолютно верно. Спасибо за подробное разъяснение. По первому — просто неудачно выразился. По поводу interrupted действительно не правильно сказал, меня самого запутали. Поток может быть завершен извне JVM, в этом случае блок finaly не будет выполнен. Гипотетически это может привести к утечке памяти, но меня данное решение устраивает.
Сегодня один умный человек с Хабра, который по каким-то причинам не может писать комментарии, заметил две важные проблемы, которые стоит иметь ввиду.

1) Стоит иметь ввиду, что в web приложениях используется пул потоков — потоки не уникальны. Данное решение будет работать, но только за счёт того что ThreadLocal каждый раз инициализируется заново.

2) Если Thread получит interrupt — блок finally не выполнится. Если работу с базой данных всегда производить через FakeOwnerTransaction.start() — всё будет хорошо, иначе getFakeChanger() может вернуть неверное значение вместо null. Конечно вероятность ошибки крайне мала, но необходимо понимать её возможность.

Добавил замечания в шапку.
Да точно, спасибо! Не знал про ThreadLocal. Искал нечто подобное, но так и не нашел. Очень здорово, теперь синхронизация точно не будет тормозить работу, при активном взаимодействии с БД. Вечером поправлю код в статье.
Не заметил кнопку ответить. Ответил ниже.
SystemUtils свой класс. Добавил код под спойлер.

Information

Rating
Does not participate
Location
Иваново, Ивановская обл., Россия
Date of birth
Registered
Activity