Надгробья современного геймдева. Феномен самораздувающихся сроков

Вы точно хотите сказать, что визионер-лидер проекта, который настолько не уверен в том, что он делает, что приходится постоянно что-то корректировать, - это норма?

Да, это норма.

Полагаю, если визионер настолько сомневается - делать ему в увлекательном мире больших проектов нечего. Потому, что бюджет не резиновый. И ото всех пирогов в мире разом не откусишь.

Рост бюджетов из-за изменений требовайни и окружающего мира - это даж в энтерпрайзе сплошь и рядом, не то что в геймдеве.

Надгробья современного геймдева. Феномен самораздувающихся сроков

Вы пытаетесь мне сказать, что сделать заранее набело работу по проработке, которую всё равно придётся делать, - сложнее и дольше, чем болтаться по течению и латать что попало чем пришлось по ходу дела.

Часто ее просто не имеет смысла делать заранее, не выпустив какой-либо продукт с минимано-необходимыми фичами. Текущий мир айти очень быстро меняется.

"Нестояние на месте" жизни и рынка же, во-первых, от пропускания критически важных этапов проектирования никуда не денется, и, во-вторых, является совершенно рядовым риском для любого сколь-либо большого проекта в любой сфере, от строительства недвижимости до оптового плетения корзинок из папье-маше.

Поэтому и делают большие проекты уже не ватерфолом, а итеративными способами.

Но вот незадача, вне IT детальной проработкой стараются не пренебрегать, поскольку она в том числе ПОНИЖАЕТ эти риски, минимизируя лишнюю работу и заранее очерчивая интересные альтернативы.

Понижение рисков расхождения ожиданий и результата при детальной проработке тз может обернуться рисками потери рынка из-за сильно большего времени разработки, то есть разработку в консервативной большой сфере типа большого энтерпрайза, стоит и часто и ведут тщательно прорабатывая тз, так как исполнители могут быть совсем со стороны и не иметь представления о предметной области. А в геймдеве, как творческом направлении, изменчивость хотелок и требований - это просто неотъемлимая часть процесса. Аналогично в стартапах, надо быстро проверять идеи, захватывать рынки, и только потом уже детально доводить до ума взлетевшие идеи.

Надгробья современного геймдева. Феномен самораздувающихся сроков

Да, именно так. Особенно сильно это касатеся творческих разработок, как игры.

Надгробья современного геймдева. Феномен самораздувающихся сроков

Вопрос не в доступности информации, а в наличии практического опыта по реализации такого подхода. Просто оказывается, что процесс детальной проработки задачи сильно сложнее и дольше, чем техническая реализация самой задачи, а жизнь и рынок при этом не стоят на месте и уходят вперед.

Надгробья современного геймдева. Феномен самораздувающихся сроков

В детальной проработке проекта ради своевременной сдачи оказывается заинтересован никто.

Вы, вероятно, совершенно не представляете, сколько процесс детальной проработки занимает времени и какие ресурсы для него нужны. Даже в разработке обычного софта, не игр, это крайне сложно достижимо, и итеративные методы разработки не зря заняли свое место под солнцем.

Поднимаем читаемость кода в iOS разработке

В Xcode в появившемся окне при создании аутлета это выбирается.

Поднимаем читаемость кода в iOS разработке

Если вы понимаете управление памятью в айос и иерархию вьюх во вьюконтроллере, то все должно быть очевидно.

Поднимаем читаемость кода в iOS разработке

Половина — просто вкусовщина.

1,2 — писать марки и давать им имена без смысловой нагрузки, которые просто констатируют капитанские факты (публичные, приватные) — странно, читаемость это точно не улучшит, стоит применять марки для разделения разных наборов методов внутри класса, например, работа с таблицей, работа с поиском и т.п.
3 — создавать множество одноразовых одно-двух-строчников также может ухудшить понимание происходящего в коде, часто придется скакать между использованием и реализацией.
4 — также ухудшает понимаемость класса, логичнее сразу в объявлении класса видеть все его наследования и интерфейсы, но с экстеншенами все интерфейсы будут разбросаны где-то далеко ниже по коду класса, придется весь класс просмотреть, чтобы понять его суть.

