?

Log in

November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

пионеры, поддержка, и Доктор Хаус

Posted on 2009.07.17 at 04:20
Tags: , , ,
- Не дай бог мне попасть на поддержку! Сидишь, правишь чужие баги...
- ...господи, да этот код писали полные идиоты!..
- ...совершенно невозможно в этом дебилизме разобраться! Единственный выход - все к черту переписать! Лучше сразу на всякий случай переписать, а то через несколько лет...
- Эх, вот бы иметь документацию! Такую, чтоб прочитал три страницы за три минуты, и все понятно стало! Да по любому модулю!
- ...Не, это разве документация? Говно это какое-то, во-первых, тут не три страницы, а сто пятьдесят, во вторых, ничерта не понятно, а в третьих - все работает не так!!!
- ...и все-таки, этот код писали полные идиоты!..
- ...что, мелкую фичу добавить к этому коду? Не, я это трогать не буду. Разобраться ж невозможно, да и писали идиоты. Я лучше сбоку вот тут такое приляпаю... Хорошее, большое, и задизайню как следует! Не то, что идиоты...
- ...что, еще и эту фичу? Разбираться? Вы издеваетесь? Да мы это сверху захачим.
- ...не, этот дефект исправить нельзя. Только если все переписать. Как так - появился после добавления моей фичи? На что это вы намекаете?
- ...Какая такая ПРОСТАЯ фича? О чем это вы говорите? Да штоб к ЭТОМУ ее добавить, полгода надо, не меньше. Чтоб все переписать. А что вы хотите?..
- ...ну и что, что это фича касается моего нового, хорошего кода! Это не он виноват, он хороший! Это виноват тот, старый, плохой код, писанный идиотами! Да черт его знает, как он работает! Я ведь вас предупреждал, надо все нахрен переписать! Все!
- ...эх, мне б новый проект! Вот где простор для НАСТОЯЩЕГО творчества!
- ...кто это идиот?! Это Я код писать не умею?! МОЙ код весь переписать?! Да ты что, новичок, охренел? На, сам напиши, попробуй! Что значит, не документирован? Нет у меня времени доки писать, программист я, не писатель! Читай код, сука! Что?! В ООН жалуйся, Кофи Аннану, блять!!!

***

Вот так, дорогие сэры. Поддержка традиционно имеет среди молодых программистов, не писавших ничего серьезного и не работавших в больших группах, репутацию грязной, ни разу не креативной работы. Код проще переписать, чем в нем разбираться. Это удобно еще потому, что переписывание - это тот самый "креатив", которого они так хотят. И совершенно не важно, насколько хорош старый код, и кем он написан, он плох только тем, что в нем надо разбираться, и "исправлять чужие баги". Это почитается унизительным. Одно дело - свои. А тут - чужие! Кошмар!


Да, а еще молодые программисты знамениты тем, что могут написать невероятно много кода в крайне сжатые сроки. Скажем, две тысячи строк кода за выходные запросто могут написать. И они этом очень гордятся. В понятие "написал", разумеется, вкладывается колбасение изолированного кода, не связанного никаким окружением, практически без какого-либо предварительного проектирования, и с отладкой его на паре основных тест-кейсов, без учета каких-либо граничных условий.

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

"Молодость" программиста, впрочем, есть скорее состояние души, чем стаж в индустрии или физиологический возраст. Пионер, он, как известно, всегда остается пионером, и он всегда готов!

Эх, пнимаешь, молодость. :) И не надо мне говорить, что вы не были такими :). Я конечно же охотно верю, что вы потратили на предварительное проектирование своей первой программы не менее 30% времени, что вы покрыли ее как white box, так и black box тестами, учтя граничные условия и обеспечив хорошее покрытие, а потом - конечно же аккуратно задокументировали результат :). Я допускаю даже, что вы были лишены искренней радости от наблюдения того, что вы по сути наблюдаете маленькое чудо, что ваша программа работает на паре тестовых кейсов. И что эта радость отнюдь не была вашей первой мотивацией к тому, чтобы программировать, и вы с самого начала делали это уныло и "промышленно". :)

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

