bobobo разместил(а) новый ресурс:
CLb0 - Логирование действий игроков с креативом
Посмотреть страницу этого ресурса...
CLb0 - Логирование действий игроков с креативом
Посмотреть страницу этого ресурса...
Спасибо <3 Надеюсь в будущем плагин будет обновлен и все же получится отличать перетаскивание от получения из меню гм
Вообще видел плагин CreativeManager, там тоже есть логирование действий, но кроме того дохуя ненужного барахла, может возможно оттуда немного спиздить код? ⚡ CreativeManager ⚡ Customizable - Complete control
Вообще видел плагин CreativeManager, там тоже есть логирование действий, но кроме того дохуя ненужного барахла, может возможно оттуда немного спиздить код? ⚡ CreativeManager ⚡ Customizable - Complete control
Хороший плагин, очень даже, но вот к архитектуре вопросы дружище, мне как пользователю чуть сложновато ориентироватся в твоей архитектуре так как она по концепции отличная а вот по релизации не очень, знания на уровне концептульного профессионала, но вот само выполнение архитектуры как то вводит в заблуждение.. Исполнение самого кода ну просто шикарное, я давно такого не видел, еще со времен старых Senior, хотя казалось бы такая вроде базовая вещь.. У тебя имеются понимания композиции и HAS-A, вижу защиту инвариантов и четкое разграничение, но чего то все же не хватает тут..
1. По коммитам не понял вообще что проводилось.. Какой рефакторинг, где и зачем он был..?
2. Почему у тебя буквально владелец бизнес-логики находится в utils? - Все исполнители не имеют своего состояния и подвешены в системе что создает не очень хорошее впечатление в проде. Решается созданием сервисов обработки с четкими слоями разграничения ответственности между model (state как истинной) -
3. У тебя размазана ответственность и потерян ownership, listener - bukkit adapter и у него нет своего обработчика service
4. Нет расширяемости, проект буквально отлично выполнен но закован в цепи собственного же исполнения, я например в файлах не очень хочу хранить целую систему логироваиния когда у меня на условном креативе играет 300 человек на 4 таких сервера.. Добавить менеджер repository, кэш, поддержку SQL (MySQL, MariaDB), архитектурных владельцев данных (PostgreSQL), NoSQL (MongoDB) P.S: Не думаю что кому то надо но все же..
5. Пакеты - по моему в таком проекте который считай не выходит за Solid - Single Responsibility Principle буквально то есть выполняет только одну функцию они тут - излишняя нагрузка на прод, обычные пакеты и тем более лишний NMS по мне не нужен маленькому проекту и с ними нужно быть очень осторожными потому что есть возможность так уронить сервер ненароком, процент мал, НО! Никогда не знаешь что у клиента на стороне по этому лишняя осторожность не помешает.
6. Геттеры - очень опасная штука, конфиг - область высшего недоверия клиету у тебя нет инвариантов и защиты ООП правила о инкапсюляции что сам класс должен обеспечить инвариантность и сразу же проверять формат ввода данных, чтобы указать администратору где именно ошибка, и не просто через ленивый интерфейс Exception а через нормальную обработку Illegal, твои геттеры не могут дать гарантии что они именно такие какими ты их ожидаешь, ты поставил default и это отлично, но вот проблема, когда администратор сделал одно а сервер выдал другое и поступит тикет что что то не работает в КОДЕ (потому что естевственно на себя он не подумает ведь он святой) ты будешь думать обо всем до 5 колена и даже полезешь в Concurrency ради ответов хотя у тебя ассинхроном тут даже и не пахнет, и да кстати, ты никогда не знаешь в каком потоке у тебя будет вызываться listener или обработчик
Из этого кстати следующий очень прикольный вопрос/ Так вот, пока не дойдет что дело не в тебе пройдет драгоценное время
7. Обработка логики в ассихнроне, так как у тебя нет service который сам определяет по средствам Executor Single Writer, HickariCP, CompletbleFuture, Scheduler или прочих инструментов ты никогда не знаешь когда твой код может проволиться в ассихнронное выполнение, потому что проблема - ты не знаешь ядра, ты не управляешь потоком и ты гость в чужой системе например Paper который и является владельцем main thread, а я думаю ты понимаешь что произойдет если обработка Bukkit логики начнется в не ThreadSagfe ассинхроннои потоке выдергивая данные из основного потока
Этот плагин буквально идеал и святой грааль, почти, ему не хватает только четкой реализации которую при твоем исполнении я не думаю что ты не смог бы довести до конца, на профиль мой можешь даже не смотреть, там максимум мои самые первые работы, но скоро буду выкатывать кое что интересное, не такое продвинутое как у тебя но все же на уровне. Я понимаю что этот проект такой гигант как ты создал за один день и не в коем разе не хочу тут умничать но просто хочу что бы эта шикарная идея от такого человека имела под собой не только хорошее написание кода а еще и грамотную архитектуру которая выдержит наплыв и не будет ломаться под обычным reload..
Я не требую и не собираюсь учить и воевать просто подумал что мои решения могут быть тебе интересны как разработчик разработчику, тут дело вкуса в неккоторых местах, у меня brain architecture type и я очень боюсь вообще за все в системе. По этому прошу, будь осторожнее..
1. По коммитам не понял вообще что проводилось.. Какой рефакторинг, где и зачем он был..?
2. Почему у тебя буквально владелец бизнес-логики находится в utils? - Все исполнители не имеют своего состояния и подвешены в системе что создает не очень хорошее впечатление в проде. Решается созданием сервисов обработки с четкими слоями разграничения ответственности между model (state как истинной) -
3. У тебя размазана ответственность и потерян ownership, listener - bukkit adapter и у него нет своего обработчика service
4. Нет расширяемости, проект буквально отлично выполнен но закован в цепи собственного же исполнения, я например в файлах не очень хочу хранить целую систему логироваиния когда у меня на условном креативе играет 300 человек на 4 таких сервера.. Добавить менеджер repository, кэш, поддержку SQL (MySQL, MariaDB), архитектурных владельцев данных (PostgreSQL), NoSQL (MongoDB) P.S: Не думаю что кому то надо но все же..
5. Пакеты - по моему в таком проекте который считай не выходит за Solid - Single Responsibility Principle буквально то есть выполняет только одну функцию они тут - излишняя нагрузка на прод, обычные пакеты и тем более лишний NMS по мне не нужен маленькому проекту и с ними нужно быть очень осторожными потому что есть возможность так уронить сервер ненароком, процент мал, НО! Никогда не знаешь что у клиента на стороне по этому лишняя осторожность не помешает.
6. Геттеры - очень опасная штука, конфиг - область высшего недоверия клиету у тебя нет инвариантов и защиты ООП правила о инкапсюляции что сам класс должен обеспечить инвариантность и сразу же проверять формат ввода данных, чтобы указать администратору где именно ошибка, и не просто через ленивый интерфейс Exception а через нормальную обработку Illegal, твои геттеры не могут дать гарантии что они именно такие какими ты их ожидаешь, ты поставил default и это отлично, но вот проблема, когда администратор сделал одно а сервер выдал другое и поступит тикет что что то не работает в КОДЕ (потому что естевственно на себя он не подумает ведь он святой) ты будешь думать обо всем до 5 колена и даже полезешь в Concurrency ради ответов хотя у тебя ассинхроном тут даже и не пахнет, и да кстати, ты никогда не знаешь в каком потоке у тебя будет вызываться listener или обработчик
Из этого кстати следующий очень прикольный вопрос/ Так вот, пока не дойдет что дело не в тебе пройдет драгоценное время7. Обработка логики в ассихнроне, так как у тебя нет service который сам определяет по средствам Executor Single Writer, HickariCP, CompletbleFuture, Scheduler или прочих инструментов ты никогда не знаешь когда твой код может проволиться в ассихнронное выполнение, потому что проблема - ты не знаешь ядра, ты не управляешь потоком и ты гость в чужой системе например Paper который и является владельцем main thread, а я думаю ты понимаешь что произойдет если обработка Bukkit логики начнется в не ThreadSagfe ассинхроннои потоке выдергивая данные из основного потока
Этот плагин буквально идеал и святой грааль, почти, ему не хватает только четкой реализации которую при твоем исполнении я не думаю что ты не смог бы довести до конца, на профиль мой можешь даже не смотреть, там максимум мои самые первые работы, но скоро буду выкатывать кое что интересное, не такое продвинутое как у тебя но все же на уровне. Я понимаю что этот проект такой гигант как ты создал за один день и не в коем разе не хочу тут умничать но просто хочу что бы эта шикарная идея от такого человека имела под собой не только хорошее написание кода а еще и грамотную архитектуру которая выдержит наплыв и не будет ломаться под обычным reload..
Я не требую и не собираюсь учить и воевать просто подумал что мои решения могут быть тебе интересны как разработчик разработчику, тут дело вкуса в неккоторых местах, у меня brain architecture type и я очень боюсь вообще за все в системе. По этому прошу, будь осторожнее..
Вложения
Так и решим, плагин какашка, нет локальной базы данных SQL с индексацией.
Да я тебя умоляю, он этого даже не увидит, на нем стоит форум и я не думаю что у него на такое найдется время, по крайней мере у меня раньше не находилось..
И четких реляционных контрактов на заполнение с продвинутой проверкой инвариантов :3Так и решим, плагин какашка, нет локальной базы данных SQL с индексацией.
Под этим я просто выделил даже принцип S как Single Responsibility Principle, из SOLID, проговариваю на всякий, потому что мало ли кто не поймет