Также в статье про читаемость стоит привести в порядок примеры кода, в них нет единого консистентного кодстайла, выглядит как надерганные куски из гугла.

P.S. Интересно, когда таки айосники перестанут писать weak для аутлетов.

А в ваших iOS приложениях IBOutlet уже private?

Типичная ситуация, захотел вдруг кодом изъять вьюшку, а потом вставить куда-либо снова.
Разработчик пишет self.myView.removeFromSuperview(), и в этот момент вьюшка деаллоцируется, так ссылка держалась только иерархией вью, а не самим контроллером из-за weak, и далее так как у нас еще и IUO, то при обращунии без ? будет креш.
Мало уже кто помнит, зачем давным давно писали weak в аутлетах ))).

А в ваших iOS приложениях IBOutlet уже private?

-

А в ваших iOS приложениях IBOutlet уже private?

Также и weak не нужен, и местами даже опасен.

Хакинтош: обновляемся с macOS Sierra 10.12 до High Sierra 10.13

Обладатели карт NVidia с web driver на 10.13.3 (версии драйвера 387.10.10.10.25.156/157) могут стролкнуться с жуткими постоянными лагами графики.
Решение: откатиться на драйвера для 10.13.2 (например на 378.10.10.10.25.106), пропатчив у них поддерживаемую версию ос (например с помощью webdriver.sh).

Swift Package Manager

В статье написано, что использование с iOS возможно, но описание использования SPM на гитхабе говорит иное:

Note that at this time the Package Manager has no support for iOS, watchOS, or tvOS platforms.

Так как использовать его в iOS проектах?
А в других местах Swift почти не применяется.

Три ошибки iOS-разработчика, которые могут дорого стоить

Правильный синглтон — отсутствующий синглтон.
Ибо такой синглтон, практически всегда, есть неявная зависимость.

Kotlin и Swift. Новая эпоха в мобильной разработке?

let mixedArray = ["4", "5", "a", "-2", "Str"]
let results = mixedArray
    .filter({ (obj) -> Bool in return Int(obj) != nil })
    .map { (obj) -> Int in return Int(obj)! }
    .reduce(0, +)

За такое использование Swift обычно надо проводить серьезные разъяснительные беседы с автором.

Инверсии зависимостей управления впрыском

Если данные идеологически разные, то зачем их в один интерфейс пытаться объединить?

А если данные одинаковы, но просто разные способы получения этих данных, допустим через разные каналы связи, то потребителю как раз не важно, как именно получаются данные, он знает, что предоставленный ему объект имеет интерфейс для получения этих данных.

Инверсии зависимостей управления впрыском

Каждый получатель, несмотря на то, что получает объект IPlayer, вынужден указывать, объект какого типа (чтиай: какого класса) он хочет получить

Значит ему не нужен интерфейс, а нужен конкретный класс.

Суть в том, что получателю все равно какую конкретную реализацию ему дадут, он сможет работать с любой.

Портфель iOS TEAM разработчика

> В проекте ибо в таргет прикладывается скрипт с путями и какие нужны фреймворки.
Да, я про этот скрипт и говорю, но пути там однотипные и относительные.
И этот скрипт нужен для подготовки фреймворков приложения для загрузки в айтюнс.
Между таргетами — копипастом :), но таргетов же обычно минимум.

По-моему, это минимальная плата за то, что ничего не ломается с каждой новой версией подов.

Портфель iOS TEAM разработчика

1.
Долгое, это если всё под все платформы собирать, но обычно нужна только одна, например, только iOS.
Также при удалении не нужно ничего пересобирать, а при обновлении/добавлении можно отдельно указать, какой обновить.

2.
Только в один скрипт для сабмита в стор надо дописывать фреймворки.

Пора ли переходить на Swift?

В Obj-C дженерики — это лишь сахарок для лишней проверки компилятором, рантайм как принимал объекты, так и принимает.
Так что нет нормальных дженериков в OC.