Однако, проблема в том, что эти странные люди вовсе не разделяют нашу радость от работоспособности программы на основном кейсе. Более того, они:
1) негодуют по поводу неожиданных багов, возникающих в самых неожиданных местах. Они, сцуки, так неожиданно нашу программу используют!
2) и кроме того, они хотят от нас новых фич, и новых кейсов! Они хотят, чтобы программа умела больше, и далала все лучше! Постоянно хотят, ссуки!

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

Плохие, негодные проекты никогда не доходят до этой фазы, мои уважаемые коллеги. :) Ибо суть они унылое ни кому не нужное говно, вызывающее зевоту у пользователей. И чем более удачен и успешен проект, тем ДОЛЬШЕ он будет находится в состоянии поддержки и развития. "Поддержка" - это признание. И при поддержке хорошего продукта, его приходится развивать. Добавляя к нему фичи.

То есть, ВСЕ успешные проекты быстро попадают в поддержку, таким образом, БОЛЬШИНСТВО проектов по факту делаются по смешанному циклу - поддержка и развитие. То есть, они развиваются ИНКРЕМЕНТАЛЬНО, в них постоянно правятся дефекты, и добавляется большое количество новых фич. Вероятность "попасть на поддержку" для молодого программиста, таким образом, крайне высока. Как не прискорбно это признать. :)

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

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

Да вот взять хотя бы меня. Проработав 6 лет в цикле поддержки и развития, и будучи "чистым" менеджером последние 4 года, единственное, мимо чего я не могу пройти спокойно мимо - это когда парни, матерясь, ловят злую багу! Волной накатывает охотничий азарт, и я сразу понимаю, как же я по этому соскучился! :)

Вы смотрели сериал "доктор Хаус"? Вы читали детективы про Шерлока Холмса? Значит, вы можете понять, на что похожа лобля багов, уважаемые коллеги. И на кого похож профессионал в этом деле. Холмс, как вы догадались?! - Это элементарно, Ватсон. Для человека, владеющего дедукцией, не составит труда понять, что Вы прибыли именно из Афганистана. Без всяких в жопу логов, отладчиков, и прочей ерунды. :)

Да что аллегории, расскажу одно из последнего. Сейчас я один из руководителей разработки микросхемы-процессора для цифровых телевизионных приставок. Баги, соответственно, у нас а) злые, программно-аппаратные, и б) чрезвычайно красивые, ибо заключаются, например, в артефактах на картике на телевизоре высокой четкости. Мимо такого бага истинный их ценитель равнодушно пройти не сможет никак :).

Короче, парни впервые подключают телевизор, и на нем наблюдаются, помимо картинки, случайно расположенные мерцающие белые точки. Черт знает что. Непронятно, где бага, учитывая, что печатные платы, шлейфы, сам видеоконтроллер в микросхеме, и драйвер к нему - все это дело наших рук. Багу ловило человека 3. Перед телевизором постоянно сидело трое, и задумчиво смотрело на точки. Иногда кто-то что-то мерял осциллографом.

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

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

Это был подарок, ибо любой человек, владеющий дедукцией, поймет, что плата работает при отключенном питании не чудом, а получая его с USB с подключенного компа, которое у нас (кажется) 3.3 вольта, а 5 как от родного блока питания, что понижает уровень единицы, и, соответственно, мы однозначно заключаем, что белые точки появляются из-за того, что "гуляет" уровень единицы в шлейфе. Что объясняет их мерцание, и все эффекты.

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

Один из аппаратчиков решил проверить, как влияет картинку наводка на кабель, положив мобильник на кабель, и позвонив на него. Он, собственно, хотел создать наводку. У него ничего не получилось. В этот момент я опять внимательно смотрел на экран, и заметил, что ТОЧЕК СТАЛО ЧУТЬ-ЧУТЬ МЕНЬШЕ, с мобильником лежащим на кабеле! А не больше! Что говорит нам дедукция? Правильно, это означает наличие ВНЕШНЕЙ наводки, ибо мобильник экранирует собой маленький участок шлейфа!

Я хватаю с полки компакт-диск (внутри компакт-дисков есть слой металла), и кладу сверху шлейфа - и точек становится СИЛЬНО меньше! Тут я, приходя в крайнее волнение, говорю - "нужна фольга! У кого-нибудь есть шоколадка? А, у Вити есть, я помню, он ел ее утром", - и убегаю в соседнюю комнату.

