А можно, не надо, подход с onMsg рекомендовать. Это примерно антипатерн «Божественный метод». Давайте нормальные абстракции для компонентов продумывать а не костыли, маскирующие проблему, городить. Всем добра.
Почему нельзя какие-то сборщики подключить. Чтобы читать и поддерживать это можно было нормально, а в итоге собирался огромный файл который может быстро работать?
Интересно, спасибо. IMHO однобординг палка о двух концах. Такие чаты часто становятся слишком раздутыми. Постоянно отвлекают. Содержат технические детали, не относящиеся к текущему таску большинства сотрудников и не откладываются в памяти даже на уровне «что-то такое было»
Забавно, джунов на собеседовании обычно такое спрашиваем. Очень надеясь услышать, что наследование нужно «когда есть общая абстракция», а не «когда есть общий код».
Но тут у человека другая проблема, как я понял. Он ставит под сомнение, полезность выделения абстракции, между модулями, аргументируя тем, что сложность архитектуры начинает перевешивать пользу, которую эта абстракция с собой несёт. И в этом даже есть доля здравого смысла.
Но я бы, в таком случае, усомнился в корректности разбиения приложения на модули. Если же архитектура корректна, то предложение автора, выделять некоторую абстракции в отдельный модуль («группировка по общему признаку»), звучит вполне здраво. Такие высокоуровневые абстракции выделять сложно. И заниматься этим должен человек, имеющий соответсвующий уровень, тот кто отвечает за архитектуру проекта, а не просто случайный разработчик. Когда абстракция выделена грамотно, то у других разработчиков не будет сильного желания поломать ее.
“Управление сложностью — самый важный технический аспект разработки ПО. По-моему, управление сложностью настолько важно, что оно должно быть Главным Техническим Императивом Разработки” (с) Стив Макконнелл.
Что же Вы думаете, что плохой код пишут осознанно, чтобы навредить проекту? Разработчики получает моральное удовлетворение, когда считаю написанный код качественным.
"Просто сделать - сложно, а сложно просто"
Тешить свое самолюбие за деньги заказчика, разве не свинство?
Ну а серьезно, я считаю что нормальным оценивать каждый случай отдельно.
Если ваш заказчик хочет "большой долгоиграющий проект" и готов оплачивать качество человеко-часов. То может быть и правда стоит искать каждый скрытый в DOM элемент и оптимизировать ресурсы, затрачиваемые на его отрисовку. Тут все еще очень сильно зависит, от того насколько корректно Вы можете обрисовать заказчику ситуацию.
Но если Ваш заказчик хочет простенький сайт визитку, и для его бизнеса важны каждые 100 рублей. Думаю ваше усердие не будет оценено должным образом.
В общем ничего нового. Каждой задаче - свое решение. Что не означает, что не нужно работать над своей квалификацией.
Умеете писать код - это хорошо.
Умеете писать качественный код - просто отлично.
Умеете писать код, цена/качество которого соответствует потребностям - Вы великолепны
Не в обиду автору будет сказано, но статья конечно из разряда «Какой я молодец, как элегантно поправил глупые ошибки» )
А вот итоговые советы очень даже полезные. Плюсую. Ещё бы они находили тех, кому адресованы. А не тем у кого и так наболели.
Я наверное скоро трёхтомник «абсурдных кусков кода» кода смогу издать. И приведённые тут примеры, далеко не верх безрассудства. Бывает на code review и смеяться хочется и плакать.
Тут главное не забывать к своим творениям относиться так же критично, как к чужим. Я вот уже сколько лет этим занимаюсь, а периодически ловлю себя на попытке нарушить свои же правила.
Да и вообще, бывает даже самые матёрые ребята пишут глупости. Я убеждён, что жёсткая архитектура, и грамотное выделение шаблонных моментов - залог здорового кода)
Здорово, что начитают появляться статьи по ZeeBe. Полагаю у данного инструмента большое будущее.
Был бы рад увидеть больше статей по данной теме.
Мы не так давно начали работать с ZeeBe.
Camunda была восхитительна, но ZeBee даже лучше. Разработчики убрали кучу сложных/неочевидных возможностей, за счёт чего ZeeBe выглядит гораздо более простым и логичным инструментом, хотя задачи ставятся более амбициозные.
Скажите у Вас ZeeBe уже в продакшне крутится? Все же при всех положительных эмоциях, она не так давно из бэты вышла.
Клей оставшийся, после наклеек, скотча и т.п. мне больше всего нравится удалять мукой. Растворитель только размазывает его. А мукой он скатывается в маленькие шарики и отрывается
Абсолютно верно. Спасибо за подробное разъяснение. По первому — просто неудачно выразился. По поводу interrupted действительно не правильно сказал, меня самого запутали. Поток может быть завершен извне JVM, в этом случае блок finaly не будет выполнен. Гипотетически это может привести к утечке памяти, но меня данное решение устраивает.
Сегодня один умный человек с Хабра, который по каким-то причинам не может писать комментарии, заметил две важные проблемы, которые стоит иметь ввиду.
1) Стоит иметь ввиду, что в web приложениях используется пул потоков — потоки не уникальны. Данное решение будет работать, но только за счёт того что ThreadLocal каждый раз инициализируется заново.
2) Если Thread получит interrupt — блок finally не выполнится. Если работу с базой данных всегда производить через FakeOwnerTransaction.start() — всё будет хорошо, иначе getFakeChanger() может вернуть неверное значение вместо null. Конечно вероятность ошибки крайне мала, но необходимо понимать её возможность.
Да точно, спасибо! Не знал про ThreadLocal. Искал нечто подобное, но так и не нашел. Очень здорово, теперь синхронизация точно не будет тормозить работу, при активном взаимодействии с БД. Вечером поправлю код в статье.
А можно, не надо, подход с 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
1) Стоит иметь ввиду, что в web приложениях используется пул потоков — потоки не уникальны. Данное решение будет работать, но только за счёт того что ThreadLocal каждый раз инициализируется заново.
2) Если Thread получит interrupt — блок finally не выполнится. Если работу с базой данных всегда производить через FakeOwnerTransaction.start() — всё будет хорошо, иначе getFakeChanger() может вернуть неверное значение вместо null. Конечно вероятность ошибки крайне мала, но необходимо понимать её возможность.
Добавил замечания в шапку.