Всё нормализуется, но ухудшается качество. Основной показатель на который он влиял - стоимость привлечения клиента. Для некоторых видов бизнеса это основной показатель рентабельности. Так же это важный показатель стоимости открытия нового направления работ и нового бизнеса(т.к. у них нет клиентов на старте).
Ну и немного упадёт социалочка(ДМС), высокие ЗП специалистов и инженеров(потому что местные столько не платят даже близко), людской ресурс(уедут, т.к. тут платят мало и нет работы). Снизится качество экспертного сообщества(знания без дела исчезнут). Сильно снизившиеся налоги с рекламы пусть и не очень то важны, но сильно упадут, т.к. с удорожанием и закрытием бизнеса просядет рынок. А вот прямо уникальных технологий не пропало.
Всё это не что-то ужасное. Если бы только это можно было бы сказать: "неприятности случаются". А когда аналогичная просадка по куче направлений? Год за годом всё больше?
Как раз добавление кучи однотипного кода приводит к проблеме. Условно, тебе говорят - почини вот ту фиговину, чтобы когда А, происходило B... А там 10 методов, отличающихся только условиями, причём условия из данных в другом пространстве. И ты не сможешь починить корректно без дополнительной инфы, да и потом надо будет искать 1 требуемый из 10.
Условиях из разных частей проекта будут как не разделяй. Иначе бы это были вообще отдельные программы.
Огромное кол-во классов мешает и набирать код(это не столь существенно), читать код, и изучать его. Лучше коммент с кодом внутри, если среда или язык не поддерживают вложенные функции. То же с классом, лучше метод приватный, чем публичный класс. Так приходим к тому, что лучше не высовывать наружу ни методов, ни код, но при этом именовать их, пусть и в комментариях. Конкретный подход сильно зависит от среды.
Кстати, отделение логики в классы-методы ещё не всё, можно пойти и дальше по пространству имён, пройтись по сборкам, модулям etc. Если позволяет среда или поиск с ИИ встроить, то можно и сильнее развернутся.
В 1.2 говорится о дезинформации. Нет никакой дезинформации в том, что получаем месяц в виде строки(название месяца), что вполне ясно по типу и названию. Иначе выходит, что любая строка с именем должна называться с Name? Это было бы весьма глупо В 1.5 вы говорите как раз так не делать, т.к. по типу ясно что там хранится.
Выделение класса - из существующего кода выделить класс(из любой части). Оно возможно вплоть до атомарных операций, тут важно знать когда начать и когда остановится. Большое кол-во классов и методов так же сильно путает. Эту проблему решает инкапсуляция на разных уровнях. Но это только уменьшает сложность, а не нивелирует её полностью. Поэтому важно где-то выделить классы, а где-то лучше методы, или даже оставить как есть. Максимум, в локальные для методов функции переложить что-то.
Не знаю за все типы игр, может какие-то и выискивают лудоманов. Но знаю, что в ММО в РФ часто крупнейшие платежи делали люди весьма богатые, либо их дети. И они давали основную часть выручки в проекте. Лудомании там явно не было, была просто покупка игрушки.
Вообще мысль интересная, наверняка так и бывает) Только лудоманы должны быть с деньгами, чтобы платить не 200, а хотя бы в 10 раз больше и не раз.
Вот прямо хз. Помню работали с BigFish - был именно такой %(это и платформа, и издатель, т.е. 30 за всё!). Я сам когда-то начинал, организовывал работу, было 30%, либо 50% + 1 млн(50к$) на разработку - вполне не плохо по тем временам. Попробую узнать по текущему партнёру условия, но тут более сложные условия и комплексное взаимодействие.
Могу сказать, что многие издатели просто красиво... пусть будет, выражаются. И много обещают. Но на деле не редко ни черта не делают. Особенно, когда от твоего проекта не ждут золотых гор. И это относится и к топовым издателям. А что они делают? Трафик? Легко покупается. Аналитика - нанять в команду отдельного человека и он сработает лучше. Пока ни разу не видел исключений. Каналы рекламы? Да это вообще не проблема - просто пишешь в личку всем по твоей тематике, все контакты сейчас онлайн, а цена... Ну на бюджет в 1 млн$ можно купить всех. По некоторым жанрам вообще (почти) бесплатно. Их рекламный опыт? А есть ли у них опыт именно в во всей индустрии? Я знаю проект, где издатель руководствуясь опытом угробил игру и ещё о парочке таких игр слышал. Потому что опыт в одном жанре у него был, а в жанре игры - нет. Потому, пытаясь из одной игры сделать удобное для манагеров издателя, они провалили проект ухудшив его показатели. Вообще, во времена такой сильной аналитики, там, часто всё ещё решают люди с чрезмерным ЧСВ.
Если заняться этим ещё на этапе разработки, то всё вполне не плохо может выйти. Полно игр сейчас выпускаются без издателя. Да, до прибылей ААА редко дорастают. Ну так и у EA и прочих гигантов не каждый раз выходит сверхприбыльная игра.
Это "ошибка выжившего": мы видим десятки игр, успешно запустившихся без издателя, но не замечает тысячи провалившихся Как мы не видим и тысяч провалившихся не смотря на работу с издателем. И ладно ещё провалившихся. Ведь издатель тупо может слить продукт, чтобы подвинуть другой продукт, который для него покажется перспективнее. И это не что-то редкое, а весьма частое явление. Но в массе своей без издателя шансов у продукта практически нет, независимо от его качества.
По мне так, это преувеличение. Очень сложно понять, где заслуга издателя, а где заслуга качества продукта как программы, а где решили именно игровые качества. Без аналитики вы этого не поймёте. Кстати, а есть у вас такая аналитика? Или издатель этим не занимается?
Не верю диаграмме, вот вообще. Есть разные схемы монетизации, но даже в вашем случае прямо противоречит тому, что я знаю. Издательство берёт 30%, но не от всей суммы продажи, а уже после комиссии, разве не так? Cost reimbursement - это возмещение затрат на разработку? Если так, то всё вполне радужно. 8+8+20=36%, с весьма не малой платой за сопровождение и площадки, или иначе - прибыль 80% от стоимости проекта. Даже для российского бизнеса это весьма хорошо.
А так то есть схемы с 50%-70% издателю, где часть расходов или даже все расходы на себя возьмёт издатель. Есть возможности и самостоятельно провести рекламную без платы издателю или изначально делать под стим и попасть под его рекламу, вполне годную. Ну или оказаться в этом как бы издателе, к примеру, в Tencent(на минутку, чистая прибыль более 100 млрд$ в 22).
Для PC игр(не MMO) и без издателя вполне хорошо можно справиться, что многие и делают. А вот в мобилках же вообще всё зависит от рекламы. Прибыль издателей так же на много больше, чем самих разработчиков. Можно сказать, что рынок захватили издатели. Даже больше - они захватывают игровые движки
Обработка большого объёма данных и принтеры материи вообще могут перевернуть всё. И для этого текущего технологического развития достаточно. Пока что мы очень слабо подвинули материальную подготовку, различными уловками узнавая что-то новое. Сейчас куча не фундаментальных знаний так и только в бумаге, т.к. их не получается использовать.
А проблему замедления науки вижу в том, что сейчас очень сложно проводить эксперименты - нужно много данных и штучные экспериментальные установки. Очень дорого и в учёных, и в материальных средствах. Земля, и то, что можно тут легко собрать не дают сильной подвижки.
Сколько тут понаписали... Однако, есть полно компаний, в которых джунов используют именно так. И это не только GC в геймдеве, круд, формошлёпство. Операционку так не сделать, но более 90% бизнеса и не нуждается в хорошем подходе. А так-то и отдельные сервисы так пилить можно, типа яндекс-такси, когда карты делает отдельная команда.
1.5 и пример в 1.2 противоречивы. Получение имени с указанием типа - явно же, что раз это строка-месяц, то ожидается строка с названием месяца. Примерно то же со всеми перегрузками функций.
Ну и немного по указаниям типа в IDE . i в начале - позволяет проще искать среди нужного типа. Но, всё же, скорее стоит отказаться от использования маркеров в слове.
Не про идеальный код, но всё же. Выделение класса - это оформление работы как класса, т.е. некоторая универсальность применения. Не редко это просто на много дороже для того, что не имеет иной реализации и не планируется использовать иначе. Поэтому делим только до функции, а дальше забываем пока аналогичный не потребуется ещё где-то. Хорошо, если язык позволяет использовать эрзац-классы(кортежи в C#) без функционала. Это помогает и структурировать, и классы не штамповать на каждый чих.
По мне так ровно наоборот. Рассчитываете, что у вас коллектив выучит все основные переменные, а это вообще не должно происходить.
Ну и новички не будут разбираться в коде. А одно дело посмотреть поблизости чем занимается локальная переменная, а другое - искать во всём коде, чем же занимается занимается класс и не поломается ли это что-то при использовании.
Ну и в целом по длине, пусть и 20 символов, но их даже переименовать можно "парой" нажатий клавиш. А при наборе IDE так же все 20 набирать не надо, часто вообще столько же, сколько и у короткого имени.
Я вот как раз работаю над одним проектом, где всё просто в лоб делается. На базовую клиент-серверную дробилку данных навешан максимально простой код. И пока логика была линейна и функцонала мало - всё было очень просто. Но оказалось, что в таблицах легко вбивается чушь и код это ест, работает, но выдаёт чушь. Там где уже надо было делать код на классы работает 3 разных метода с копипастом на 80%+, каждый состоит из пары десятков условий, которые очень сильно разносятся между собой и находятся в разных областях знания о проекте. В каждом методе куча условий на входе, которые тихо прекращают выполнение if (bool) return; Справедливости ради, читать там в большинстве случаев легко. Только в каждом методе может потребоваться знание о любой части проекта. А изменение может поменять логику непредсказуемым образом, но отработать без ошибок.
Так вот, изменять его можно легко только продолжая писать как раньше. Иначе надо переписывать огромными кусками. Т.е. если надо побыстрее сделать мелкую правку , то просто дописываем ставя ещё один условный оператор во все места и молимся рандому. На деле это очень бытсро и просто, если случайно никак не заденешь кор загрузки и сети.
Интереснее с расширением функционала. В таком случае мелкой правкой не обойтись. Меняешь в одном месте, другом. А потом оказывается, что в приложении есть ещё место, которое работает по старой логике, а так же пара мест очень старой логики, где уже забыли внести изменения до старой логики, но внесли другие изменения. Уже на много веселее, с кучей дополнительных согласований по логике с дизайном проекта. В принципе, это ещё не так сложно, если есть исчерпывающая документация, которая распишет каждое условие в линейной логике. Я такую не видел очень давно. Да и там условия не только от бизнеса, но и от внутренней структуры переплетены.
С добавлением функционала так же просто, пока он не задевает логику старого. А вот если затрагивает, то опять как с расширением, только сложнее. Проще переписать ту часть с 0, хотя бы по частям.
Я бы ещё добавил, что взгяд опирается не столько на код, сколько на дизайн задачи. Ищешь сначала по представлению того как должно быть(множество вариантов), потом уже по коду. И правки стараешься так же делать, не опираясь на текущую реализацию кода. Иногда бывает, что и несколько мест вместо одного приходится переписать для этого.
Куда ни плюнь - ответственность высокая. По мне так, общепит - очень ответственная профа. Приготовишь плохо, стол не протрёшь, холерку занесёт и сядешь лет на много.
Ответственность - это не то, за что надо платить сильно больше. Ответственность в первую очередь должна быть на бизнесе(государстве). А её нет. Тогда и платить больше незачем. Ну и если где-то требуется высокая ответственность, то в первую очередь это говорит о том, что ответственность в этой сфере надо снимать с человека, а не доплачивать.
Я не говорю, что невозможно написать эквивалентный код. Можно. Достижимой она останется, но при условия меняются. И он бы выглядел примерно так: if (!newOption){ if (!(symbol_idleFX)) return; if (!idleFX) return;} if(nextReward == 0) return; Но для этого пришлось бы лезть внутрь функции и разбираться в её работе. Чем больше таких условий, тем больше шанс ошибки и меньше шанс корректной работы программиста, т.к. узнавать причины появления всех условий сложно и дорого. Поэтому программист просто напишет: if (!newOption)return; Т.е. это становится причиной того, что пишут кривой код. И она исходит из того, что функция не делает того, что должна по названию. В данном случае функция должна была показать награду, но она вместо непосредственно показа занималась ещё и валидацией данных(которая вообще должна быть на входе, а не тут), ну и логикой в решении, вообще показывать или нет.
Так бы и писали) Но это единственный коммент) Пожалуй, возвращение пустого ответа так же возможно, если только это будет обработано полноценно в дальнейшем, т.е. не является аналогом return; , точнее того же тихого выхода. Именно так было написано в начале этой ветки, что это уменьшает цикломатическая сложность(на деле - нет). В случае, когда возвращается какое-либо значение, то разницы по сравнению с обычным описанием нет.
Проблема не том, что это сложно понять - это всё легко понимается. Проблема в том, что часто постепенно логику из вызова переносят в функцию. И, условно, если в функции 5 ранних выходов(условий) затрагивающие 5 разных фич, то для корректной правки в этих условиях нужна инфа обо всех этих 5 фичах, т.к. правка может все их затронуть. Вот пример: if (!symbol_idleFX) return; if (!idleFX) return; if (nextReward == 0) return; Расчёт вознаграждения. Одно условие тут проверяет состояние, одно нужно для обработки, а ещё одно никак нигде не фигурирует и возможно завязано на бизнес-логику. И вот каким боком тут проверка symbol_idleFX вообще не понятно. Если новая фича будет не связана с этим параметром и функция должна будет отработать даже когда symbol_idleFX == false, то просто вызвать функцию уже будет нельзя. Нужно будет смотреть внутрь неё и проверять из-за чего она не работает.
Почему вы с таким не сталкиваетесь, не знаю. Возможно редко переиспользуете код или переиспользуете большими кусками? Меньше интенсивность работы? У меня проекты обычно поменьше, до 150к, но за год около 300к вполне может быть пере-/написано в этом проекте.
Такой некоммуникабельный, конечно, сильно ограничивает список задач для поручения. Но он учится. БольшАя часть хороших разработчиков - именно такие изначально. Но потом из таких могут получится и хорошие лиды.
Вот очень не люблю такой код. Если делать именно исключения - то всё ок. Если логику вносить - он путает. Поначалу ничего плохого, но вот потом...
Очень просто перенести логическую проверку с верхнего уровня на вызов функции, выставить ранний выход и радоваться выполненной задаче. А потом кто-то ещё будет работать с этой функцией, возможно из множества мест, а проверка будет приводить к преждевременному выходу. Из-за этого условие усложнится и туда добавят исключение(возможно даже протащив в функцию дополнительный опциональный параметр).
Ну и с логической стороны, если функцию вызываешь, то ожидаешь результат, а не тихое завершения без результата. В случае ошибки как раз всё ок - тихого завершения не будет. Да и при чтении такой код можно просто пропустить. А вот логику - нельзя.
Если вы не мало проектов глубоко перерабатывали, то возможно не раз и не два видели такое. У меня в практике встречалось чуть ли не в половине проектов. В двух проектах такой код разрастался до 20 проверок на функцию. Правда, те проекты весьма стары были, ещё с колбекным программированием.
Всё нормализуется, но ухудшается качество. Основной показатель на который он влиял - стоимость привлечения клиента. Для некоторых видов бизнеса это основной показатель рентабельности. Так же это важный показатель стоимости открытия нового направления работ и нового бизнеса(т.к. у них нет клиентов на старте).
Ну и немного упадёт социалочка(ДМС), высокие ЗП специалистов и инженеров(потому что местные столько не платят даже близко), людской ресурс(уедут, т.к. тут платят мало и нет работы). Снизится качество экспертного сообщества(знания без дела исчезнут).
Сильно снизившиеся налоги с рекламы пусть и не очень то важны, но сильно упадут, т.к. с удорожанием и закрытием бизнеса просядет рынок.
А вот прямо уникальных технологий не пропало.
Всё это не что-то ужасное. Если бы только это можно было бы сказать: "неприятности случаются". А когда аналогичная просадка по куче направлений? Год за годом всё больше?
Как раз добавление кучи однотипного кода приводит к проблеме. Условно, тебе говорят - почини вот ту фиговину, чтобы когда А, происходило B... А там 10 методов, отличающихся только условиями, причём условия из данных в другом пространстве. И ты не сможешь починить корректно без дополнительной инфы, да и потом надо будет искать 1 требуемый из 10.
Условиях из разных частей проекта будут как не разделяй. Иначе бы это были вообще отдельные программы.
Огромное кол-во классов мешает и набирать код(это не столь существенно), читать код, и изучать его. Лучше коммент с кодом внутри, если среда или язык не поддерживают вложенные функции. То же с классом, лучше метод приватный, чем публичный класс. Так приходим к тому, что лучше не высовывать наружу ни методов, ни код, но при этом именовать их, пусть и в комментариях. Конкретный подход сильно зависит от среды.
Кстати, отделение логики в классы-методы ещё не всё, можно пойти и дальше по пространству имён, пройтись по сборкам, модулям etc. Если позволяет среда или поиск с ИИ встроить, то можно и сильнее развернутся.
В 1.2 говорится о дезинформации. Нет никакой дезинформации в том, что получаем месяц в виде строки(название месяца), что вполне ясно по типу и названию. Иначе выходит, что любая строка с именем должна называться с Name? Это было бы весьма глупо
В 1.5 вы говорите как раз так не делать, т.к. по типу ясно что там хранится.
Выделение класса - из существующего кода выделить класс(из любой части). Оно возможно вплоть до атомарных операций, тут важно знать когда начать и когда остановится. Большое кол-во классов и методов так же сильно путает. Эту проблему решает инкапсуляция на разных уровнях. Но это только уменьшает сложность, а не нивелирует её полностью. Поэтому важно где-то выделить классы, а где-то лучше методы, или даже оставить как есть. Максимум, в локальные для методов функции переложить что-то.
Не знаю за все типы игр, может какие-то и выискивают лудоманов. Но знаю, что в ММО в РФ часто крупнейшие платежи делали люди весьма богатые, либо их дети. И они давали основную часть выручки в проекте. Лудомании там явно не было, была просто покупка игрушки.
Вообще мысль интересная, наверняка так и бывает) Только лудоманы должны быть с деньгами, чтобы платить не 200, а хотя бы в 10 раз больше и не раз.
Вот прямо хз. Помню работали с BigFish - был именно такой %(это и платформа, и издатель, т.е. 30 за всё!). Я сам когда-то начинал, организовывал работу, было 30%, либо 50% + 1 млн(50к$) на разработку - вполне не плохо по тем временам.
Попробую узнать по текущему партнёру условия, но тут более сложные условия и комплексное взаимодействие.
Могу сказать, что многие издатели просто красиво... пусть будет, выражаются. И много обещают. Но на деле не редко ни черта не делают. Особенно, когда от твоего проекта не ждут золотых гор. И это относится и к топовым издателям.
А что они делают? Трафик? Легко покупается. Аналитика - нанять в команду отдельного человека и он сработает лучше. Пока ни разу не видел исключений. Каналы рекламы? Да это вообще не проблема - просто пишешь в личку всем по твоей тематике, все контакты сейчас онлайн, а цена... Ну на бюджет в 1 млн$ можно купить всех. По некоторым жанрам вообще (почти) бесплатно.
Их рекламный опыт? А есть ли у них опыт именно в во всей индустрии? Я знаю проект, где издатель руководствуясь опытом угробил игру и ещё о парочке таких игр слышал. Потому что опыт в одном жанре у него был, а в жанре игры - нет. Потому, пытаясь из одной игры сделать удобное для манагеров издателя, они провалили проект ухудшив его показатели. Вообще, во времена такой сильной аналитики, там, часто всё ещё решают люди с чрезмерным ЧСВ.
Если заняться этим ещё на этапе разработки, то всё вполне не плохо может выйти. Полно игр сейчас выпускаются без издателя. Да, до прибылей ААА редко дорастают. Ну так и у EA и прочих гигантов не каждый раз выходит сверхприбыльная игра.
Это "ошибка выжившего": мы видим десятки игр, успешно запустившихся без издателя, но не замечает тысячи провалившихсяКак мы не видим и тысяч провалившихся не смотря на работу с издателем. И ладно ещё провалившихся. Ведь издатель тупо может слить продукт, чтобы подвинуть другой продукт, который для него покажется перспективнее. И это не что-то редкое, а весьма частое явление.
Но в массе своей без издателя шансов у продукта практически нет, независимо от его качества.По мне так, это преувеличение. Очень сложно понять, где заслуга издателя, а где заслуга качества продукта как программы, а где решили именно игровые качества. Без аналитики вы этого не поймёте. Кстати, а есть у вас такая аналитика? Или издатель этим не занимается?
Не верю диаграмме, вот вообще. Есть разные схемы монетизации, но даже в вашем случае прямо противоречит тому, что я знаю. Издательство берёт 30%, но не от всей суммы продажи, а уже после комиссии, разве не так? Cost reimbursement - это возмещение затрат на разработку? Если так, то всё вполне радужно. 8+8+20=36%, с весьма не малой платой за сопровождение и площадки, или иначе - прибыль 80% от стоимости проекта. Даже для российского бизнеса это весьма хорошо.
А так то есть схемы с 50%-70% издателю, где часть расходов или даже все расходы на себя возьмёт издатель. Есть возможности и самостоятельно провести рекламную без платы издателю или изначально делать под стим и попасть под его рекламу, вполне годную. Ну или оказаться в этом как бы издателе, к примеру, в Tencent(на минутку, чистая прибыль более 100 млрд$ в 22).
Для PC игр(не MMO) и без издателя вполне хорошо можно справиться, что многие и делают.
А вот в мобилках же вообще всё зависит от рекламы. Прибыль издателей так же на много больше, чем самих разработчиков. Можно сказать, что рынок захватили издатели. Даже больше - они захватывают игровые движки
Обработка большого объёма данных и принтеры материи вообще могут перевернуть всё. И для этого текущего технологического развития достаточно. Пока что мы очень слабо подвинули материальную подготовку, различными уловками узнавая что-то новое. Сейчас куча не фундаментальных знаний так и только в бумаге, т.к. их не получается использовать.
А проблему замедления науки вижу в том, что сейчас очень сложно проводить эксперименты - нужно много данных и штучные экспериментальные установки. Очень дорого и в учёных, и в материальных средствах. Земля, и то, что можно тут легко собрать не дают сильной подвижки.
Сколько тут понаписали... Однако, есть полно компаний, в которых джунов используют именно так. И это не только GC в геймдеве, круд, формошлёпство. Операционку так не сделать, но более 90% бизнеса и не нуждается в хорошем подходе. А так-то и отдельные сервисы так пилить можно, типа яндекс-такси, когда карты делает отдельная команда.
1.5 и пример в 1.2 противоречивы.
Получение имени с указанием типа - явно же, что раз это строка-месяц, то ожидается строка с названием месяца. Примерно то же со всеми перегрузками функций.
Ну и немного по указаниям типа в IDE . i в начале - позволяет проще искать среди нужного типа. Но, всё же, скорее стоит отказаться от использования маркеров в слове.
Не про идеальный код, но всё же.
Выделение класса - это оформление работы как класса, т.е. некоторая универсальность применения. Не редко это просто на много дороже для того, что не имеет иной реализации и не планируется использовать иначе. Поэтому делим только до функции, а дальше забываем пока аналогичный не потребуется ещё где-то.
Хорошо, если язык позволяет использовать эрзац-классы(кортежи в C#) без функционала. Это помогает и структурировать, и классы не штамповать на каждый чих.
По мне так ровно наоборот. Рассчитываете, что у вас коллектив выучит все основные переменные, а это вообще не должно происходить.
Ну и новички не будут разбираться в коде. А одно дело посмотреть поблизости чем занимается локальная переменная, а другое - искать во всём коде, чем же занимается занимается класс и не поломается ли это что-то при использовании.
Ну и в целом по длине, пусть и 20 символов, но их даже переименовать можно "парой" нажатий клавиш. А при наборе IDE так же все 20 набирать не надо, часто вообще столько же, сколько и у короткого имени.
Я вот как раз работаю над одним проектом, где всё просто в лоб делается. На базовую клиент-серверную дробилку данных навешан максимально простой код. И пока логика была линейна и функцонала мало - всё было очень просто. Но оказалось, что в таблицах легко вбивается чушь и код это ест, работает, но выдаёт чушь. Там где уже надо было делать код на классы работает 3 разных метода с копипастом на 80%+, каждый состоит из пары десятков условий, которые очень сильно разносятся между собой и находятся в разных областях знания о проекте. В каждом методе куча условий на входе, которые тихо прекращают выполнение if (bool) return;
Справедливости ради, читать там в большинстве случаев легко. Только в каждом методе может потребоваться знание о любой части проекта. А изменение может поменять логику непредсказуемым образом, но отработать без ошибок.
Так вот, изменять его можно легко только продолжая писать как раньше. Иначе надо переписывать огромными кусками. Т.е. если надо побыстрее сделать мелкую правку , то просто дописываем ставя ещё один условный оператор во все места и молимся рандому. На деле это очень бытсро и просто, если случайно никак не заденешь кор загрузки и сети.
Интереснее с расширением функционала. В таком случае мелкой правкой не обойтись. Меняешь в одном месте, другом. А потом оказывается, что в приложении есть ещё место, которое работает по старой логике, а так же пара мест очень старой логики, где уже забыли внести изменения до старой логики, но внесли другие изменения. Уже на много веселее, с кучей дополнительных согласований по логике с дизайном проекта. В принципе, это ещё не так сложно, если есть исчерпывающая документация, которая распишет каждое условие в линейной логике. Я такую не видел очень давно. Да и там условия не только от бизнеса, но и от внутренней структуры переплетены.
С добавлением функционала так же просто, пока он не задевает логику старого. А вот если затрагивает, то опять как с расширением, только сложнее. Проще переписать ту часть с 0, хотя бы по частям.
Пока хуже было только с колбеками.
Распознавание по лицу есть и у андродтелефонов уже много лет... И вообще это впервые появилось не на айфонах)
Я бы ещё добавил, что взгяд опирается не столько на код, сколько на дизайн задачи. Ищешь сначала по представлению того как должно быть(множество вариантов), потом уже по коду. И правки стараешься так же делать, не опираясь на текущую реализацию кода. Иногда бывает, что и несколько мест вместо одного приходится переписать для этого.
Куда ни плюнь - ответственность высокая.
По мне так, общепит - очень ответственная профа. Приготовишь плохо, стол не протрёшь, холерку занесёт и сядешь лет на много.
Ответственность - это не то, за что надо платить сильно больше. Ответственность в первую очередь должна быть на бизнесе(государстве). А её нет. Тогда и платить больше незачем.
Ну и если где-то требуется высокая ответственность, то в первую очередь это говорит о том, что ответственность в этой сфере надо снимать с человека, а не доплачивать.
Я не говорю, что невозможно написать эквивалентный код. Можно. Достижимой она останется, но при условия меняются.
И он бы выглядел примерно так:
if (!newOption){if (!(symbol_idleFX)) return;
Но для этого пришлось бы лезть внутрь функции и разбираться в её работе. Чем больше таких условий, тем больше шанс ошибки и меньше шанс корректной работы программиста, т.к. узнавать причины появления всех условий сложно и дорого. Поэтому программист просто напишет:if (!idleFX) return;}
if(nextReward == 0) return;
if (!newOption)return;Т.е. это становится причиной того, что пишут кривой код. И она исходит из того, что функция не делает того, что должна по названию. В данном случае функция должна была показать награду, но она вместо непосредственно показа занималась ещё и валидацией данных(которая вообще должна быть на входе, а не тут), ну и логикой в решении, вообще показывать или нет.
Так бы и писали) Но это единственный коммент)
Пожалуй, возвращение пустого ответа так же возможно, если только это будет обработано полноценно в дальнейшем, т.е. не является аналогом
return;, точнее того же тихого выхода. Именно так было написано в начале этой ветки, что это уменьшает цикломатическая сложность(на деле - нет). В случае, когда возвращается какое-либо значение, то разницы по сравнению с обычным описанием нет.Проблема не том, что это сложно понять - это всё легко понимается. Проблема в том, что часто постепенно логику из вызова переносят в функцию. И, условно, если в функции 5 ранних выходов(условий) затрагивающие 5 разных фич, то для корректной правки в этих условиях нужна инфа обо всех этих 5 фичах, т.к. правка может все их затронуть.
Вот пример:
if (!symbol_idleFX) return;nextReward == 0if (!idleFX) return;
if (
) return;
Расчёт вознаграждения. Одно условие тут проверяет состояние, одно нужно для обработки, а ещё одно никак нигде не фигурирует и возможно завязано на бизнес-логику. И вот каким боком тут проверкаsymbol_idleFXвообще не понятно. Если новая фича будет не связана с этим параметром и функция должна будет отработать даже когдаsymbol_idleFX == false, то просто вызвать функцию уже будет нельзя. Нужно будет смотреть внутрь неё и проверять из-за чего она не работает.Почему вы с таким не сталкиваетесь, не знаю. Возможно редко переиспользуете код или переиспользуете большими кусками? Меньше интенсивность работы? У меня проекты обычно поменьше, до 150к, но за год около 300к вполне может быть пере-/написано в этом проекте.
Такой некоммуникабельный, конечно, сильно ограничивает список задач для поручения. Но он учится. БольшАя часть хороших разработчиков - именно такие изначально. Но потом из таких могут получится и хорошие лиды.
Вот очень не люблю такой код. Если делать именно исключения - то всё ок. Если логику вносить - он путает. Поначалу ничего плохого, но вот потом...
Очень просто перенести логическую проверку с верхнего уровня на вызов функции, выставить ранний выход и радоваться выполненной задаче. А потом кто-то ещё будет работать с этой функцией, возможно из множества мест, а проверка будет приводить к преждевременному выходу. Из-за этого условие усложнится и туда добавят исключение(возможно даже протащив в функцию дополнительный опциональный параметр).
Ну и с логической стороны, если функцию вызываешь, то ожидаешь результат, а не тихое завершения без результата. В случае ошибки как раз всё ок - тихого завершения не будет. Да и при чтении такой код можно просто пропустить. А вот логику - нельзя.
Если вы не мало проектов глубоко перерабатывали, то возможно не раз и не два видели такое. У меня в практике встречалось чуть ли не в половине проектов. В двух проектах такой код разрастался до 20 проверок на функцию. Правда, те проекты весьма стары были, ещё с колбекным программированием.
И салатика с борщом достаточно для набора веса. И даже наоборот, иногда с булкой проще вес сбросить, отказавшись от картошки, гречки, риса.
В подсчёте калорий важнее сам процесс, а не точные значения.