- Влад, тебе надо спокойнее относиться к работе, - улыбаясь говорит мне вслед Женя, руководитель группы мультимедиа.

- Витя, где твоя шоколадка?! Я видел, утром она у тебя была.
- Съел, - подозрительно смотрит на меня Витя.
- Отдай мне фольгу! - я вытаскиваю смятую фольгу из мусорной корзины.
- В чем дело-то?
- Мы ту злую багу поймали, прикинь?! Внешняя наводка на шлейф! Надо в фольгу завернуть!
- Сейчас, подожди, я тебе другой фольги дам, у меня еще шоколадка есть!
- Да какая разница! Догоняй!

Возвращаюсь с фольгой, и заворачиваю в нее кабель. Точки исчезают полностью. Мы видим идеальную картинку.

- Хренассе, откуда это здесь такая наводка? - поражаются аппаратчики.
- Да черт его знает! Интересно, как в этих условиях вообще хоть что-то работает! Надо все нахрен заэкранировать!

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

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

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

- Первый созданный в России видеоконтроллер телевидения высокой четкости, наконец, заработал, и дал на настоящий телевизор чистую картинку, - говорю я, включая видеозапись, - Слово предоставляется главному конструктору видеоконтроллера, руководителю группы мультимедиа, кандидату технических наук, Евгению Янкевичу.

- Гхм! - важно говорит Женя в видеокамеру, поправляя очки - Инопланетный разум, пнимаете-ли, передавал на наш макет свои сигналы, препятствуя испытаниям последних образцов отечественной микроэлектроники. Однако, в сжатые сроки нашими учеными было разработано специальное покрытие для шлейфа, - Женя демонстрирует шлейф обмотанный фольгой камере, - которое надежно защищает макет от сигналов инопланетного разума. Очередная попытка инопланетного разума помешать прогрессу Российской науки в очередной раз пресечена! Ура, товарищи! Выпьем за триумф Российской науки!

Вот как много удовольствия приносит процесс ловли багов. :) Собственно, говоря серьезно, этот баг парни нашли бы и без меня, несколько позже. :) Как они без меня устранили множество других, не менее, а более тяжелых, и трудноуловимых ошибок. Это я бы без них не справился. Но свою дозу экстаза в данном случае я получил. :)

В ловле багов доставляет не только результат, но и сам процесс. И это требует охрененно большой компетенции и практики. Интуиции и наблюдательности. Логики и умения делать выводы. Внимания к мелочам, и одновременно умения абстрагироваться от них. Знаний принципиальных закономерностей, и понимания архитектуры. Умения читать код, и умения его писать. Умения проективать в голове вообще необходимо - это, как ни парадоксально, помогает _читать_ код, и диагностировать ошибки.

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

Не бойтесь поддержки. Не работая на поддержке, сложно стать хорошим инженером. И главное, отказываясь работать на поддержке, вы лишаете себя огромной порции удовольствия, достойного настоящих гурманов :).

Comments:


qehgt at 2009-07-17 01:32 (UTC) (Link)
Замечательно написано.
insooo at 2009-07-17 02:50 (UTC) (Link)
Я "молодой" программист. Половина моей работы заключается в поддержке драйвера продублированного на три операционные системы. Ничего интереснее для себя я сейчас представить не могу)
1a1 -> Первый в алфавите :)
1a1 at 2009-07-17 04:50 (UTC) (Link)
Отлично написано!
lexas
lexas at 2009-07-17 05:37 (UTC) (Link)

Что за кабель был?

Кабель случаем не HDMI ?

Рассказ отличный.
Gaperton
gaperton at 2009-07-17 12:13 (UTC) (Link)

Re: Что за кабель был?

Там была система веревочек.
1) Есть большая плата с большим ПЛИС-ом (где прошит наш квидеоконтроллер). У нее свое питание.
2) В нее втыкается плата переходник (наша), с хитрых разъемов на гражданские разъемы, в которые втыкается шлейф, напиминающий шлейв к диску IDE. Собственно, наводка была на него. По этому кабелю идет цифровой 16-битный интерфейс для пепредачи видео. Это не HDMI.
3) Этот шлейф втыкается в плату (чужую), на которой стоит HDMI-трансивер. У нее свое питание. Эта плата управляется компом через USB.
4) С нее уже идет HDMI на телевизор.



