0 просмотренных постов скрыто
Пятничный мем
Показать полностью
1
Как мы потеряли веру в игрожур
В наше избалованное время потребитель имеет доступ к огромному разнообразию всякого контента. Чтобы в этом хоть как-то ориентироваться, существует великое множество изданий, «независимых» блогеров и «честных» журналистов. Мы уже привыкли, что по десятибалльной шкале оценка меньше 8 означает чуть ли не провал. Происходит некая инфляция оценок и мнений, которая мне вообще не нравится, но тут се ля ви...
Что в таком случае делать? Самый логичный и простой вариант — найти того обзорщика, с кем у тебя приблизительно совпадает вкус, и потом ориентироваться на него. Да, поначалу будет проблема проанализировать и отсеять негодные варианты, но потом процесс поиска, во что бы поиграть, будет достаточно прост. Как правило, большим агрегаторам невыгодно писать разгромные рецензии, ведь на них есть рычаги давления и помимо занесения чемодана денег незадолго до релиза игры. Поэтому лучше всего найти хотя бы с виду независимого небольшого обзорщика, с кем у вас совпадает вкус.
А если вы думаете, что эта тенденция сформировалась недавно, то я сейчас вам расскажу, как игропресса встретила выход «Корсаров 3», и было более 20 лет назад, в конце 2005 года. Широко известен тот факт, что игра вышла недоделанной; ходит байка, что в офис разработчиков ворвался представитель издательства «1С» и чуть ли не силой забрал последнюю версию игры с легендарным уже индексом версии 0.99. С ним она и вышла в печать. Впрочем, акелловцы будут всячески отмазываться, так что, возможно, эти оправдания просто лапша на уши игроков.
А что же оценки «независимых» игроСМИ? Вот тут и зарыт цирк с конями, после которого российские игроки потеряли всяческую веру в журналистов, освещающих игры. Ну ладно, не всякую: до релиза Lada Racing Club оставалось ещё чуть больше года, и там прогрев был гораздо более сильным. Но и небольшого шторма хватило для раскачки команды корабля «Корсаров 3».
А началось всё с роскошной презентации, устроенной компаниями «Акелла» и «1С» 8 декабря 2005 года в московском ресторане «Джон Сильвер». Из заснеженной столицы журналисты попадали на закрытую палубу корабля, увешенную пиратскими флагами и черепами. Дубовые столы ломились от яств, а основным напитком вечера, конечно же, стал ром, который лился рекой вперемешку с пивом и портвейном. Каждый гость сразу получал пресс-пакет с DVD-боксом игры за сутки до официального релиза и гору сувенирной продукции: футболки, ручки, наклейки.
Главной заводилой этого пиршества стала рыжая «пиратка» и капитанша корабля, в которой даже самые отбитые пиарщики мигом опознали Ирину Семёнову — руководительницу пиар-отдела «Акеллы». Она перевоплотилась в Беатрис, героиню игры, и устроила «допрос с пристрастием» для «пленённых» представителей издательства. Журналистам выдали роль инквизиторов, и те, воодушевлённые бесплатным ромом и возможностью покрасоваться, с энтузиазмом тянули руки за призами. А призы, надо сказать, были не спички с логотипом: акустические системы и домашние кинотеатры от компании AVE падали в руки победителям, как сундуки с золотом после удачного абордажа.
Помимо «пыток» издателей, гостей ждала демо-зона с компами — можно было на полчаса притвориться, что ты тут по делу. А для тех, кто пришёл не столько играть, сколько гулять, работали бильярд, игральные кости, метание дротиков и конкурс признаний в любви капитанше. Кульминацией вечера стали зажигательные танцы некой красавицы Клементины — под одобрительные крики и звон стаканов. Гулянье закончилось далеко за полночь; некоторые «независимые» журналисты покидали корабль на ватных ногах, бережно прижимая к груди коробки с игрой и предчувствуя завтрашние хвалебные рецензии.
И они таки последовали. «PC - игры»: «А вообще третьи "Корсары" удались на славу. Тут тебе и красоты морей-океанов, и напряженные бои, и торговля, и приключения. Где-то прослеживается сходство с Sid Меегs Pirates: ровно настолько, чтобы понять, что нашей игре глубины не занимать. "Корсары" — это настоящий, полноценный симулятор веселой морской жизни». 8.5 — таков был итоговый вердикт.
«Навигатор игрового мира»: «Жаль, что эта игра не вышла раньше, и мы потеряли столько драгоценного времени на убогие “пиратские” поделки (Во! Неплохой каламбур вышел). Но я рад, что эта игра, наконец, у меня в руках. И что ее достоинства с горкой превышают ее недостатки. Играть в нее можно долго, чего вам и советую». 8.8 баллов.
«Страна игр: «Просто еще одна красивая игра про пиратов. Подарок фанатам ”Корсаров”». 7.5 баллов.
Согласитесь, это звучало издевательски на фоне того, что, во-первых, игра изначально была в принципе непроходима, во-вторых, очень часто она в принципе не запускалась, каждый раз выдавая разные ошибки. Справедливости ради отмечу, что не все СМИ так облизывали релиз: примерно половина недоумённо говорили, что это какой-то провал невиданного масштаба. Наверное, это были те, кому не достался домашний кинотеатр...
Хоть «Акелла» оперативно патчила игру, репутационный удар как пробоину под ватерлинию компания таки получила. Несмотря на коммерческий успех, выпуск сырого и багнутого продукта в конечном итоге послужил катализатором развала. После ещё будут локальные успехи, и даже в линейке «Корсаров», но потом такие релизы будут чуть ли не нормой. Это и погубит компанию (как и финансовый кризис 2008 года, от которого «Акелла» до конца не оправится).
Это потом начнут релизить игры с припиской «ранний доступ», типа не бейте сильно, видите, у нас игра толком не готова? Вы нам её бесплатно (купив за свои кровные) потестите, а потом, может быть, мы её доведём до ума. Ну а насколько смелости журналистам хватит облизывать такую, с позволения сказать, игру, если, не сделав этого, они будут отлучены от кормушки? В этом и суть игрожура. Дилемма: либо ты свой и в системе, имеешь на игру с маслом, либо пишешь правду и нужен немногим подписчикам. Выбирайте.
Поэтому, когда в следующий раз увидите очередной восторженный обзор на игру, выходящую «чуть сыроватой», а потом разгром купивших и купившихся игроков в Стиме — вспомните ту самую презентацию в «Джон Сильвере». Вспомните рыжую Беатрис и домашние кинотеатры AVE. Не упало ли ваше доверие где-то между «сногсшибательной графикой» и первым вылетом на рабочий стол?
Потому что единственный действительно независимый обзорщик — это вы сами. Ваш собственный опыт, ваши сэкономленные деньги и потраченное время. А всё остальное — просто пираты, делящие добычу. И неважно, 2005 год или 2026‑й. Просто теперь у пиратов вместо сабель — промокоды, а вместо рома — бабл-ти из спонсорской зоны.
Поднимайте якоря, господа котогики. И помните: если вам ставят 8.5 до выхода патча — бегите. Бегите быстрее, чем от пиратского брига с двадцатью пушками.
Автор текста: Алексей Цибенко. Написано специально для CatGeek и читателей Pikabu
🎮 🎲 Также читайте и смотрите нас на других ресурсах:
Мы всегда рады новым авторам. Если хотите предложить статью на CatGeek или заинтересованы в сотрудничестве — пишите сюда или сюда.
Может быть интересно:
Показать полностью
1
Как не превратить архитектуру в 1С в ком грязи?
Стриму по DDD быть.
Вижу, что интерес есть, поэтому ставим дату:
Четверг 23 июля в 19:00 МСК
Тема: «DDD и слои в 1С-разработке с примером конфигурации, кодом и разбором, как это применять в 1С мире»
Пока по количеству регистраций мы вмещаемся в закрытый Zoom. Если так и останется, то сделаем камерный формат без записи: спокойно все обсудим и пообсуждаем голосом.
Если доберем 200+ регистраций, тогда проведем большой стрим с записью.
На стриме разберем:
👉 почему думать от UI или метаданных — путь к комку грязи в архитектуре;
👉 что такое «проектирование архитектуры» на самом деле;
👉 как выделять слои и зачем они нужны;
👉 как проектировать домен по DDD;
👉 зачем вообще нужен DDD, если у нас есть справочники, документы, регистры и типовые механизмы;
Пока с активностью в канале приторможу.
Подготовка сложная, потому что тема большая и хочется показать не теорию ради теории, а реальный практический пример.
Если хотите попасть на стрим — регистрируйтесь в боте.
По количеству регистраций финально выберем формат: закрытый Zoom без записи или большой стрим с записью.
Регистрируйтесь тут: https://r.bothelp.io/tg?domain=topgamemakers_bot&start=c...
Показать полностью
1
Архитектура никому не нужна?
Вчера жена сказала мне неприятную вещь.
Мы обсуждали планы на ближайшие две недели, и оказалось, что много времени уйдёт на подготовку к стриму по DDD в 1С. Я хочу не просто выйти и поговорить про DDD и хорошую архитектуру, а доработать типовую конфигурацию и показать, как DDD и слои могут выглядеть в 1С. Показать, какие задачи можно с помощью такого подхода решать.
Я поделился, что после тестов по архитектуре у меня странное ощущение 🤔
Вроде бы большинство отвечает правильно.
Видит ошибки.
Понимает, где проблема.
А потом пишут:
“У нас так никто не делает”.
“Это должна вся команда так писать”.
“В реальных проектах на это нет времени”.
“Мы всё понимаем, но работаем как работаем”.
И вот жена смотрит на меня и говорит:
«Жень, тебе не кажется, что эта архитектура никому не нужна, кроме тебя? Ты сейчас две недели будешь носиться с этой конфигурацией, готовить стрим, разбирать DDD и чистую архитектуру.
А может, это мало кому нужно? Может, лучше уехать в отпуск, лечь у бассейна и нормально отдохнуть?
Потому что людям, кажется, интересно пообсуждать архитектуру, поставить правильный ответ в тесте, написать умный комментарий.
Но применять это в работе — нет.
И тогда зачем тебе делать стрим, если в итоге это нужно трём людям?»
И я расстроился...
Первое желание — спорить и сказать, что архитектура нужна.
Что без неё 1С-проекты превращаются в ком грязи, который страшно трогать.
Что “нет времени на архитектуру” потом превращается в “нет времени на добавление новых фич”.
Гнев прошел и пришлось согласиться, что вопрос нормальный.
Проблема в пропасти между: “я понимаю” и “я так пишу”.
И мне интересно, насколько эта пропасть вообще кому-то мешает. Может, я правда смотрю на это через свою профессиональную деформацию. А может, рынку достаточно знать, как правильно, но продолжать писать как принято.
Отсюда вопрос👇
Вам нужен большой стрим, где я покажу, как DDD и чистая архитектура могут выглядеть в 1С мире?
Или это тема для закрытого разбора в ZOOM на несколько человек, которым реально надо так писать, а не просто послушать?
Сделал голосовалку в боте, который сохранит ваш ответ и пригласит на тот формат, за который вы проголосуете.
Жду ваши честные ответы
Голосовать тут: https://r.bothelp.io/tg?domain=topgamemakers_bot&start=c...
Показать полностью
1
Есть ли доказательства, что архитектура работает?
Стас требует доказательства, что хорошая архитектура помогает решить проблему превращения кода приложения в большой ком грязи.
Проблема выглядит так:
кодовую базу все еще можно запускать, но развивать ее становится все тяжелее. Разработчики все больше времени тратят на исправление ошибок, согласование изменений и понимание старого кода, а не на развитие функциональности.
Сразу замечу: Мартин и его «Чистая архитектура» — не единственный пример хорошего архитектурного подхода. Есть еще гексагональная архитектура, луковая архитектура. Все эти подходы говорят об одном: защищайте бизнес-логику от UI, хранилищ, фреймворков и прочей инфраструктуры.
Нашел исследования по этой теме. Они сводят эту проблему к конкретным цифрам:
— времени
— ошибкам
— стоимости сопровождения
👉 В исследовании Code Red: The Business Impact of Code Quality https://ar5iv.labs.arxiv.org/html/2203.04374 изучили 39 реальных промышленных кодовых баз и активность в 30 737 файлах. Авторы связывали качество кода с задачами из системы учета, историей изменений и временем разработки.
Выводы такие:
— код низкого качества содержит примерно в 15 раз больше дефектов;
— задачи в таком коде решаются на 124% дольше;
— худшие случаи по времени решения становятся примерно в 9 раз длиннее.
Плохая архитектура — это больше ошибок, больше времени на задачи и хуже предсказуемость разработки.При этом проблема не просто в количестве строк. Большой файл сам по себе еще не проблема. Беда начинается, когда код трудно понимать и менять: обязанности перемешаны, методы и классы разрастаются, а одно изменение требует держать в голове слишком много неявных связей.
👉 Другая статья — Technical Debt and System Architecture https://www.hbs.edu/ris/Publication Files/2016-JSS Technical Debt_d793c712-5160-4aa9-8761-781b444cc75f.pdf . В ней исследовали две большие системы: примерно по 20 000 компонентов в каждой. Авторы смотрели на связность компонентов:
— кто от кого зависит
— где появляется центральный клубок
— насколько изменение в одном месте может потянуть изменения в других
Там хорошо видно, что дефекты распределяются по системе неравномерно.
В первой системе центральные компоненты составляли около 31% файлов, но давали почти 70% всей работы по дефектам. При этом периферийные и изолированные файлы составляли около 30% системы, но давали всего 1.1% работы по дефектам.
Во второй системе ядро составляло около 26% файлов, но давало около 62% всей работы по дефектам. В этой же системе дефекты в 5.8% периферийных файлов.
То есть проблема в том, что внутри появляется связанный центр, через который проходит слишком много изменений. Исправляешь одно место — задеваешь другое. Добавляешь новую возможность — неожиданно ломаешь старое поведение.
В этой же работе есть финансовая оценка.
В одной из систем строка кода в центральных компонентах стоила в сопровождении в 15 раз дороже, чем строка кода на периферии.
👉 Еще одно крупное исследование — работа Google Understanding Architectural Complexity, Maintenance Burden, and Developer Sentiment https://par.nsf.gov/servlets/purl/10590239
Там изучили 1252 проекта на C++ и Java и данные по 7200 разработчикам. Авторы смотрели на архитектурную сложность через несколько признаков:
— насколько изменения могут распространяться по системе
— насколько части системы развязаны между собой
— сколько есть циклов между файлами и других структурных проблем
Вывод из исследования:
чем больше связность, чем больше циклов между файлами и проблемного наследования, тем меньшая доля работы уходит на новые возможности и тем большая — на исправление ошибок.
===
Итого
Плохая архитектура приводит к тому, что:
— становится больше ошибок;
— задачи делаются дольше;
— больше времени уходит на исправления вместо новых возможностей;
— центральные компоненты становятся дорогими в сопровождении;
— изменение одного места заставляет проверять слишком много связей.
Хорошая архитектура решает обратную задачу: уменьшает связность, ограничивает распространение изменений и не дает бизнес-логике утонуть в UI, базе данных и инфраструктуре.
Вопрос в том, есть ли в системе границы, которые помогают ей развиваться
👉 Подписывайся на @YellowClub,
Показать полностью
1
Как безрукий программист
Показать полностью
2
1С Специалист (подготовка к экзамену)
Приветствую всех пикабутян 1С-ников и прошу содействия в подготовке к специалисту по платформе.
Начал самостоятельно решать билеты, но столкнулся с проблемой проверки достоверности решения.
Вроде как всё верно по проводкам, но там за разные мелочи и не очень снимают баллы на экзамене.
Нашёл вот на инфостарте уже готовые решения по всем билетам, по которым вроде как можно будет даже не только сверяться, но и брать их за основы решений:
[2711959] Экзамен 1С:Специалист по платформе 8.3. ВСЕ решенные билеты экзамена (Июнь 2026)
*Решение ВСЕХ билетов + Новые Доп задачи + Полные конспекты*
Может есть тут альтруисты, которые могут взять полный набор или может у кого есть про подписка и он может на это всё потратить 10 стартмани?
Пожалуйста помогите!
P.S. Если вдруг 1С специалисты по платформе, кто уже сдал экзамен и получил сертификат, увидят сей пост, то поделитесь, что вам помогло успешно сдать экзамен и как вы сами к нему готовились.
Показать полностью