Вопрос о переход в софт из геймдева
Работаю на C# около 5 лет, в софте работал меньше года, потом ушёл в разработку игр. Сейчас меня начали посещать о том, что я хотел бы перейти в софт, но это оказалось сложнее чем мне казалось. Всем необходим именно опыт в софте которого у меня не много.
Как вы думаете на сколько возможно сменить род деятельности? И, если возможно, то как?
51 коментар
Додати коментар Підписатись на коментаріВідписатись від коментарівА в чем проблема? Специалисты везде нужны!
Ох, а у меня наоборот — 4 года Java, но хочу в геймдев...
вам деньги надоели?
дык хотеть же не вредно, не ушел же в геймдев еще и не факт что уйдет
Геймдев как работа дерьмо: платят мало, работать много
если ты на юнити фигачил все это время, тогда, наверное, да — проблема, но легко решаемая, надо просто подтянуть шарп чтобы в книжке Рихтера не было белых пятен, ну и всякие хендлеры/модули, спаны/дивы, индексы, солид и т.д.
если полноценный шарп, то проблема надуманная, предметная область не имеет значения
P.S.: и из программиста в программиста переход — не смена рода деятельности, то если бы ты барменом был, тогда другой разговор :)))
На юнити в основном да, и если я работаю на юнити это не значит что у меня плохой шарп. И Рихтера я тоже читал и с солид принципами знаком. Я вот тоже думал что не будет ни какой проблемы, а вот оказалось есть проблема.
читал и знаком это знаю и всегда следую? если да, то нет проблемы, только в каких-то лютых компаниях могут забраковать за такое, просто сходи в нормальную
Твой шанс: это найти тех кому нужны разработчики прямо на сейчас, и желательно с очень тонкой прослойкой между заказчиком и тобой. Конторы типа «нам вообще никто не нужен, но если очень понравится — возьмем» — будут футболить, среди аутсорсеров таких выше крыши.
Да, скорее всего так и есть
У Вас +500 конекшенов на линкедине и хороший профиль — оповестите HR -ов что вы хотите перейти и выберете подходящее предложение. все.
Я сейчас так и пробую, к сожалению в основном получаю ответ что вы не достаточно работали с нашей технологией, увы.
Добавьте HR-ов из моего профиля — они возможно поактивнее )))
попробую)
Послушайте, но это ж такая игра: HR говорит, что нужно столько-то лет работы. Вы говорите, что вы именно столько и работали. И меняете резюме. И шлете его. На собеседование берете честное и говорите «Ой, что-то у вас какое-то не то резюме, старое. Вот новое.»
ну, это уже из разряда лайфхаков мне кажется)
Думаю, вопрос не в опыте программирования вообще, а именно в знаниях конкретных технологий и соответствии знаний запрлатным ожиданиям. Вопрос в том, что Вы уже знаете/умеете на текущий момент и чем именно хотите заниматься в софте. Пытаться стать Jack-of-all-trades явно не стоит, лучше выбрать специализацию, которая будет Вам интересна и сфокусироваться на ней, а уже после расширять спектр знаний. Набор наиболее востребованных технологий, это:
Entity Framework
ASP.Net MVC
WCF
WebAPI
MS SQL
AngularJS/KnockoutJS
Azure
Если можете сформулировать, что конкретно Вы ищете и в чем проблемы с поиском, возможно смогу что-то еще подсказать.
На счёт зарплатных ожиданий: я чётко понимаю что при смене стека технологий будет понижение и я к этому готов. На счёт стека и направленности: я как вы и сказали смотрю на веб, не из-за востребованности, а скорее из интереса и перспектив. У меня скорее проблема в том что даже не готовы рассматривать мою кандидатуру из-за отсутствия опыта в технологии.. Хотя я готов выучить все необходимые технологии на проект в свободное от работы время.
Вы пытаетесь вклиниться в область, где сейчас огромнейшая конкуренция среди претендентов уже выучивших все необходимые технологии.
В первое время свободного от работы времени, фактически, не будет, чтобы быстро въехать в проект, над ним надо будет мозговать и в личное время.
Поэтому сначала все-таки придется изучить и опробовать технологии, а потом уже заняться поиском работы.
Я это прекрасно понимаю и сейчас как раз и занимаюсь изучением.
Порог очень высокий. Как от беллетристики перейти в юриспруденцию, зная русский. Вроде и язык один, но де-факто язык разный.
Иными словами, нужен АРГУМЕНТ — зачем ты собираешься понести транзакционные издержки на переход. Если только деньги — аргумент сомнительный, лучше ищи куда прыгнуть в геймдеве. Переезд в другую страну вероятно выйдет дешевле.
Мой аргумент в том что я хочу делать то, что будет помогать людям в в работе и это будут использовать.
Тогда добро пожаловать в реальный мир! Теперь определяйся куда тебе — бодишопы или продуктовая разработка.
Ключевая дрянь бодишопов — что ты окажешься в том же геймдеве, но в другой игре — в бюрократию. То есть то что ты будешь делать, людям как правило не нужно.
Ключевая дрянь продукта/сервиса — то что они с огромной вероятностью пролетают. Твоя задача не попасть в те, которые пролетают с вероятностью 100%.
Ещё есть фриланс. Но тут уже тебе проще своими глазами глянуть на этот рынок. Если кратко, то дерьма неимоверное количество всех сортов и расцветок, ибо никто эти конюшни толком не чистит. Туда ходить не рекомендую.
Только исходя из этого решения будешь определяться, что тебе собственно нужно. Абсолютно разный набор требований. Даже за одними и теми же ключевыми словами стоят разные по сути задачи, и без прямого разговора ты не поймёшь, что из хотелок составляет97-99% работы, а что просто красивые слова приписанные для понту.
Есть одна гадость самого реального мира: конечный потребитель крайне редко будет давать оценку качеству твоей работы. Его как правило никто не слушает. Думаю, в геймдеве ты уже это понял. Вопрос насколько готов с этим смириться. Например я так и не смирился, и тем самым ввязался в конкурентную войну в неравных условиях — нескучное занятие :)
Бодишопы или нет — сложный вопрос, конечно хотелось бы в продуктовой с хорошим продуктом. Но из своего опыта я вынес что скорее важен не тип компании и даже не продукт. При выборе лучше руководствоваться тем, на сколько тебе тебе хочется работать с людьми которые тебя собеседовали (в том числе и руководитель конечно).
Фриланс да, как-то пробовал, не для меня.
На счёт на сколько я готов смириться с тем что пользователей не слушают.. Не знаю готов ли)
Ну это ключевой выбор — НА КОГО ты работаешь, КОГО ты удовлетворяешь.3-5% кода. Притом половину из них выбросишь на рефакторинге. Если для бюрократов — то и 100% не предел, и TDD наше всё.
К примеру, если ты пишешь для клиентов, то покрываешь тестами
Людей делает окружение, точно говорю. Какие стимулы — такие и люди. И человек попадая в бюрократию — становится бюрократом. Есть те кто наоборот — получает абсолютно противоположный навык, но таких всего 0.2%.
О чём пытаюсь сказать — куда пойдёшь, таким и будешь. А войти сможешь и туда, и туда, если точно знаешь что это то к чему ты стремишься, и что самое важное — готов отказаться от прошлого образования и опыта. Если не готов — не ходи.
В теории нет разницы между теорией и практикой. На практике есть.
Тестами покрываются ключевые точки коммуникации, чаще всего API. В остальных местах просто вылизывают код. Написать качественный код занимает меньше времени, чем код средней паршивости и тест к нему паршивости хуже средней. Если бы то время, которое тратится на написание тестов, люди тратили на рефакторинг кода — мы бы жили в безглючном мире.
Против чего реально работают тесты — против человеческого фактора. Когда хочется побыстрее, а нельзя. Иными словами, это искусственный тормоз, для тех кому он необходим. А необходим он менеджерам, которые кричат «давай быстрее», и которым некому набить морду. Но работает такой подход слабо, поскольку написание тестов — это тоже код, и в результате количество багов только удваивается. Вспомни, сколько раз проблема была в самом тесте, а не в коде?
И главное, почему нужно отказываться от тестов всего и вся: чтобы потом изменить код, требуется в2-3 раза БОЛЬШЕ человеческой памяти. А это крайне ограниченный ресурс. И если нет атмосферы глубокого погружения, то задача на 20 минут может запросто лечь в долгий ящик на 4 месяца. Просто потому что никто не хочет за неё браться, ведь версия-то стабильна.
Заканчивается тем, что в долгий ящик попадают багрепорты по сравнительно редко встречаемым багам. Но когда приходит пора выкатить новую версию, серьёзное обновление — тестеры в последний момент вспоминают о старых багах. Кому они попадают в результате? Джунам естественно! И новая версия летит в продакшен уже с багами джунов. Часть из этих багов — обязательно попадает в долгий ящик до новой серьёзной версии. Результат: обесценивание продукта, неимоверные затраты на его продажи, только потому что ВЫГОДУ по сравнению с РИСКОМ никто не оценивал — в результате боролись с риском, и потеряли выгоду.
Как происходит то же самое в сильном продукте: затраты идут не на написание уймы тестов, и соответственно кучу всякого тестирования, а на ОБРАТНУЮ СВЯЗЬ. Бета-тестеры оказываются куда лучше внутренних. Я не говорю, что внутренних иметь не нужно, но переоценивать их роль не стоит, и перенагружать ритуалами тоже. А вот обратная связь должна подниматься реальными профессионалами, которых вы готовы слушать сами, и фактически делегировать им тактическое руководство.
PS. Тесты начисто лишают всех преимуществ фреймворков. Прежде всего — ПОНИМАНИЯ кода.
Окей. Написал я каких-то пару методов. Ничего сверхсложного, но есть немного бизнес логики.
Через 3 месяца произошли изменения в какой-то структуре где-то там, методы нужно дописать. Вася садится, дописывает пару новых кейсов. Потом решил подрефакторить и часть моего кода, ибо теперь есть слегка пересекающиеся кейсы.
Позже оказывается, что были tricky moments в бизнес логике, и Вася своим рефакторингом поломал все к чертям.
А был бы тест — при сборке Вася бы увидел failed tests : N, пошел бы разобраться и понял свою ошибку. Возможно даже зарефакторил опять, но не упуская эти кейсы.
Иногда это улучшит читаемость, сократит количество кода, и тд.
В остальных 95% случаев да, не надо лезть. Но такие люди везде есть...
и именно для этих кейсов есть код ревью
тесты не гарантируют защиту от этого, они сами могут быть с багами, 100% покрытие в целом недостижима, и пустая трата времени
Я не говорил о 100% покрытии. Но вовсе игнорить их, или написать пару штук, все же, как по мне, нельзя.
там была речь не про пару штук, а насколько я понял Алексея о покрытие ключевых участков — что абсолютно правильно
Не ключевых участков кода, а ключевых участков ВЗАИМОДЕЙСТИЯ. То есть те места, где ввод и вывод документированы.
А вот как раз те места где данные меняются — нужно вылизывать и рефакторить код. В том числе для того, чтобы его было потом легко менять, и так же легко найти виновника бага при очередном изменении.
В противном случае, когда тестом покрывается тривиальный код вместо API — получаем ситуацию Райикна «Кто сшил этот костюм?». В отдельности всё работает, а как целый продукт — никого не волнует.
Никто и не говорит про пару. Но про пару процентов — да.
Видимо, я понял это как отказ от тестов в пользу фулл рефакторинга.
if(код читаешь) while(не понимаешь что он делает || с чем){ рефакторить;}
-
Абсолютно верно. И посылая по известному адресу идеологов «don’t repeat youself», если какому-то Васе понадобилась для своего кейза часть кода — так пусть берёт и копипастит. А не закладывает душу дьяволу ради каких-нить пары ништяков.
Поверьте, лучше иметь сотни мест одинакового кода, чем одно которое запутано чужими исключениями и писанное несколькими людьми с разным уровнем эволюции. Даже если в этом коде окажется бага, компьютер с лёгкостью найдёт все места где лежит конкретный кусок текста. Но если код один на всех — то баги вы будете плодить друг другу, пока кому-нить в итоге руки не поотрывают.
2) Именно эти «tricky moments» практически никогда не покрываются тестами. По той уже причине, что они нетривиальны. И гораздо проще просто не давать «неправильных» данных тесту.
Если факты не соответствуют теории — от них избавляются.
Я и говорю о тестах на tricky moments. Покрывать тестами простые вещи не надо, а специфические места — вполне стоит.
Как правило не помогает. Только грамотное написание кода, без лишней оптимизации. Пусть чуть дольше, но чтобы понятно как.
Отдельный вопрос по регулярным выражениям. Я считаю, того кто их придумал следует посадить пожизненно с обязательством разгребать логи, прочитывая их вслух. Это дерьмо хуже самого страшного ассемблера или битового кодирования. И даже яростные его фанаты ошибаются в них просто песец как часто.
Ключевая гадость регулярки — что она отвратительно поддаётся дебагу. И лишь вопрос времени, когда к ней прилетит, то чем она подавится.
Регулярки — необходимое зло. И ничего плохого не случается, если использовать умеренно где нужно (парсить файлы/сайты/итд)
К сожалению, это «где нужно» выливается в настройки конечного пользователя. Которому предлагается [сюрпраайз] написать регулярку.
Про админские задачи я вообще молчу, сплошь и рядом требуют не только с ходу писать регулярку (и да, угадывать особенности её работы в конкретном приложении), но ещё и знать мета-язык автора софта.
В общем, я не сторонник телесных наказаний, но этот тот случай когда они необходимое зло.
Одно дело когда ты что-то парсишь не особо важное, и если из 1000 сайтов 1 не распарсился, то хрен с ним. И совершенно другое — когда тебя принуждают той же регуляркой контролировать вопросы безопасности, ИЧСХ даже потестить некак.
Бюрократія == бодішоп == тдд???? А продукт != тдд або ~ тдд
Игры очень помогают людям в работе. Иначе рехнуться можно было бы, если бы была одна работа в жизни.
Рехнуться тоже помогает :)
Вот у тебя есть воображаемый енотик? Так давай подарю. (надоел сволочь, советует как чистый код писать)
Нет, у меня есть прист 102 уровня в PW :)
Меняешь на енотика? Он добрый и пушистый.
Нет, прист пока нужнее :)