Сера Птах
gray_bird at 2009-07-17 05:46 (UTC) (Link)
Воистину так!
Я сталкивался с еще более предельным случаем кодописательства. Когда в программе уже есть требуемый функционал, но он вызывается не очевидным образом. И вот в поддержку звонит клиент, который не читал инструкцию, там сидит программист, который тоже не читал инструкцию... В итоге молниеносно пишется "пришлепка сбоку", которая должна реализовывать запрашиваемый функционал, вот только почему-то без учета архитектуры системы и тестирования она работает криво и не так. Клиент этой фигней не пользуется, однако она попадает в основную ветку релиза. Далее история повторяется, с другим клиентом и другим инженером, в итоге пишется еще один чудо-модуль, который тоже попадает в основную ветку.
Это тоже удивительное, извращенное удовольствие, находить, читать подобные артефакты, пытаясь понять ход мысли этих людей.

Reflex-blue
reflex_blue at 2009-07-17 05:47 (UTC) (Link)
пока не дочитала до "Да что аллегории, расскажу одно из последнего", нравилось :)
а дальше немножко наивно, угу
еще слышна та порция экстаза :)))))

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

в общем, всем срочно ловить злые баги!
Red Monkey
duska_mom at 2009-07-17 06:09 (UTC) (Link)
Спасибо! Доставило и прослезило.
Loislo
loislo at 2009-07-17 06:55 (UTC) (Link)
Согласен, Хаус это такой азартный программист-траблшутер. Отличный диагност по логам. Всем это говорю, а они ржут.
b00ter
b00ter at 2009-07-17 07:13 (UTC) (Link)
Ну, как-то странно. Электронщики вообще должны первым делом на наводки думать.

Когда мы делали программно-аппаратный комплекс управления механикой в театре, был забавный случай. Мне надо было считывать с одного контроллера через RS-232 состояние четырех кнопок, учитывать это в программе и зажигать при помощи отсылки в тот же RS-232 команд на включение светодиодов над каждой кнопкой. Тесты прошли на ура, на макете работало. Перенесли в реальные условия - началась свистопляска - нажатие кнопки вело либо к загоранию трех светодиодов, либо ни одного. На меня посыпались ебуки. Потом оказалось, что кабель от компьютера к контроллеру (30 см) был протянут не экранированной витой парой, как везде, а обычной витой парой. Который и ловил кучу наводок. После обеда, на котором я уже не знал на что грешить, заменили кабель на экранированный - все заработало как надо.
Сера Птах
gray_bird at 2009-07-17 07:19 (UTC) (Link)
Наводки ладно, они еще понятны, и вполне очевидны. А вот статическое электричество, возникающее от того что в кассовом аппарате трется об корпус бумага при печати, это вообще как? Причем при определенной напряженности электрического поля в кассе сходило с ума ЭКЛЗ и касса переставала работать, пока поле не "стекало".
Вдобавок это не вполне касса а железка подключаемая к программно-аппаратной торговой системе.

shalayev
shalayev at 2009-07-17 07:47 (UTC) (Link)
Хорошо написано! Мне как раз очень в тему :) дал программистам почитать — тоже оценили.

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

Вот это очень верно замечено. Хотя поддержка это уже и не совсем проектная деятельность (с точки зрения классического УП). Тем не менее это действительно реальность, которая слабо отражена в существующих методологиях (ИМХО).
sleepy_drago at 2009-07-17 08:15 (UTC) (Link)
дебаг и написание кода это деятельность разных частей мозга :) Так что те кто пишут код будут его и дальше писать. Документация и тесты не влияют тк их писатели тоже "пишут", пусть и не так азартно. Точно так же те кто с радостью ловят самую необъяснимую багу мучаются с написанием документов тк их надо "писать".

