*Service - плохая практика, так как мотивирует напихать туда всего, так же как и *Manager и подобное. Если не получается подобрать подходящее имя класса (например PostCreator, ProductFinder и т.д.), то сразу возникает мысль, не нарушается ли здесь SRP?
Из суффиксов Controller и Repository по крайней мере можно понять домен использования, поэтому оно больше полезно, чем вредно.
Почему-то очень часто встречается мнение, что Канбан - это как Скрам, только без спринтов. Это в корне неверное утверждение: Канбан и Скрам - это вещи, которые акцентируются на разных аспектах. Более того, Канбан и Скрам можно применять одновременно, и вселенная от этого не схлопнется, эксепшн не вылетит.
в Kanban не выставляются итерации работы по времени.
Канбан не запрещает итерации, а только разрывает зависимости между различными активностями. Например, наша команда использует Канбан, и у нас встречи по пополнению очереди происходят два раза в неделю. Никто не запрещает устраивать эти встречи раз в неделю или реже.
В Kanban важно следить за приоритетами
Канбан-сообщество, во главе с Дэвидом Андерсеном (создателем Канбана), активно стараются избавиться от понятия "приоритет" (те самые пресловутые Low, Medium, High, Blocker или числовые приоритеты) в пользу классов поставки и типов задач.
Ну и еще отмечу, что Канбан может нарушать ценности Agile.
Стимул от пользователя - это и есть стимул от окружающего мира. Но тут нужен стимул из внутренних систем. Пользователь уже закончил сессию с системой, забыл про нее, а тут внезапно приходит: "Слушай, а ты упоминал Меанотек в нашей последней беседе. Это что вообще такое?"
Но это пассивная способность. Вопрос нейросетью может быть задан только в ответ на фразу интервьюера. Нейронки пассивны и не инициируют диалог сами, нужен стимул от пользователя
Lev не реализует свою СУБД, для поиска или перебора файлов Lev пользует обычные функции файловой системы.
Вы организуете хранение данных в файлах, это тоже БД, просто не классическая реляционная, типа MySQL или Postgres. А если есть БД, то есть и СУБД. Модули чтения и записи в файлы, даже если они используют обычные функции файловой системы - это и есть ваша самописная СУБД.
Прочтите определение термина "База данных" хотя бы на той же Википедии:
У вас есть данные, есть схема (без схемы вы не знали бы, как данными можно манипулировать), есть манипулирование данными.
Систе́ма управле́ния ба́зами да́нных, сокр. СУБД (англ.Database Management System, сокр. DBMS) — совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных[1].
У вас есть технические средства для использования баз данных - пресловутые fread/fwrite.
Еще раз: СУБД - это не только РСУБД.
И, в конце концов, классические БД - это те же fread/fwrite под капотом.
Не знаю, как сейчас в Yii или Laravel, но в Symfony ORM по умолчанию не идет, ее нужно подключать отдельно. Если БД не нужна, то и пакет не подключаешь;
Вы говорите, что СУБД не нужна, но сами реализуете свою собственную СУБД, работающую на файлах (если я правильно понял). Или для вас СУБД - это только реляционные СУБД?
"Мультисайтовость" можно делать и на Symfony: выносишь vendor в отдельное место, весь кастомный код для каждого отдельного сайта натравливаешь на этот единый для всех vendor. Только зачем, если удобнее держать независимые версии vendor для каждого сайта? Вам жалко несколько десятков мегабайт?
Как будто конфиги в yaml - это что-то уникальное для Lev. В Symfony они уже давно, и во многих случаях от них сейчас отказываются в пользу PHP/Annotations по ряду причин.
ООП сформировалось полвека назад, за это время оно прошло серьезную эволюцию. Более того, те принципы, которые вы проповедуете, были описаны много позже самого появления понятия ООП.
Если для вас неучи - это те, кто не застрял в семидесятых, то ок.
И ООП нас учит, что нужно так декомпозировать объекты реального мира на классы, чтобы они содержали бы в себе и состояние, и поведение вместе. В этом по сути базис ООП.
А еще в принципах ООП указано Наследование. Однако уже давно определено, что наследование часто бывает вредным.
Само заявление, что класс должны содержать в себе и состояние (если здесь идет речь именно про динамическое состояние, а не readonly зависимости при DI) и поведение вместе, довольно спорное. Оно актуально для некоторых паттернов, таких, как Builder. Но для слоя бизнес-логики подобный подход стоит использовать с осторожностью.
Четвертое, я периодически сталкиваюсь с мнением, что в Юнити нужно минимизировать использование MonoBehaviour? Но, почему?
Для начала, MonoBehaviour - это достаточно дорого для производительности.
Второе - это проблема с отслеживанием зависимостей и взаимодействия различных систем между собой.
В Mass Effect не играл, но наслышан. Боюсь, что захейтили его далеко не только за баги.
Контр-пример: TES. Сколько уж там багов, а люди все равно всем сердцем любят эту серию.
Второй пример - это Cyberpunk. Сколько его критиковали на старте. Но ничего, через пару лет подлатали дыры, и игру любят и покупают.
Но не это главное. Главное, что разработка игр - это всегда огромное количество экспериментов по игровым механикам. Львиная доля этих экспериментов потом выпиливается из релиза. То есть, огромное количество кода просто выбрасывается на помойку. Именно в таких случаях подход "сделал на коленке, потом допилил до удовлетворительного состояния" очень хорошо себя показывает.
Добро пожаловать в реальный мир, где проект может вообще не взлететь, и все потраченные ресурсы будут выброшены.
Добро пожаловать в реальный мир, где проект может измениться до такой степени, что написанный код просто выкинется или станет неузнаваемым.
В такой изменчивой среде делать преждевременные оптимизации - это через чур оптимистично. Если вдруг окажется, что код прижился и такая же логика понадобится в других местах - тогда и реализовывать переиспользуемое решение.
Все деньги заработает тот, кто первый выставит продукт на рынок, а не тот, кто заложит лучшую архитектуру
Ощущение, что прочел статью, сгенерированную нейросетью. Вроде общий смысл улавливается, но предложения как-то слабо связаны друг с другом.
По теме автоматизации: был у меня знакомый, для которого идеальная работа - наматывать проволоку на катушки. Без стремлений, без амбиций, без желания что-то привнести в мир. Вы мне платите копеечку, а я буду проволоку наматывать. Идеальный биоробот. А роботов, случается, заменяют на более совершенные модели.
Автолевелинг там только на случайных монстрах. Но статично прописанные НПЦ там не скейлятся вместе с игроком. Именно поэтому однажды приходит приятное осознание, что теперь, наконец, ты можешь прикончить Умбру или Дивайта Фира)
По мне так это все словоблудие. Разработчик просто более широкое понятие, так как разрабатывать можно не только ПО, но и, например, месторождения полезных ископаемых или прототип автомобиля. Но в IT-среде разработчик и программист - тождественные понятия
Везде засветился тот же Пименов, но это не удивительно, он один из главных евангелистов канбана в России.
Если есть много времени и хочется углубиться больше, то книга создателя канбана Дэвида Андерсена "Альтернативный Путь в Аджайл", хотя она уже довольно устарела.
И, конечно, ссылка от товарища Apathetic.
Тут надо отметить, что информация о канбане от ресурса к ресурсу разнится. Это связано с тем, что канбан очень живой и постоянно эволюционирует. А в русском сегменте это усугубляется часто неправильными переводами и, следовательно, неверным пониманием некоторых моментов
А можете, пожалуйста, привести пример, как вы используете Quick Commands? Пока не придумал ничего полезного, но может вдохновлюсь вашими идеями)
Интересно было бы посмотреть на смешение сеттингов. Можете, пожалуйста, сгенерировать что-то вроде
Dark lord Darth Dovahkiin, photorealistic style
Или
Obi Van Kenobi mutated to zerg, game screenshot style
?
Осталось разработать нейросеть, умеющую анимацию, и инди-разработчикам будет раздолье
*Service - плохая практика, так как мотивирует напихать туда всего, так же как и *Manager и подобное. Если не получается подобрать подходящее имя класса (например PostCreator, ProductFinder и т.д.), то сразу возникает мысль, не нарушается ли здесь SRP?
Из суффиксов Controller и Repository по крайней мере можно понять домен использования, поэтому оно больше полезно, чем вредно.
Заранее прошу прощения, немного подушню.
Почему-то очень часто встречается мнение, что Канбан - это как Скрам, только без спринтов. Это в корне неверное утверждение: Канбан и Скрам - это вещи, которые акцентируются на разных аспектах. Более того, Канбан и Скрам можно применять одновременно, и вселенная от этого не схлопнется, эксепшн не вылетит.
Канбан не запрещает итерации, а только разрывает зависимости между различными активностями. Например, наша команда использует Канбан, и у нас встречи по пополнению очереди происходят два раза в неделю. Никто не запрещает устраивать эти встречи раз в неделю или реже.
Канбан-сообщество, во главе с Дэвидом Андерсеном (создателем Канбана), активно стараются избавиться от понятия "приоритет" (те самые пресловутые Low, Medium, High, Blocker или числовые приоритеты) в пользу классов поставки и типов задач.
Ну и еще отмечу, что Канбан может нарушать ценности Agile.
Стимул от пользователя - это и есть стимул от окружающего мира. Но тут нужен стимул из внутренних систем. Пользователь уже закончил сессию с системой, забыл про нее, а тут внезапно приходит: "Слушай, а ты упоминал Меанотек в нашей последней беседе. Это что вообще такое?"
Но это пассивная способность. Вопрос нейросетью может быть задан только в ответ на фразу интервьюера. Нейронки пассивны и не инициируют диалог сами, нужен стимул от пользователя
Вы организуете хранение данных в файлах, это тоже БД, просто не классическая реляционная, типа MySQL или Postgres. А если есть БД, то есть и СУБД. Модули чтения и записи в файлы, даже если они используют обычные функции файловой системы - это и есть ваша самописная СУБД.
Прочтите определение термина "База данных" хотя бы на той же Википедии:
Ба́за да́нных — совокупность данных, хранимых в соответствии со схемой данных, манипулирование которыми выполняют в соответствии с правилами средств моделирования данных[1][2][3].
У вас есть данные, есть схема (без схемы вы не знали бы, как данными можно манипулировать), есть манипулирование данными.
Систе́ма управле́ния ба́зами да́нных, сокр. СУБД (англ. Database Management System, сокр. DBMS) — совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных[1].
У вас есть технические средства для использования баз данных - пресловутые fread/fwrite.
Еще раз: СУБД - это не только РСУБД.
И, в конце концов, классические БД - это те же fread/fwrite под капотом.
Не знаю, как сейчас в Yii или Laravel, но в Symfony ORM по умолчанию не идет, ее нужно подключать отдельно. Если БД не нужна, то и пакет не подключаешь;
Вы говорите, что СУБД не нужна, но сами реализуете свою собственную СУБД, работающую на файлах (если я правильно понял). Или для вас СУБД - это только реляционные СУБД?
"Мультисайтовость" можно делать и на Symfony: выносишь vendor в отдельное место, весь кастомный код для каждого отдельного сайта натравливаешь на этот единый для всех vendor. Только зачем, если удобнее держать независимые версии vendor для каждого сайта? Вам жалко несколько десятков мегабайт?
Как будто конфиги в yaml - это что-то уникальное для Lev. В Symfony они уже давно, и во многих случаях от них сейчас отказываются в пользу PHP/Annotations по ряду причин.
ООП сформировалось полвека назад, за это время оно прошло серьезную эволюцию. Более того, те принципы, которые вы проповедуете, были описаны много позже самого появления понятия ООП.
Если для вас неучи - это те, кто не застрял в семидесятых, то ок.
А еще в принципах ООП указано Наследование. Однако уже давно определено, что наследование часто бывает вредным.
Само заявление, что класс должны содержать в себе и состояние (если здесь идет речь именно про динамическое состояние, а не readonly зависимости при DI) и поведение вместе, довольно спорное. Оно актуально для некоторых паттернов, таких, как Builder. Но для слоя бизнес-логики подобный подход стоит использовать с осторожностью.
Для начала, MonoBehaviour - это достаточно дорого для производительности.
Второе - это проблема с отслеживанием зависимостей и взаимодействия различных систем между собой.
В Mass Effect не играл, но наслышан. Боюсь, что захейтили его далеко не только за баги.
Контр-пример: TES. Сколько уж там багов, а люди все равно всем сердцем любят эту серию.
Второй пример - это Cyberpunk. Сколько его критиковали на старте. Но ничего, через пару лет подлатали дыры, и игру любят и покупают.
Но не это главное. Главное, что разработка игр - это всегда огромное количество экспериментов по игровым механикам. Львиная доля этих экспериментов потом выпиливается из релиза. То есть, огромное количество кода просто выбрасывается на помойку. Именно в таких случаях подход "сделал на коленке, потом допилил до удовлетворительного состояния" очень хорошо себя показывает.
Добро пожаловать в реальный мир, где проект может вообще не взлететь, и все потраченные ресурсы будут выброшены.
Добро пожаловать в реальный мир, где проект может измениться до такой степени, что написанный код просто выкинется или станет неузнаваемым.
В такой изменчивой среде делать преждевременные оптимизации - это через чур оптимистично. Если вдруг окажется, что код прижился и такая же логика понадобится в других местах - тогда и реализовывать переиспользуемое решение.
Все деньги заработает тот, кто первый выставит продукт на рынок, а не тот, кто заложит лучшую архитектуру
Ощущение, что прочел статью, сгенерированную нейросетью. Вроде общий смысл улавливается, но предложения как-то слабо связаны друг с другом.
По теме автоматизации: был у меня знакомый, для которого идеальная работа - наматывать проволоку на катушки. Без стремлений, без амбиций, без желания что-то привнести в мир. Вы мне платите копеечку, а я буду проволоку наматывать. Идеальный биоробот. А роботов, случается, заменяют на более совершенные модели.
Black Mesa вообще отличная. Но ее и делали фанаты HL1, олдскульщики
Автолевелинг там только на случайных монстрах. Но статично прописанные НПЦ там не скейлятся вместе с игроком. Именно поэтому однажды приходит приятное осознание, что теперь, наконец, ты можешь прикончить Умбру или Дивайта Фира)
По мне так это все словоблудие. Разработчик просто более широкое понятие, так как разрабатывать можно не только ПО, но и, например, месторождения полезных ископаемых или прототип автомобиля. Но в IT-среде разработчик и программист - тождественные понятия
У вас интересный опыт, но странные выводы: негативное отношение к Аджайлу, когда в вашей фирме его толком и не было.
Если мошенник продаст вам фейковый Айфон, ругаться из-за низкого качества вы будете на Эппл?
Какая милая наивность)
Алексей Пименов хорошо рассказывает про канбан, можно поискать его материалы.
Несколько хороших статей можно найти на https://scrumtrek.ru/blog/kanban/, можно начать с https://scrumtrek.ru/blog/kanban/1360/chto-takoe-kanban-metod-maksimalno-korotko/, чтобы получить первое представление.
В Яндекс.Музыке есть годный подкаст Kanban Talks.
Везде засветился тот же Пименов, но это не удивительно, он один из главных евангелистов канбана в России.
Если есть много времени и хочется углубиться больше, то книга создателя канбана Дэвида Андерсена "Альтернативный Путь в Аджайл", хотя она уже довольно устарела.
И, конечно, ссылка от товарища Apathetic.
Тут надо отметить, что информация о канбане от ресурса к ресурсу разнится. Это связано с тем, что канбан очень живой и постоянно эволюционирует. А в русском сегменте это усугубляется часто неправильными переводами и, следовательно, неверным пониманием некоторых моментов