Статья любопытная, но похоже устаревшая. Список стран, принимающих Мир сильно сократился с тех пор. Золотая Корона в приложении и на сайте убрала Россию из списка стран-получателей.
Спасибо за обзор! Было бы еще интересно почитать про способы отправить деньги в Россию, для тех кто завёл трактор, но хочет финансово поддерживать оставшихся в РФ родственников. Пока что гуглежка показывает, что вывести деньги из РФ мб даже проще, чем наоборот.
> В составе с космическим кораблём и экипажем Shenzhou 14, а также с грузовым кораблём Tianzhou 4 станция примерно на 20% будет превышать по массе 480-тонную МКС.
Что-то не сходится, в той же википедии написано что масса Tiangong будет около 100 тонн. Может имеется ввиду что станция будет весить около 20% от массы МКС, а не превышать её на 20%?
Прогаю уже 5 лет, за всё время переработок было меньше раз, чем пальцев на двух руках. Из вашего поста скорее можно сделать вывод о важности уметь сохранять своё право не овертаймить.
Справедливые замечания, спасибо. Не сталкивался с "переговорами по улучшению оффера" после подписания. На моём опыте на оффер обычно не соглашаются пока все условия не будут обговорены, оффер же просто закрепляет договоренность. Но я не то чтобы на очень большом количестве собесов был)
Мне кажется автор описывает какой-то очень специфический кейс, не все собесы будут такие. Я не проходил очных интервью в США, но на удалённую вакансию попадал успешно, при том что некоторые шаги из статьи я выполнял с точностью до наоборот)
Это мне кажется странным. Есть такая психологическая штука, не помню как называется, но заключается в том что то, что воспринимается как дефицитное, нам кажется более желанным. Так что имхо дать понять что могут быть и другие офферы - это важно. Понятно что не надо сходу начинать шантажировать типа "берите меня или к другим уйду", но между делом упомянуть что вы выбираете между несколькими компаниями будет полезно.
А какая польза от того что начинать это говорить после оффера? Оффер уже получен, цель достигнута, теперь задача уже другая - показать текущему работодателю, насколько вы хороший сотрудник)
Не путаю, в текущих планах стартовая башня будет ловить как SuperHeavy, так и Starship. Сразу после чего стекать Starship обратно на стоящую рядом SuperHeavy. Звучит фантастически, но блин, они это уже строят :) Про различные модификации всё верно, будут модификации с посадочными ногами для межпланетных перелетов. Я неправильно выразился, хотел просто обратить внимание на то, что стандартная модификация ноги не включает, а другие модификации будут разрабатываться позднее.
Насчет посадки хорошее замечание, особенно учитывая что у стандартной модификации старшипа возможность посадки на землю вообще не предусматривается (кроме аварийных ситуаций). Его будут ловить в полёте стартовой башней (aka Mechazilla) недалеко от земли.
На какие графики смотреть если у видях 10, 15 и 24 просмотра? :D Статья конечно любопытное, но вряд ли поможет "получить миллионы подписчиков" тем, кто начинает с нуля. Имхо путь от 0 до хотя бы нескольких сотен подписчиков самый сложный, мб даже сложнее чем 1000->1000000
Последний раз когда я проверял инфу, юнити занимал львиную долю рынка мобильных игр, а там ведь крутятся самые деньги. Думаю пока это остаётся так, юнити ничего особо не угрожает.
Почему вы позволили себе использовать переменную var в строготипизированном языке?
Ничего страшного, строгая типизация никуда не денется, нужный тип выставится компилятором на этапе сборки. Вы даже можете получить все те же complie time errors как если бы тип переменной был объявлен явно (Источник https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/var) С другой стороны, использование var избавит нас от необходимости изменять объявление переменной behaviorName если тип BindingBehavior[i].Name изменится на другой. Бонусом мы также получаем более аккуратный код при объявлении нескольких переменных подряд, пример: // Зачем два раза писать имя класса? Визуальный мусор
// Индентация до имени везде разная - создает friction при чтении кода
Foo foo = new Foo();
List<Foo> fooList = new List<Foo>();
bool isFooSpawned = foo.IsSpawned;
Против:
var foo = new Foo();
var fooList = new List<Foo>();
var isFooSpawned = foo.IsSpawned;
Второй вариант читается на мой взгляд гораздо легче. Я допускаю что в некоторых компаниях предпочитают так не делать, но мне такие компании не встречались.
Почему вы бесполезно ввели лишнею переменную behaviorName
Она не лишняя, её предназначение - удобочитаемость. Она очищает от визуального мусора следующие несколько строчек. При этом так как это локальная переменная, ссылающаяся на существующий объект, она практически не добавляет нам нагрузки.
if (IsDoneBinding(BindingBehavior[i].Name) == false) - нет именно так и надо, почему вы предпочитаете "усложняющую чтение визуальную нагрузку" аналог ?
Это наверное самое субъективное из всего списка. Вариант с явным сравнением с false сильнее визуально нагружает, на мой взгляд. Я допускаю что вы можете думать иначе и это ваше право, но я не понимаю как if (condition1 == true && condition2 == false || condition3 == true)
может быть более читабельно чем
if (condition1 && !condition2 || condition3)
Почему вы позволяете себе return в методе ничего не возвращающем, почему не используете goto?
The return statement terminates execution of the function in which it appears and returns control and the function's result, if any, to the caller.
As the preceding example shows, you typically use the return statement without expression to terminate a function member early.
Вот и ответ на ваш вопрос "почему вы себе позволяете": потому что это литерали то, ради чего это слово было добавлено в язык.
Вы также справедливо заметили, что я мало что написал по поводу самой статьи. Я скажу как читатель хабра что мне не нравится, когда в prerequisites для понимания статьи входит просмотр видео на ютубе. Моё ИМХО что статья должна быть самодостаточной, но без просмотра видео что эта, что прошлая статья больше запутывают чем объясняют. Но в этом конкретном случае я посмотрел видео, о которых идёт речь, и моё мнение что вариант в принципе рабочий в некоторых ситуациях. Хочется только спросить в чём преимущество такого подхода по сравнению с другими методами для решения такой проблемы? Мне кажется используя тот же Zenject решить проблему можно было бы гораздо меньшими усилиями.
Теперь давайте к весёлой части)
Вы сами понимаете, что этого мало? Что как минимум в раза 4 это меньше моего?
Да, я понимаю что 5 лет это меньше чем 20. А ещё я понимаю что это имеет абсолютно нулевое отношение к поставленным вопросам. Аргумент "я прав потому что у меня 20 лет опыта" это обычный аргумент от авторитета, являющийся подвидом ad hominem на который вы жаловались в соседнем комменте.
Во всех компаниях где я работал всегда поощрялось когда начинающие ставят под вопрос действия синьоров. В 9 из 10 случаев синьор окажется прав, объяснит новичку почему он прав, новичок за счет этого поднимет свой технический навык, что хорошо для компании. В 1 из 10 случае синьор окажется неправ (нет людей которые не ошибаются) и код попадет в проект только после исправлений, что также хорошо для компании. Win-win. А за аргументацию вида "делаем так потому что у меня N лет стажа" синьора ждал бы как минимум разговор с HR.
Что это за манера такая, не зная оппонента думать, что он знает меньше вас?
Я нигде ничего про ваш уровень знаний не писал. Я вообще ничего про вас не писал, только про ваш код и статью, это вы в качестве реакции на критику пытаетесь меня зашеймить на ровном месте.
И нет, вы позволили себе - учить меня тому, чего я не просил!
Если вы публикуете статью в общий доступ, значит вы готовы получать как положительные, так и негативные комментарии.
которые по стилю кода позволяют себе что-то то сумничать
Мне кажется тут у нас есть идеологическое разногласие. Поправьте меня если я ошибаюсь, но мне кажется что стиль кода и readability для вас является чем-то второстепенным.
Я для пояснения своей позиции вернусь к базовому вопросу: в чём заключается суть работы программиста, применительно к геймдеву? По моему убеждению, все сводится к тому что мы должны написать продукт, который приносит стейкхолдеру максимум $$$, при минимальных затратах $$$ самого стейкхолдера. Для программиста достижение этой цели держится на трех столпах:
1) Умение эффективно коммуницировать как с техническими, так и с нетехническими коллегами.
2) Умение создать удобную, адекватную, расширяемую архитектуру.
3) Умение писать код чисто и понятным/принятым в компании стилем.
Убери один столп - и стейкхолдер начнет терять $$$.
У вас чистый код, но плохая архитектура? При добавлении новой фичи придется муторно/долго её подключать, и стейкхолдер потеряет $$$.
У вас хорошая архитектура, но код стайл плохой/не соблюдается? При ротации новичка на проект он будет первые несколько месяцев с головной болью плутать в куче вложенных ifов и ветвящихся методов, и стейкхолдер потеряет $$$.
Поэтому я не считаю что нужно слепо следовать всяким абстрактным принципам просто ради того чтобы им следовать. Код должен быть хорошо спроектирован и при этом быть удобным для людей. Если я потеряю три наносекунды на аллокации лишней переменной, но при этом смогу сделать код более удобным для работы в будущем - я это сделаю, потому что так стейкхолдер быстрее получит больше $$$ и будет мной доволен, и мои коллеги-программисты тоже будут благодарны за то, что упростил им задачу когда придет их черед работать с кодом.
Со всех сторон хороший фидбек, и программист получает заслуженный рейз $ :)
Я считаю что хороший синьор это в первую очередь тот, кто может доступно и по делу донести свою позицию до спецов любого уровня. Общаться на ровне со старшими, обучить и направить на верный путь младших. Вы же пока больше пишете про "глупости", "палками гнать из профессии", "настоящих программистов", "молодеж", "умничать" и тд. На мой взгляд вы ведете себя очень не профессионально для человека с вашим стажем.
Мои источники - 5 лет коммерческого опыта, из которых полтора года в Британском юникорне, в котором меня на ревью за такое качество кода как минимум попросили бы объясниться и отправили переписывать)
Вы говорите про неуважение, но я в комментарии ни слова не сказал про вас. Неумение отличать критику кода от критики написавшего его человека это распространённая проблема, которая может привести к трудностям в командной работе. Решается транспарентностью в коллективе и прокачкой emotional intelligence.
Всё что написано выше (как и предыдущий мой оригинальный коммент) написано не столько для вас, сколько для юнити-новичков, которые могут зайти в эту статью и долистать до комментов, посему я достаточно подробно расписал довольно очевидные для более опытного разработчика вещи.
Мне, конечно, было бы интересно поспорить по существу (я считаю что здоровая техническая дискуссия может повысить технический навык обоих участников), но я не знаю что отвечать на "глупости", "несуразицу" и "советы от умников". В любом случае я уважаю ваше право на своё мнение.
Оно всё конечно здорово, но в вашем примере качество кода сперва стоит улучшить, исправив readability косяки.
Но сперва по существу вопроса: MVC практически не заменимая штука, когда над игрой работает дев в паре с тех. артистом. В таком случае как раз прогер делает большую часть логики в MC, пока тех. артист пилит всякие красивости для V. Если бы они работали в одном общем классе то это была бы во-первых боль при работе с системой контроля версий, а во-вторых код связанный с визуалом имеет свойство быть очень объемным и игровая логика может в нём просто потонуть, ухудшая читабельность.
А теперь по читабельности примера. Вы уж простите но меня триггерит, когда в статье про паттерны и архитектуру сам код-пример нуждается в рефакторинге х)
1) Проверка на false
if (IsDoneBinding(BindingBehavior[i].Name) == false) Не надо так ? Давайте использовать цивилизованный
if (!IsDoneBinding(BindingBehavior[i].Name))
2) Кеширование локальной переменной Нет нужды несколько раз вызывать BindingBehavior[i].Name в пределах одной итерации цикла. Во-первых это создает усложняющую чтение визуальную нагрузку, а во-вторых чуть-чуть добавляет работы процессору (хоть извлечение по индексу это и очень быстрая операция). Лучше один раз закешировать это в локальную переменную и пользоваться ей.
var behaviorName = BindingBehavior[i].Name;
3) Разбиение методов на логические части пустыми строками
Тайтл. Когда код одной сплошной стеной, это сложно читать. Использование пустых строк позволяет проще направлять внимание на отдельные блоки кода. Пример ниже.
4) Диагональный ветвистый код
Если у нас в коде появляется if, вложенный в if, вложенный в цикл, вложенный в if, то что-то явно пошло не так. Человеческому мозгу проще воспринимать линейный код чем пытаться отследить все ветви кучи ifов. Как rule of a thumb, я стараюсь держать индентацию в пределах 2х, максимум 3х табов. В этом хорошо помогает на мой взгляд один из самых недооцененных readability паттернов early return, суть которого заключается в том что мы вместо расписывания всех возможных ветвей кода просто выходим из метода раньше времени (или уходим на следующую итерацию цикла).
Для наглядности всего перечисленного вот исправленный метод Bind():
PS А еще у меня подозрение что этот метод вообще ничего особо делать не должен, если у нас Related == null (но я не знаю что у вас происходит в IsDoneBinding и AddDoneBinding, которые вы почему-то в пример не включили. Но если в них переменной Related значения отличные от null не присваиваются, тогда код можно упростить еще сильнее: https://pastebin.com/79qpcvPX )
Получается что не каждый айтишник - инженер, и не каждый инженер - айтишник ? Условный бизнес-аналитик - айтишник, но не инженер. Программист - и айтишник, и инженер. Какой-нибудь специалист по монтажу заводских станков - не айтишник, но инженер. Мне нравится такое разделение)
Интересно было бы сравнить количество выбросов от запусков ракет с, например, авиационной индустрией. Понятно что ракета за один запуск сделает больше выбросов, чем условный самолёт, но ведь ракетных запусков за год человечество совершает от силы несколько десятков, тогда как самолёты совершают тысячи рейсов в день. У меня подозрения что выбросы от ракет это капля в море.
Не раскрыто главное по теме кочевничества - нужна ли виза чтобы легально получать доход? Можно/нужно ли открывать ИП? Нужно ли платить местные налоги и кому?
Вам конечно плюс за старания, но заголовок со статьёй не вяжется - больше похоже на гайд для туриста, а не для номада.
Было бы здорово если бы подробнее раскрыли тему user acquisition. Какой бюджет из 1млн пошёл на рекламу вашей игры? Какие способы рекламы использовали? Какие маркетинговые стратегии оказались провальными?
Статья любопытная, но похоже устаревшая. Список стран, принимающих Мир сильно сократился с тех пор. Золотая Корона в приложении и на сайте убрала Россию из списка стран-получателей.
Спасибо за обзор!
Было бы еще интересно почитать про способы отправить деньги в Россию, для тех кто завёл трактор, но хочет финансово поддерживать оставшихся в РФ родственников. Пока что гуглежка показывает, что вывести деньги из РФ мб даже проще, чем наоборот.
> В составе с космическим кораблём и экипажем Shenzhou 14, а также с грузовым кораблём Tianzhou 4 станция примерно на 20% будет превышать по массе 480-тонную МКС.
Что-то не сходится, в той же википедии написано что масса Tiangong будет около 100 тонн. Может имеется ввиду что станция будет весить около 20% от массы МКС, а не превышать её на 20%?
Прогаю уже 5 лет, за всё время переработок было меньше раз, чем пальцев на двух руках. Из вашего поста скорее можно сделать вывод о важности уметь сохранять своё право не овертаймить.
Справедливые замечания, спасибо.
Не сталкивался с "переговорами по улучшению оффера" после подписания. На моём опыте на оффер обычно не соглашаются пока все условия не будут обговорены, оффер же просто закрепляет договоренность. Но я не то чтобы на очень большом количестве собесов был)
Мне кажется автор описывает какой-то очень специфический кейс, не все собесы будут такие. Я не проходил очных интервью в США, но на удалённую вакансию попадал успешно, при том что некоторые шаги из статьи я выполнял с точностью до наоборот)
Это мне кажется странным. Есть такая психологическая штука, не помню как называется, но заключается в том что то, что воспринимается как дефицитное, нам кажется более желанным. Так что имхо дать понять что могут быть и другие офферы - это важно.
Понятно что не надо сходу начинать шантажировать типа "берите меня или к другим уйду", но между делом упомянуть что вы выбираете между несколькими компаниями будет полезно.
А какая польза от того что начинать это говорить после оффера? Оффер уже получен, цель достигнута, теперь задача уже другая - показать текущему работодателю, насколько вы хороший сотрудник)
Есть форк со SponsorBlock https://github.com/polymorphicshade/NewPipe
Не путаю, в текущих планах стартовая башня будет ловить как SuperHeavy, так и Starship. Сразу после чего стекать Starship обратно на стоящую рядом SuperHeavy. Звучит фантастически, но блин, они это уже строят :)
Про различные модификации всё верно, будут модификации с посадочными ногами для межпланетных перелетов. Я неправильно выразился, хотел просто обратить внимание на то, что стандартная модификация ноги не включает, а другие модификации будут разрабатываться позднее.
Насчет посадки хорошее замечание, особенно учитывая что у стандартной модификации старшипа возможность посадки на землю вообще не предусматривается (кроме аварийных ситуаций). Его будут ловить в полёте стартовой башней (aka Mechazilla) недалеко от земли.
На какие графики смотреть если у видях 10, 15 и 24 просмотра? :D
Статья конечно любопытное, но вряд ли поможет "получить миллионы подписчиков" тем, кто начинает с нуля. Имхо путь от 0 до хотя бы нескольких сотен подписчиков самый сложный, мб даже сложнее чем 1000->1000000
Последний раз когда я проверял инфу, юнити занимал львиную долю рынка мобильных игр, а там ведь крутятся самые деньги. Думаю пока это остаётся так, юнити ничего особо не угрожает.
Давайте начнем с того что написано по-существу:
Ничего страшного, строгая типизация никуда не денется, нужный тип выставится компилятором на этапе сборки. Вы даже можете получить все те же complie time errors как если бы тип переменной был объявлен явно (Источник https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/var)
С другой стороны, использование var избавит нас от необходимости изменять объявление переменной behaviorName если тип BindingBehavior[i].Name изменится на другой. Бонусом мы также получаем более аккуратный код при объявлении нескольких переменных подряд, пример:
// Зачем два раза писать имя класса? Визуальный мусор// Индентация до имени везде разная - создает friction при чтении кодаFoo foo = new Foo();List<Foo> fooList = new List<Foo>();bool isFooSpawned = foo.IsSpawned;Против:
var foo = new Foo();var fooList = new List<Foo>();var isFooSpawned = foo.IsSpawned;Второй вариант читается на мой взгляд гораздо легче. Я допускаю что в некоторых компаниях предпочитают так не делать, но мне такие компании не встречались.
Она не лишняя, её предназначение - удобочитаемость. Она очищает от визуального мусора следующие несколько строчек. При этом так как это локальная переменная, ссылающаяся на существующий объект, она практически не добавляет нам нагрузки.
Это наверное самое субъективное из всего списка. Вариант с явным сравнением с false сильнее визуально нагружает, на мой взгляд. Я допускаю что вы можете думать иначе и это ваше право, но я не понимаю как
if (condition1 == true && condition2 == false || condition3 == true)может быть более читабельно чем
if (condition1 && !condition2 || condition3)Я не использую goto потому что он избыточен для данной ситуации (да и вообще юзать goto это так себе практика), более того, зачем юзать goto если в C# есть ключевое слово специально для нашей ситуации? Смотрим: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/statements/jump-statements#the-return-statement
Вот и ответ на ваш вопрос "почему вы себе позволяете": потому что это литерали то, ради чего это слово было добавлено в язык.
Вы также справедливо заметили, что я мало что написал по поводу самой статьи. Я скажу как читатель хабра что мне не нравится, когда в prerequisites для понимания статьи входит просмотр видео на ютубе. Моё ИМХО что статья должна быть самодостаточной, но без просмотра видео что эта, что прошлая статья больше запутывают чем объясняют. Но в этом конкретном случае я посмотрел видео, о которых идёт речь, и моё мнение что вариант в принципе рабочий в некоторых ситуациях. Хочется только спросить в чём преимущество такого подхода по сравнению с другими методами для решения такой проблемы? Мне кажется используя тот же Zenject решить проблему можно было бы гораздо меньшими усилиями.
Теперь давайте к весёлой части)
Да, я понимаю что 5 лет это меньше чем 20. А ещё я понимаю что это имеет абсолютно нулевое отношение к поставленным вопросам. Аргумент "я прав потому что у меня 20 лет опыта" это обычный аргумент от авторитета, являющийся подвидом ad hominem на который вы жаловались в соседнем комменте.
Во всех компаниях где я работал всегда поощрялось когда начинающие ставят под вопрос действия синьоров. В 9 из 10 случаев синьор окажется прав, объяснит новичку почему он прав, новичок за счет этого поднимет свой технический навык, что хорошо для компании. В 1 из 10 случае синьор окажется неправ (нет людей которые не ошибаются) и код попадет в проект только после исправлений, что также хорошо для компании. Win-win. А за аргументацию вида "делаем так потому что у меня N лет стажа" синьора ждал бы как минимум разговор с HR.
Я нигде ничего про ваш уровень знаний не писал. Я вообще ничего про вас не писал, только про ваш код и статью, это вы в качестве реакции на критику пытаетесь меня зашеймить на ровном месте.
Если вы публикуете статью в общий доступ, значит вы готовы получать как положительные, так и негативные комментарии.
Мне кажется тут у нас есть идеологическое разногласие. Поправьте меня если я ошибаюсь, но мне кажется что стиль кода и readability для вас является чем-то второстепенным.
Я для пояснения своей позиции вернусь к базовому вопросу: в чём заключается суть работы программиста, применительно к геймдеву? По моему убеждению, все сводится к тому что мы должны написать продукт, который приносит стейкхолдеру максимум $$$, при минимальных затратах $$$ самого стейкхолдера. Для программиста достижение этой цели держится на трех столпах:
1) Умение эффективно коммуницировать как с техническими, так и с нетехническими коллегами.
2) Умение создать удобную, адекватную, расширяемую архитектуру.
3) Умение писать код чисто и понятным/принятым в компании стилем.
Убери один столп - и стейкхолдер начнет терять $$$.
У вас чистый код, но плохая архитектура? При добавлении новой фичи придется муторно/долго её подключать, и стейкхолдер потеряет $$$.
У вас хорошая архитектура, но код стайл плохой/не соблюдается? При ротации новичка на проект он будет первые несколько месяцев с головной болью плутать в куче вложенных ifов и ветвящихся методов, и стейкхолдер потеряет $$$.
Поэтому я не считаю что нужно слепо следовать всяким абстрактным принципам просто ради того чтобы им следовать. Код должен быть хорошо спроектирован и при этом быть удобным для людей. Если я потеряю три наносекунды на аллокации лишней переменной, но при этом смогу сделать код более удобным для работы в будущем - я это сделаю, потому что так стейкхолдер быстрее получит больше $$$ и будет мной доволен, и мои коллеги-программисты тоже будут благодарны за то, что упростил им задачу когда придет их черед работать с кодом.
Со всех сторон хороший фидбек, и программист получает заслуженный рейз $ :)
Я считаю что хороший синьор это в первую очередь тот, кто может доступно и по делу донести свою позицию до спецов любого уровня. Общаться на ровне со старшими, обучить и направить на верный путь младших. Вы же пока больше пишете про "глупости", "палками гнать из профессии", "настоящих программистов", "молодеж", "умничать" и тд. На мой взгляд вы ведете себя очень не профессионально для человека с вашим стажем.
Мои источники - 5 лет коммерческого опыта, из которых полтора года в Британском юникорне, в котором меня на ревью за такое качество кода как минимум попросили бы объясниться и отправили переписывать)
Вы говорите про неуважение, но я в комментарии ни слова не сказал про вас. Неумение отличать критику кода от критики написавшего его человека это распространённая проблема, которая может привести к трудностям в командной работе. Решается транспарентностью в коллективе и прокачкой emotional intelligence.
Всё что написано выше (как и предыдущий мой оригинальный коммент) написано не столько для вас, сколько для юнити-новичков, которые могут зайти в эту статью и долистать до комментов, посему я достаточно подробно расписал довольно очевидные для более опытного разработчика вещи.
Мне, конечно, было бы интересно поспорить по существу (я считаю что здоровая техническая дискуссия может повысить технический навык обоих участников), но я не знаю что отвечать на "глупости", "несуразицу" и "советы от умников".
В любом случае я уважаю ваше право на своё мнение.
Оно всё конечно здорово, но в вашем примере качество кода сперва стоит улучшить, исправив readability косяки.
Но сперва по существу вопроса: MVC практически не заменимая штука, когда над игрой работает дев в паре с тех. артистом. В таком случае как раз прогер делает большую часть логики в MC, пока тех. артист пилит всякие красивости для V. Если бы они работали в одном общем классе то это была бы во-первых боль при работе с системой контроля версий, а во-вторых код связанный с визуалом имеет свойство быть очень объемным и игровая логика может в нём просто потонуть, ухудшая читабельность.
А теперь по читабельности примера. Вы уж простите но меня триггерит, когда в статье про паттерны и архитектуру сам код-пример нуждается в рефакторинге х)
1) Проверка на false
if (IsDoneBinding(BindingBehavior[i].Name) == false)Не надо так ? Давайте использовать цивилизованный
if (!IsDoneBinding(BindingBehavior[i].Name))2) Кеширование локальной переменной
Нет нужды несколько раз вызывать BindingBehavior[i].Name в пределах одной итерации цикла. Во-первых это создает усложняющую чтение визуальную нагрузку, а во-вторых чуть-чуть добавляет работы процессору (хоть извлечение по индексу это и очень быстрая операция). Лучше один раз закешировать это в локальную переменную и пользоваться ей.
var behaviorName = BindingBehavior[i].Name;3) Разбиение методов на логические части пустыми строками
Тайтл. Когда код одной сплошной стеной, это сложно читать. Использование пустых строк позволяет проще направлять внимание на отдельные блоки кода. Пример ниже.
4) Диагональный ветвистый код
Если у нас в коде появляется if, вложенный в if, вложенный в цикл, вложенный в if, то что-то явно пошло не так. Человеческому мозгу проще воспринимать линейный код чем пытаться отследить все ветви кучи ifов. Как rule of a thumb, я стараюсь держать индентацию в пределах 2х, максимум 3х табов. В этом хорошо помогает на мой взгляд один из самых недооцененных readability паттернов early return, суть которого заключается в том что мы вместо расписывания всех возможных ветвей кода просто выходим из метода раньше времени (или уходим на следующую итерацию цикла).
Для наглядности всего перечисленного вот исправленный метод Bind():
https://pastebin.com/mSSMm2eL
PS А еще у меня подозрение что этот метод вообще ничего особо делать не должен, если у нас
Related == null(но я не знаю что у вас происходит вIsDoneBindingиAddDoneBinding, которые вы почему-то в пример не включили. Но если в них переменной Related значения отличные от null не присваиваются, тогда код можно упростить еще сильнее: https://pastebin.com/79qpcvPX )Получается что не каждый айтишник - инженер, и не каждый инженер - айтишник ?
Условный бизнес-аналитик - айтишник, но не инженер.
Программист - и айтишник, и инженер.
Какой-нибудь специалист по монтажу заводских станков - не айтишник, но инженер.
Мне нравится такое разделение)
Интересно было бы сравнить количество выбросов от запусков ракет с, например, авиационной индустрией. Понятно что ракета за один запуск сделает больше выбросов, чем условный самолёт, но ведь ракетных запусков за год человечество совершает от силы несколько десятков, тогда как самолёты совершают тысячи рейсов в день. У меня подозрения что выбросы от ракет это капля в море.
Не раскрыто главное по теме кочевничества - нужна ли виза чтобы легально получать доход? Можно/нужно ли открывать ИП? Нужно ли платить местные налоги и кому?
Вам конечно плюс за старания, но заголовок со статьёй не вяжется - больше похоже на гайд для туриста, а не для номада.
Было бы здорово если бы подробнее раскрыли тему user acquisition. Какой бюджет из 1млн пошёл на рекламу вашей игры? Какие способы рекламы использовали? Какие маркетинговые стратегии оказались провальными?
Тогда извиняюсь. Прост уже месяц хожу по Стамбулу и все оплачиваю картой из РБ, думал с сервисами тоже прокатит.