И пока мой опыт показывает, что перейти из одних в другие наверное нельзя. То есть поддержка тут не при чем - все дело в том чтобы найти себе работу, приносящую удовольствие.
NaN
guamoka at 2009-07-17 08:33 (UTC) (Link)
Воспитывать молодых программистов на поддержке- это все равно что учить плаванию детей, забрасывая их сразу на глубину и выжидая, кто же выплывет;) С тех былинных пор педагогика и методы обучения шагнули гораздо дальше. Возможно, для человека пробывшего "чистым" менеджером 4 года выйти в поле и показать свою дедуктивную составляющую, тряхунть стариной, так сказать, и фан. Но повседневная поддержка кода, написанного до тебя,- это не "умения проективать в голове вообще необходимо - это, как ни парадоксально, помогает _читать_ код, и диагностировать ошибки" и проч. Это прежде всего умение проникнуть в психологию толпы разработчиков, "поработавших" до тебя, в их персональные жабы и тараканы и самые правильные представления об окружающем мире, дисорганизацию и хаос, творившиеся до тебя. Даже идеальный код грешит частностями, недо/перепроектированием, недопониманиями, пробелами в требованиях, понимании требований, и пробелами самих заказчиков в понимании того, чего им нужно. В итоге, как правило, получается ситуация, когда "у нас тут все уже написано, но нихрена не работает", а все стахановцы-первопроходцы уже выпили шампанского и разъехались. И фактически "поддержка" заключается в имплементации не сделанного и успевшего поменяться в требованиях, только совсем в другие сроки и совсем из другого положения- положения враскаряку. Не знаю, возможно, где-то существуют 20% проектов, близких к идеалу, но 80% оффшора и не только- именно в таком состоянии: все написано, но нихрена не работает, а заказчик под видом багов накидывает новых требований, и менеджер это проглатывает, ибо трясется за свое место. Так что поддержка- это всего лишь перчик, а не основное блюдо. Не надо ее идеализировать и превращать в панацею:)
d_ao at 2009-07-17 10:07 (UTC) (Link)
Очень согласен.
andy_scott
andy_scott at 2009-07-17 09:35 (UTC) (Link)
Блестящий текст, в зале аплодисменты :) спасибо!
d_ao at 2009-07-17 10:02 (UTC) (Link)
Ловить баги - сложная и увлекательная работа. Но, к сожалению, зачастую недооцениваемая. Одно дело реализовать новую функциональность - это сразу видно, почет и уважуха. Другое дело - найти баг. Вроде как ничего не сделал, только убрал за теми уважаемыми товарищами, которые заимплементив фичу не учли чего-то. Также очень сложно оценить усилия, затраченные на поиск.

Мое мнение - фиксить баги должны те же люди, которые имплементят фичи. Т.е. фиксить всегда только СВОИ баги. Если вы не согласны - хотелось бы услышать, почему это неправильно.
Gaperton
gaperton at 2009-07-17 12:26 (UTC) (Link)
Это правильно, и так дешевле, но это далеко не всегда возможно.

1) На этапе диагностики баги не всегда понятно, кто ее внес. Ее еще надо локализовать для начала. Для этого часто приходится выходить за рамки своего кода. Либо собирать "консилиумы".
2) Тот, кто внес багу, может уже не работать в компании.
3) Тот, кто написал код, в котором бага - может быть в данный момент занят критичной работой. Да хоть другой багой, более высокого приоритета.
Max
muzh_fomushki at 2009-07-17 10:14 (UTC) (Link)
Молодец! :)
brainslugs.blogspot.com
brainslugs.blogspot.com at 2009-07-17 10:21 (UTC) (Link)
Баги то как раз прикольно ловить, и особенно чужие -- не испытываешь никакого чувства вины за него :)

А вот когда надо к куче говнокода прилепить простенькую фичу на полчаса работы, но ты понимаешь что тут сначала надо неделю сидеть и рефакторить весь этот клубок -- вот это реально угнетает.
We come in peace!
develop7 at 2009-07-17 18:56 (UTC) (Link)

Разовьём

