[Эксельбант]

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

Когда читала перед глазами был наш главный программер, который проверяет код у остальных, орущий, что в ** он видел все это и ему все равно что оно работает, раз написано некрасиво  ^_^

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

[zaza]

Ты видать путаешь тех, кто фиксит чужие баги, и тех, кто пишет автотесты.

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

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

Я же говорю, вы не видели геймдев. В те же времена всё было ещё хуже и писать океан велосипедов было стандартной практикой. Вообще использование вещей "общего назначения" не очень тут живёт. Читал истории как использование вещей общего назначения, чудно работающее в обычном коде, приводило к аду в игре.

Да, и это - когда некая персона приписывает или ей приписывают половину IQ страны, сразу хочется спросить и чего эта персона сделала полезного в ИТ. Даже Бринн и Цукерберг себе таких понтов не позвляют, насколько известно.

Это вроде бы был IronPeter, программировал движок Heroes Of Might And Magic 5, движок Аллодов и в ещё куче игр. Я уже не помню точно, он из геймдева ушёл.

[Nifeus2]

Смотрю на НК элита програмирования нашей страны собралась 

[parter]

Успех Diablo повысил планку, и по Starcraft было принято решение, которое подтвердило кредо компании - не выпускать игры, пока они не готовы.

видимо забыли про принципы и выпустили диабло3 

[zaza]

Смотрю на НК элита програмирования нашей страны собралась 

Я всего лишь говнокодер, мне далеко до.

[Targitay]

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

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

Ну не знаю, у нас в фирме это так:
Верификация, там очень много студентов которые ищут и несколько инженеров которые фиксят, если баг серьезный то им уже занимаются в микроархетектуре.
Эмуляция- доп проверки, работа с кодом через скрипты.
Дизайн- напрямую работа с кодом, студенты не допускаются, работают в основном уже опытные инженеры.
Ну это все относится к компание которая занимается "хардом" типо intel, qualcomm. Возможно у "софтеров" это подругому.

[ku7mich]

Очень интересная статья, спасибо большое. С нетерпением жду продолжения.

[Apptyc]

Классная статейка, переводите дальше, обязательно. И быстрей бы.

[Dzugaru]

Ну не знаю, у нас в фирме это так:
Верификация, там очень много студентов которые ищут и несколько инженеров которые фиксят, если баг серьезный то им уже занимаются в микроархетектуре.
Эмуляция- доп проверки, работа с кодом через скрипты.
Дизайн- напрямую работа с кодом, студенты не допускаются, работают в основном уже опытные инженеры.
Ну это все относится к компание которая занимается "хардом" типо intel, qualcomm. Возможно у "софтеров" это подругому.

Слышал, что у тех, кто реально занимается хардом (intel) всё еще на порядок круче. Там код/дизайн процов верифицируют статическими анализаторами кода и теорем-пруверами навроде Microsoft Z3, Pex and Moles и т.д. Проверяют даже временные характеристики схем.  Перспективы у таких исследований для кодинга огромные, но я пока в реальных задачах не применял.

[Eldhenn]

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

Когда читала перед глазами был наш главный программер, который проверяет код у остальных, орущий, что в ** он видел все это и ему все равно что оно работает, раз написано некрасиво  ^_^

Вам страшно повезло, что у вас есть такой человек.

[Eldhenn]

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

ЗЫ А я бы хотел погонять то, что на первой картинке Орков в космосе

[Dzugaru]

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

ЗЫ А я бы хотел погонять то, что на первой картинке Орков в космосе

Нет никогда никаких оправданий переписывания всего кода. Это всегда огромный риск, что подтверждается кучей реальных случаев. С ходу вспоминаю про Oracle, но что-то не могу найти статейки. Вот про стартапы: http://steveblank.com/2011/01/25/startup-suicide-%E2%80%93-rewriting-the-code/

Выкинутое на помойку время тестирования и исправления старого кода (иногда годы) + время тестирования и исправления нового кода +  не факт что новый дизайн будет лучше старого, особенно когда старый дизайн непонятен и т.д.

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

[Keiran]

Спасибо,интересно.

[Dzugaru]

Прочитал вторую часть (про двусвязные списки) - какая-то она не очень. Частично пишет довольно очевидные и известные вещи, частично спорные, что отражено в комментах. Даже для прогера интересного мало.

[Эксельбант]

Нет никогда никаких оправданий переписывания всего кода. Это всегда огромный риск, что подтверждается кучей реальных случаев.
Если уж совсем плохо всё, то переписывать/рефакторить надо частями, оставляя систему в рабочем и тестируемом состоянии.

Разумеется. Кстати самый отличный способ оценить нового сотрудника - если он с порога вопит "надо все переписать", то обычно такой сотрудник живет в команде недолго.

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