Comments 31
А я поддержу предыдущего оратора. Дело не в ошибках, а (судя по статье) в
А) Ужасно продуманной архитектуре
Б) Слабых разработчиках, которые сперва пишут, а потом думают о последствиях/алгоритмической или нагрузочной сложности, если вообще думают.
С) Упорном нежелании делать вещи правильно и изучать общепринятые решения/консультироваться.
Мне по молодости-глупости как-то доводилось работать в небольшой конторе с не-топовыми з/п. Вот там я наблюдал похожие перлы от разрабов. Вот серьезно, на контрасте очень заметен уровень разработчиков в таких вопросах.
Ошибки допускают все, но уровень допускаемых ошибок и устойчивость проектируемой системы к ошибкам у всех разные.
Тут вопрос в том, делать хорошо, либо очень быстро и иногда с косяками. Как показывает практика, часто одна неделя простоя может быть критической при развитии проекта
У вас, конечно, каждый проект с
А) Отлично продуманной архитектурой, которая вовремя обновляется и в ней учтены все возможные косяки
Б) Каждая задача проходит 40 етапов согласования, бизнес-аналитики сидят и по 2-3 месяца проверяют требования и разработчики, которые пишут задачу несколько недель, зато сразу оптимизированную.
С) А еще это все идеально фитится в опыт команды и ни у кого нет слепых пятен и все дофига опытные.
Шутки-шутками, но Б) — это причина, почему компании-гиганты по-прежнему (несмотря на тонны ненависти по этому поводу) дают на собеседовании олимпиадные задачки, вайтбординг, такие ненавистные задачи на биг-О. Тогда боттлнеки будут как минимум замечены перед написанием кода, их выявление уже вросло в подкорку.
Удивительно, но пункт Б) был написан с тонной сарказма как пример неправильного подхода к разработке.
В общем случае биг-О вообще не дает никакого понимания о том, насколько лучше один или другой алгоритм, потому что вы выпускаете из поля зрения настолько много вопросов, включая константы, ограничение на само число N, поведения рантайма языка, скрытые оптимизации операционной системы и так далее. Я уже не говорю о том, что задачи, в которых вам дадут это биг-О считать существуют в исчезающе малом количестве, которое в основном относятся к какой-то bigdata. Ведь именно так умерло доказательное программирование, разве нет?
Если бы все было так просто, никто бы не занимался мониторингом, нагрузочным тестированием и прочим. Даже в самом банальном вопросе "квадратичный или линейный алгоритм" иногда можно выбрать квадратичный, потому что максимальное n аж целых 2 или 3, а наглядность кода от этого вырастает.
Замените биг-О на computational thinking, если уж так придираетесь к формулировкам.
Маленьким конторам это все не так важно, как отличное владение фреймворками, библиотеками и языковыми средствами — причины отлично сам ОП расписал парой постов выше. Отсюда и возникают описанные баги.
Да, известный парадокс, что нет смысла оставаться в стартапе после его роста тоже в эту тему. Сперва берут и ценят людей, могущих быстро наговнокодить что-то рабочее. Потом приоритет отдается в пользу надежного кода и дальновидных/глубокознающих сотрудников.
Опять же таки, касательно "computational thinking" в общем случае крайне сложно сказать о том, какая на самом деле часть системы окажется самой нагруженной. Поэтому в каждой умной книге люди предупреждают насчет "преждевременной оптимизации", когда программист вылизывал перформанс веб приложения 3 месяца, а по факту им пользуется 1.5 анонимуса и прототип, написанный джуном на коленке так же отлично работает с такой нагрузкой.
Более того, даже если все пошло идеально и нагрузка большая, потом 100% окажется, что вы забыли про 2-3 важные вещи, которые куда сильнее садят производительность, чем не оптимизированный код, например, кеширование не добавили в нужные места.
Если мы говорим про большие компании, то в большом количестве случаев вы будете разрабатывать какой-то внутренний сервис, в котором перформанс вполне может быть не особо важен из-за того, что сервис ближе к пользователю выступает естественным барьером.
Сперва берут и ценят людей, могущих быстро наговнокодить что-то рабочее. Потом приоритет отдается в пользу надежного кода и дальновидных/глубокознающих сотрудников.
Если что — основной показатель программы это то, то она работает. Всем плевать, насколько она круто написана, если она не работает. И вам никто не мешает говнокодить дальновидно и заранее отмечать места, которые нужно будет отрефакторить или переписать.
Ну и напоследок, хочешь не хочешь, а вместо прикидывания на глаз алгоритмической сложности все равно надо будет бенчить код, потому что правильно прикинуть сложность кода дай бог топ-топ программисты в кремниевой долине смогут. А бенчить можно и без знаний О-нотации и сложности алгоритмов.
Опять же таки, касательно «computational thinking» в общем случае крайне сложно сказать о том, какая на самом деле часть системы окажется самой нагруженной
Вы утрируете. Безусловно предугадать все нельзя. Но то что ретрай поломавшегося запроса делается без кулдауна — показывает что люди банально не знакомы с устоявшимися хорошими практиками (читай — малоопытные).
Поэтому в каждой умной книге люди предупреждают насчет «преждевременной оптимизации»
В этом и проявляется senior develoer, что он хорошо разделяет преждевременные оптимизации, и архитектурные решения без которых в продакшн лучше не соваться.
Если что — основной показатель программы это то, то она работает
Именно, а если наговнокодить, не думая о последствиях в какой-то момент она внезапно перестанет работать. Во многих случаях это даже хуже, чем если бы она сразу не работала.
Ну и напоследок, хочешь не хочешь, а вместо прикидывания на глаз алгоритмической сложности все равно надо будет бенчить код
Насмотрелся я на этих горячих ребят «я не знаю O-notation» но зато я могу побенчить. А потом в продакшене оказывается решение которое на искуственных бенчах Лев Толстой, а на деле вставало колом. Бенчмарки не отменяют здравый смысл и понимание интсрументов которыми пользуешься
Ошибки допускают все, но уровень допускаемых ошибок и устойчивость проектируемой системы к ошибкам у всех разные.
Вы правы, их допускают все, и ошибки разные, но вот банальные допускаются как мне кажется чаще в более больших и дорого стающих проектах из-за того что в основное внимание, уделяется более сложным и узким местам. Можно вспомнить недавние брики айфонов из-за простого символа, благо War Robots компенсирует это в той или иной степени. На ум приходит история про «Ахиллесову пяту».
Прошу не обижаться разработчиков, но мне кажется, любой мид при написании кода сразу задумывается о возможных проблемах такого рода и они решаются еще на этапе обдумывания архитектуры, а не всплывают на продакшене. Уж точно не грабли сеньора это.
Ну и самое забавное, по крайней мере на мобильных платформах, заметил закономерность: чем более развитая система монетизации в игре, тем сильнее она греет телефон и быстрее садит батарейку.
HP на клиенте? в мультиплеерной игре? Аж в 2015 году?
Хороший пример того, что пока одни люди думают о секьюрности, масштабируемости, паттернах, другие не думают, а говнокодят по-черному, и отжимают их рынок.
Пока играет 3 калеки, то никто ломать не будет, а захватив рынок, и переписать «как надо» не пробема.
Самое время вводить хештег #косякинапроде
У каждого программиста найдется несколько историй под такой тэг. :)
Но каждый такой косяк — это бесценный опыт, как ни крути.
Вспоминается история какого-то разработчика, из-за которого контора попала на круглую сумму. Когда он заикнулся насчет ожидаемого увольнения за просчет, директор ему сказал что-то в духе «компания только что по сути вложила в твое образование и опыт миллион долларов, и ты думаешь мы тебя после этого возьмем и уволим?»
Только игра в Mechwarrior — это постоянное страдание из-за нехватки компьютерных ресурсов, нестабильности игры, неудобства управления с клавиатуры и сложности геймплея, которые способен переносить только гик, а в казуальную War Robots на планшетике играть намного удобнее и проще.
если бы вы, хотя бы раз, реализовывали механику роботов и реалтайм мультиплеера в рамках мобильной платформы у вас бы не возникало таких мыслей )))
p.s. игра интересная как не крути что с точки задачи разработки что с точки геймплея, Pixonic'ам респект )
Очень фееричная история. Вообще из всех постов о разработке игр складывается впечатление что это одна из самых, как бы это назвать… богатых на веселые факапы индустрий. И чем глубже игра, тем больше их.
Был один раз косяк, когда на проде удалили половину медиа файлов. А все потому, что:
- Начали разрабатывать новую версию сайта
- Сделали для медиа отдельную папку /beta/media/
- Начали туда заливать много картинок в папку /beta/media/templates/
- Бета вышла из своей беты и решили на /beta/ тестить новые сборки, а на /prod/ прод
- Т.к. в обеих версиях нужна медиа (особенно, чтобы папка /templates/ была и там и там одинаковой), а в папке /beta/ она уже есть, решили, что /prod/media/templates — ссылка на /beta/media/templates
- Прошло полгода, решили отказаться от версии /beta/ но файлы пока не удалять «атовдругчо»
- Прошел еще год и теперь-то пора удалять ненужные файлы.
- Удалили папку /beta/
Мы чуть случайно не стали вашими конкурентами, но начальство прототип про войну роботов зарезало, приказав сосредоточится на дрэг-рейсинге.
С рейсингом вышла история очень поганая в одном месте. Он был изначально чисто сингловый, и всё было хорошо. Но тут решили приделать всякий бэкэнд, и после некоторого раздумья выбрали для этого контору GameSparks, чтобы самим писать поменьше. Какой ошибкой это оказалось! Их C++ SDK начал вызывать у меня лёгкие вопросы ещё при первом знакомстве, когда я увидел, что они удаляют первый элемент из вектора через последовательность std::reverse + std::pop_back + std::reverse. Поправив в их SDK несколько подобных косяков, всё-таки решили им пользоваться.
И вот приходит день и час, и мы выкатываем очередную версию на iOS. Выкатили. А она вешается на стартовом экране намертво у некоторых игроков. Подлость в том, что на всех имеющихся устройствах баг не воспроизводился вообще никак, но зато — воспроизводился на самом свежем по тем временам iPhone 6. Который, по счастью, обнаружился у инвестора, и мы у него его взяли на время отладки.
Дело, конечно же, оказалось в race condition. И что самое прекрасное — не у нас. А в этом самом GameSparks SDK, но даже и не в нём, а в его open source зависимости. Которую авторы GameSparks допилили кривыми добрыми руками (добавив поддержку HTTPS при помощи OpenSSL), конечно же, у себя в форке, не послав в исходный проект никаких пулл-риквестов, и не пройдя никаких проверок сообществом. А в результате у них там, кажется, звался pthread_join на хэндл уже умершего треда, и на этом всё зависало навсегда (очевидно, если тред успел умереть до того, что на более медленных устройствах не происходило).
Фикс состоял насколько я помню что-то около из одной строчки или двух, но пока мы обнаружили, что происходит что-то ненормальное, пока оторвались от других платформ (для нас тогда в приоритете был Windows Phone, т.к. приносил больше всего денег — там у нас не было конкурентов) — все пользователи, какие у нас были на iOS разбежались, да так уже и не вернулись.
Как мы перебанили обычных игроков и заDDoSили свои сервера: практическое руководство