И вот идёшь ты к манагеру, излагаешь ему ситуацию, а он смотрит на тебя умными глазами и спрашивает «А прилепить, не рефакторя, сможешь?» А ты смотришь на него и понимаешь, что не можешь сказать "Не смогу", потому как в принципе непреодолимых препятствий реализации этой фичи нет. Ведь "это говнокод и вам же потом будет хуже" это, как правило, аргумент, который принимают к сведению и игнорируют. Как и в этот раз. Менеджер говорит: «Тогда действуй» и ты с матюками под нос удаляешься. Теперь за остаток дня ты вряд ли подступишься к этой фиче.
zerthurd
zerthurd at 2009-07-17 10:47 (UTC) (Link)
Хорошо написал, понравилось :)
(Deleted comment)
avr_forever at 2009-07-28 13:31 (UTC) (Link)

Re: Вот-вот!!!

+1
Наводки --- это ужас.
Давеча вот недавно боролись со страшным багом, проявлявшимся в том, что девайс полностью сходил с ума по непонятным причинам в зависимости от фазы луны.
Как выяснилось, при разработке печатной платы из-за "недослышки" и "непонятки" остался висеть в воздухе вход микросхемы. Причина, собственно, обнаружилась тогда, когда случайно (!) дрыгнули битом регистра, который переключает соответствующую функцию с этой ноги на соседнюю, сидящую на вполне фиксированном уровне.
kasarino
kasarino at 2009-07-17 18:12 (UTC) (Link)
супер! :)
virtul
virtul at 2009-07-17 20:12 (UTC) (Link)
Спасибо за пост. Баг-хантинг действительно доставляет в большинстве случаев. Но бывают такие сложно-воспроизводимые баги (по закону подлости они вылезают именно у заказчкиов/в релизе), львиную долю времени на которых уходит на попытки воспроизвести/найти закономерность. Ибо гипотезы о причинах строить можно до бесконечности, но надо же их еще и проверять. А как проверить если баг происходит один раз на 100 запусков? :(
Simbar
counterpr at 2009-07-19 17:15 (UTC) (Link)
Очень хорошая статья. Спасибо за чтиво.
Вами был представлен один случай ловли багов, однако в жизни все намного скучнее, особенно для опытного разработчика.
Сам я вырос от джуниора до тим лида на одном из таких проектов - успешных и эволюционирующих. Год, два, я переписал почти весь проект (заказчик на рефакторинг не скупился). Что писал не я, то я проектировал. В итоге, фикс багов заключался в том что я вижу симптомы бага и говорю где и что надо поправить или где и что неправильно написано. Если я незнал из-за чего бага, то надо было пол часа что бы его локализовать. Это очень скучно.. Никакого азарта, никакого развития.
В общем я поменял как проект так и технологию разработки и нисколько об этом не жалею.
Павел Корягин
pavel_koryagin at 2009-07-19 17:57 (UTC) (Link)
У молодых программистов более актуальной проблемой является как раз отсутствие таких интересных багов.

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

Для мелких и скучных багов дзен нужен в арсенале :)
Surger
surger at 2009-07-19 18:45 (UTC) (Link)
Спасибо!
Возьмите меня, кто нибудь, в поддержку!

;)
new_mikha
new_mikha at 2009-07-22 05:19 (UTC) (Link)
Теория конечно интересная.

Однако приходилось ли вам разбираться в коде, написаном стадом безумных павианов? Это когда присутствуют методы размером в 3000 строк, с невыравненным кодом (в смысле отступов), с жуткой архитектурой (ок, допустим это я идиот), с безумным количеством копипастов, изначальными ошибками при выборе технологий... Мне приходилось. Багов было - море, и отпилите мне голову, если эта работа должна была кому то нравиться. Поддержка, да. Не дай бог снова на такое попасть.

А ведь такое бывает довольно часто, особенно в нынешние времена, когда (и в России в том числе) бывает нужно править код после бангалорских мастеров...
avr_forever at 2009-07-28 13:33 (UTC) (Link)
Почитай код Мозиллы.
Олег
zamotivator at 2009-07-22 11:04 (UTC) (Link)
http://news2.ru/story/182482/
Вы были правы - ОПСОСы засуетились =)
Gaperton
gaperton at 2009-07-23 20:50 (UTC) (Link)
Ну конечно. Прочитали мой пост, и сразу обкакались :). Вообще, за такие высказывания неплохо бы объявить бойкот Мегафону. И теперь, я точно не буду уходить с Йоты - дождусь новой прошивки и VoIP-а. Из принципа.
Previous Entry  Next Entry