пионеры, поддержка, и Доктор Хаус
- Не дай бог мне попасть на поддержку! Сидишь, правишь чужие баги...
- ...господи, да этот код писали полные идиоты!..
- ...совершенно невозможно в этом дебилизме разобраться! Единственный выход - все к черту переписать! Лучше сразу на всякий случай переписать, а то через несколько лет...
- Эх, вот бы иметь документацию! Такую, чтоб прочитал три страницы за три минуты, и все понятно стало! Да по любому модулю!
- ...Не, это разве документация? Говно это какое-то, во-первых, тут не три страницы, а сто пятьдесят, во вторых, ничерта не понятно, а в третьих - все работает не так!!!
- ...и все-таки, этот код писали полные идиоты!..
- ...что, мелкую фичу добавить к этому коду? Не, я это трогать не буду. Разобраться ж невозможно, да и писали идиоты. Я лучше сбоку вот тут такое приляпаю... Хорошее, большое, и задизайню как следует! Не то, что идиоты...
- ...что, еще и эту фичу? Разбираться? Вы издеваетесь? Да мы это сверху захачим.
- ...не, этот дефект исправить нельзя. Только если все переписать. Как так - появился после добавления моей фичи? На что это вы намекаете?
- ...Какая такая ПРОСТАЯ фича? О чем это вы говорите? Да штоб к ЭТОМУ ее добавить, полгода надо, не меньше. Чтоб все переписать. А что вы хотите?..
- ...ну и что, что это фича касается моего нового, хорошего кода! Это не он виноват, он хороший! Это виноват тот, старый, плохой код, писанный идиотами! Да черт его знает, как он работает! Я ведь вас предупреждал, надо все нахрен переписать! Все!
- ...эх, мне б новый проект! Вот где простор для НАСТОЯЩЕГО творчества!
- ...кто это идиот?! Это Я код писать не умею?! МОЙ код весь переписать?! Да ты что, новичок, охренел? На, сам напиши, попробуй! Что значит, не документирован? Нет у меня времени доки писать, программист я, не писатель! Читай код, сука! Что?! В ООН жалуйся, Кофи Аннану, блять!!!
***
Вот так, дорогие сэры. Поддержка традиционно имеет среди молодых программистов, не писавших ничего серьезного и не работавших в больших группах, репутацию грязной, ни разу не креативной работы. Код проще переписать, чем в нем разбираться. Это удобно еще потому, что переписывание - это тот самый "креатив", которого они так хотят. И совершенно не важно, насколько хорош старый код, и кем он написан, он плох только тем, что в нем надо разбираться, и "исправлять чужие баги". Это почитается унизительным. Одно дело - свои. А тут - чужие! Кошмар!
Да, а еще молодые программисты знамениты тем, что могут написать невероятно много кода в крайне сжатые сроки. Скажем, две тысячи строк кода за выходные запросто могут написать. И они этом очень гордятся. В понятие "написал", разумеется, вкладывается колбасение изолированного кода, не связанного никаким окружением, практически без какого-либо предварительного проектирования, и с отладкой его на паре основных тест-кейсов, без учета каких-либо граничных условий.
Ибо молодому программисту, на самом-то деле, не интересно ловить не только чужие, но и свои собственные баги. Ему интересно творить. Думать ему перед написанием кода тоже не особо интересно, ибо написание кода ему в новинку, представляет собой для него бешеный креатив, и поэтому кода пишет он много. И написание кода ему нириально доставляет. В отличии от отладки, диагностики проблем, написания документации. И конечно, тягостных раздумий о том, как написать меньше кода, и чтобы в нем было поменьше проблем, а не побольше. Последнее для него совершенно противоестественно. Так уж он устроен, молодой программист.
"Молодость" программиста, впрочем, есть скорее состояние души, чем стаж в индустрии или физиологический возраст. Пионер, он, как известно, всегда остается пионером, и он всегда готов!
Эх, пнимаешь, молодость. :) И не надо мне говорить, что вы не были такими :). Я конечно же охотно верю, что вы потратили на предварительное проектирование своей первой программы не менее 30% времени, что вы покрыли ее как white box, так и black box тестами, учтя граничные условия и обеспечив хорошее покрытие, а потом - конечно же аккуратно задокументировали результат :). Я допускаю даже, что вы были лишены искренней радости от наблюдения того, что вы по сути наблюдаете маленькое чудо, что ваша программа работает на паре тестовых кейсов. И что эта радость отнюдь не была вашей первой мотивацией к тому, чтобы программировать, и вы с самого начала делали это уныло и "промышленно". :)
Это, в сущности, прекрасно, и ничего плохого в этом нет. Дело однако в том, что цель и реальность промышленного программирования немного другая. За программу должны заплатить деньги те люди, чью потребность она удовлетворяет. Это никак не конфликтует с целью получения удовольствия от программирования, даже напротив, факт того, что результат нашего труда людям полезен, и они его ценят - также нириально доставляет.
Однако, проблема в том, что эти странные люди вовсе не разделяют нашу радость от работоспособности программы на основном кейсе. Более того, они:
1) негодуют по поводу неожиданных багов, возникающих в самых неожиданных местах. Они, сцуки, так неожиданно нашу программу используют!
2) и кроме того, они хотят от нас новых фич, и новых кейсов! Они хотят, чтобы программа умела больше, и далала все лучше! Постоянно хотят, ссуки!
Здесь и состоит загвоздка. Реальность промышленного программирования состоит в том, что любой коммерчески успешный (читай - удачный, нужный людям) проект достаточно быстро выходит из фазы первой версии, и превращается в то, что молодые программисты называют "поддержкой". А на самом деле - является не только поддержкой, но и развитием.
Плохие, негодные проекты никогда не доходят до этой фазы, мои уважаемые коллеги. :) Ибо суть они унылое ни кому не нужное говно, вызывающее зевоту у пользователей. И чем более удачен и успешен проект, тем ДОЛЬШЕ он будет находится в состоянии поддержки и развития. "Поддержка" - это признание. И при поддержке хорошего продукта, его приходится развивать. Добавляя к нему фичи.
То есть, ВСЕ успешные проекты быстро попадают в поддержку, таким образом, БОЛЬШИНСТВО проектов по факту делаются по смешанному циклу - поддержка и развитие. То есть, они развиваются ИНКРЕМЕНТАЛЬНО, в них постоянно правятся дефекты, и добавляется большое количество новых фич. Вероятность "попасть на поддержку" для молодого программиста, таким образом, крайне высока. Как не прискорбно это признать. :)
Удивительно, кстати, что традиционное "управление проектами" уделяет столь мало внимания этому жизненному факту, являющемуся кроме всего прочего признаком успеха продуктовой компании в нашей индустрии, концентрируясь на новых проектах "с чистого листа". Надо уметь управляться в той реальности, в которой мы живем, не так ли? Однако, в этот раз я хочу рассказать не об управлении разработкой при цикле "поддержка и развитие", а о том, что данная реальность вовсе не так тягостна для молодых программистов, как им кажется.
Дело в том, что писать код - это не самое большое удовольствие. Это ерунда, слабенькое средство, от которого торкает не так сильно. Истинное удовольствие, гораздо более сильное, и подсев на которое, сложно слезть - кроется именно в нелюбимой ими "поддержке".
Да вот взять хотя бы меня. Проработав 6 лет в цикле поддержки и развития, и будучи "чистым" менеджером последние 4 года, единственное, мимо чего я не могу пройти спокойно мимо - это когда парни, матерясь, ловят злую багу! Волной накатывает охотничий азарт, и я сразу понимаю, как же я по этому соскучился! :)
Вы смотрели сериал "доктор Хаус"? Вы читали детективы про Шерлока Холмса? Значит, вы можете понять, на что похожа лобля багов, уважаемые коллеги. И на кого похож профессионал в этом деле. Холмс, как вы догадались?! - Это элементарно, Ватсон. Для человека, владеющего дедукцией, не составит труда понять, что Вы прибыли именно из Афганистана. Без всяких в жопу логов, отладчиков, и прочей ерунды. :)
Да что аллегории, расскажу одно из последнего. Сейчас я один из руководителей разработки микросхемы-процессора для цифровых телевизионных приставок. Баги, соответственно, у нас а) злые, программно-аппаратные, и б) чрезвычайно красивые, ибо заключаются, например, в артефактах на картике на телевизоре высокой четкости. Мимо такого бага истинный их ценитель равнодушно пройти не сможет никак :).
Короче, парни впервые подключают телевизор, и на нем наблюдаются, помимо картинки, случайно расположенные мерцающие белые точки. Черт знает что. Непронятно, где бага, учитывая, что печатные платы, шлейфы, сам видеоконтроллер в микросхеме, и драйвер к нему - все это дело наших рук. Багу ловило человека 3. Перед телевизором постоянно сидело трое, и задумчиво смотрело на точки. Иногда кто-то что-то мерял осциллографом.
Собственно, мимо такого пройти совершенно невозможно, хоть я и не микроэлектронщик, а программист, и я подключился к расследованию. Драйвер мы исключили сразу. Оставалось понять, проблема цифровая, или аналоговая. Сначала мне удалось установить систему в расположении белых точек - они определялись цветовым паттерном точек вокруг. Что было уже прикольно, заподозрили шлейф и аналоговую багу.
Потом, один из аппаратчиков отключил питание платы с трансивером (внешняя плата формирователя телесигнала, не наша), и я, будучи единственным, кто в данный момент смотрел на экран (парни смотрели на плату и на монитор), заметил, что изображение почему-то не пропало, зато белых точек стало больше.
Это был подарок, ибо любой человек, владеющий дедукцией, поймет, что плата работает при отключенном питании не чудом, а получая его с USB с подключенного компа, которое у нас (кажется) 3.3 вольта, а 5 как от родного блока питания, что понижает уровень единицы, и, соответственно, мы однозначно заключаем, что белые точки появляются из-за того, что "гуляет" уровень единицы в шлейфе. Что объясняет их мерцание, и все эффекты.
Осталось понять, почему это происходит. То-ли и-за рассогласованного питания на двух платах (земля общая, но питание разное), или из-за наводок в шлейфе, в котором провода не проложены через один землей, или... из-за внешней наводки, что в данном случае настолько невероятно, что данный вариант никому не пришел в голову. Уже можно пробовать укоротить шлейф, и это с высокой вероятностью поможет. Но это долго.
Один из аппаратчиков решил проверить, как влияет картинку наводка на кабель, положив мобильник на кабель, и позвонив на него. Он, собственно, хотел создать наводку. У него ничего не получилось. В этот момент я опять внимательно смотрел на экран, и заметил, что ТОЧЕК СТАЛО ЧУТЬ-ЧУТЬ МЕНЬШЕ, с мобильником лежащим на кабеле! А не больше! Что говорит нам дедукция? Правильно, это означает наличие ВНЕШНЕЙ наводки, ибо мобильник экранирует собой маленький участок шлейфа!
Я хватаю с полки компакт-диск (внутри компакт-дисков есть слой металла), и кладу сверху шлейфа - и точек становится СИЛЬНО меньше! Тут я, приходя в крайнее волнение, говорю - "нужна фольга! У кого-нибудь есть шоколадка? А, у Вити есть, я помню, он ел ее утром", - и убегаю в соседнюю комнату.
- Влад, тебе надо спокойнее относиться к работе, - улыбаясь говорит мне вслед Женя, руководитель группы мультимедиа.
- Витя, где твоя шоколадка?! Я видел, утром она у тебя была.
- Съел, - подозрительно смотрит на меня Витя.
- Отдай мне фольгу! - я вытаскиваю смятую фольгу из мусорной корзины.
- В чем дело-то?
- Мы ту злую багу поймали, прикинь?! Внешняя наводка на шлейф! Надо в фольгу завернуть!
- Сейчас, подожди, я тебе другой фольги дам, у меня еще шоколадка есть!
- Да какая разница! Догоняй!
Возвращаюсь с фольгой, и заворачиваю в нее кабель. Точки исчезают полностью. Мы видим идеальную картинку.
- Хренассе, откуда это здесь такая наводка? - поражаются аппаратчики.
- Да черт его знает! Интересно, как в этих условиях вообще хоть что-то работает! Надо все нахрен заэкранировать!
- Я же говорил, это аналоговая проблема, - лениво заключает Гоша (руководитель другой группы микроэлектроники, зашедший посмотреть, как соседняя группа полным составом ловит такую зычную и диковинную багу) - а ты, Влад, по-моему, не тем занимаешься :). Тебе лаборантом надо работать, а не менеджером :).
- Шесть лет на поддержке даром не проходят, Гоша! - говорю я, - Рефлексы остались, ничего не могу с собой поделать. Ну что, парни, я разливаю коньяк. Ибо есть повод.
Витя медленно, с достоинством несет идеально отглаженную фольгу от второй своей шоколадки, ребята заворачивают в нее шлейф, и аккуратно заматывают его скотчем. Так оно и работает до сих пор. :)
- Первый созданный в России видеоконтроллер телевидения высокой четкости, наконец, заработал, и дал на настоящий телевизор чистую картинку, - говорю я, включая видеозапись, - Слово предоставляется главному конструктору видеоконтроллера, руководителю группы мультимедиа, кандидату технических наук, Евгению Янкевичу.
- Гхм! - важно говорит Женя в видеокамеру, поправляя очки - Инопланетный разум, пнимаете-ли, передавал на наш макет свои сигналы, препятствуя испытаниям последних образцов отечественной микроэлектроники. Однако, в сжатые сроки нашими учеными было разработано специальное покрытие для шлейфа, - Женя демонстрирует шлейф обмотанный фольгой камере, - которое надежно защищает макет от сигналов инопланетного разума. Очередная попытка инопланетного разума помешать прогрессу Российской науки в очередной раз пресечена! Ура, товарищи! Выпьем за триумф Российской науки!
Вот как много удовольствия приносит процесс ловли багов. :) Собственно, говоря серьезно, этот баг парни нашли бы и без меня, несколько позже. :) Как они без меня устранили множество других, не менее, а более тяжелых, и трудноуловимых ошибок. Это я бы без них не справился. Но свою дозу экстаза в данном случае я получил. :)
В ловле багов доставляет не только результат, но и сам процесс. И это требует охрененно большой компетенции и практики. Интуиции и наблюдательности. Логики и умения делать выводы. Внимания к мелочам, и одновременно умения абстрагироваться от них. Знаний принципиальных закономерностей, и понимания архитектуры. Умения читать код, и умения его писать. Умения проективать в голове вообще необходимо - это, как ни парадоксально, помогает _читать_ код, и диагностировать ошибки.
Короче, диагностика ошибок, это такое занятие, которое требует ВСЕХ умений сразу. Когда вы начнете получать удовольствие от диагностики ошибок, и в особенности - в чужом коде, это будет признаком того, что вы становитесь настоящим профессионалом. Как доктор Хаус.
Не бойтесь поддержки. Не работая на поддержке, сложно стать хорошим инженером. И главное, отказываясь работать на поддержке, вы лишаете себя огромной порции удовольствия, достойного настоящих гурманов :).
- ...господи, да этот код писали полные идиоты!..
- ...совершенно невозможно в этом дебилизме разобраться! Единственный выход - все к черту переписать! Лучше сразу на всякий случай переписать, а то через несколько лет...
- Эх, вот бы иметь документацию! Такую, чтоб прочитал три страницы за три минуты, и все понятно стало! Да по любому модулю!
- ...Не, это разве документация? Говно это какое-то, во-первых, тут не три страницы, а сто пятьдесят, во вторых, ничерта не понятно, а в третьих - все работает не так!!!
- ...и все-таки, этот код писали полные идиоты!..
- ...что, мелкую фичу добавить к этому коду? Не, я это трогать не буду. Разобраться ж невозможно, да и писали идиоты. Я лучше сбоку вот тут такое приляпаю... Хорошее, большое, и задизайню как следует! Не то, что идиоты...
- ...что, еще и эту фичу? Разбираться? Вы издеваетесь? Да мы это сверху захачим.
- ...не, этот дефект исправить нельзя. Только если все переписать. Как так - появился после добавления моей фичи? На что это вы намекаете?
- ...Какая такая ПРОСТАЯ фича? О чем это вы говорите? Да штоб к ЭТОМУ ее добавить, полгода надо, не меньше. Чтоб все переписать. А что вы хотите?..
- ...ну и что, что это фича касается моего нового, хорошего кода! Это не он виноват, он хороший! Это виноват тот, старый, плохой код, писанный идиотами! Да черт его знает, как он работает! Я ведь вас предупреждал, надо все нахрен переписать! Все!
- ...эх, мне б новый проект! Вот где простор для НАСТОЯЩЕГО творчества!
- ...кто это идиот?! Это Я код писать не умею?! МОЙ код весь переписать?! Да ты что, новичок, охренел? На, сам напиши, попробуй! Что значит, не документирован? Нет у меня времени доки писать, программист я, не писатель! Читай код, сука! Что?! В ООН жалуйся, Кофи Аннану, блять!!!
***
Вот так, дорогие сэры. Поддержка традиционно имеет среди молодых программистов, не писавших ничего серьезного и не работавших в больших группах, репутацию грязной, ни разу не креативной работы. Код проще переписать, чем в нем разбираться. Это удобно еще потому, что переписывание - это тот самый "креатив", которого они так хотят. И совершенно не важно, насколько хорош старый код, и кем он написан, он плох только тем, что в нем надо разбираться, и "исправлять чужие баги". Это почитается унизительным. Одно дело - свои. А тут - чужие! Кошмар!
Да, а еще молодые программисты знамениты тем, что могут написать невероятно много кода в крайне сжатые сроки. Скажем, две тысячи строк кода за выходные запросто могут написать. И они этом очень гордятся. В понятие "написал", разумеется, вкладывается колбасение изолированного кода, не связанного никаким окружением, практически без какого-либо предварительного проектирования, и с отладкой его на паре основных тест-кейсов, без учета каких-либо граничных условий.
Ибо молодому программисту, на самом-то деле, не интересно ловить не только чужие, но и свои собственные баги. Ему интересно творить. Думать ему перед написанием кода тоже не особо интересно, ибо написание кода ему в новинку, представляет собой для него бешеный креатив, и поэтому кода пишет он много. И написание кода ему нириально доставляет. В отличии от отладки, диагностики проблем, написания документации. И конечно, тягостных раздумий о том, как написать меньше кода, и чтобы в нем было поменьше проблем, а не побольше. Последнее для него совершенно противоестественно. Так уж он устроен, молодой программист.
"Молодость" программиста, впрочем, есть скорее состояние души, чем стаж в индустрии или физиологический возраст. Пионер, он, как известно, всегда остается пионером, и он всегда готов!
Эх, пнимаешь, молодость. :) И не надо мне говорить, что вы не были такими :). Я конечно же охотно верю, что вы потратили на предварительное проектирование своей первой программы не менее 30% времени, что вы покрыли ее как white box, так и black box тестами, учтя граничные условия и обеспечив хорошее покрытие, а потом - конечно же аккуратно задокументировали результат :). Я допускаю даже, что вы были лишены искренней радости от наблюдения того, что вы по сути наблюдаете маленькое чудо, что ваша программа работает на паре тестовых кейсов. И что эта радость отнюдь не была вашей первой мотивацией к тому, чтобы программировать, и вы с самого начала делали это уныло и "промышленно". :)
Это, в сущности, прекрасно, и ничего плохого в этом нет. Дело однако в том, что цель и реальность промышленного программирования немного другая. За программу должны заплатить деньги те люди, чью потребность она удовлетворяет. Это никак не конфликтует с целью получения удовольствия от программирования, даже напротив, факт того, что результат нашего труда людям полезен, и они его ценят - также нириально доставляет.
Однако, проблема в том, что эти странные люди вовсе не разделяют нашу радость от работоспособности программы на основном кейсе. Более того, они:
1) негодуют по поводу неожиданных багов, возникающих в самых неожиданных местах. Они, сцуки, так неожиданно нашу программу используют!
2) и кроме того, они хотят от нас новых фич, и новых кейсов! Они хотят, чтобы программа умела больше, и далала все лучше! Постоянно хотят, ссуки!
Здесь и состоит загвоздка. Реальность промышленного программирования состоит в том, что любой коммерчески успешный (читай - удачный, нужный людям) проект достаточно быстро выходит из фазы первой версии, и превращается в то, что молодые программисты называют "поддержкой". А на самом деле - является не только поддержкой, но и развитием.
Плохие, негодные проекты никогда не доходят до этой фазы, мои уважаемые коллеги. :) Ибо суть они унылое ни кому не нужное говно, вызывающее зевоту у пользователей. И чем более удачен и успешен проект, тем ДОЛЬШЕ он будет находится в состоянии поддержки и развития. "Поддержка" - это признание. И при поддержке хорошего продукта, его приходится развивать. Добавляя к нему фичи.
То есть, ВСЕ успешные проекты быстро попадают в поддержку, таким образом, БОЛЬШИНСТВО проектов по факту делаются по смешанному циклу - поддержка и развитие. То есть, они развиваются ИНКРЕМЕНТАЛЬНО, в них постоянно правятся дефекты, и добавляется большое количество новых фич. Вероятность "попасть на поддержку" для молодого программиста, таким образом, крайне высока. Как не прискорбно это признать. :)
Удивительно, кстати, что традиционное "управление проектами" уделяет столь мало внимания этому жизненному факту, являющемуся кроме всего прочего признаком успеха продуктовой компании в нашей индустрии, концентрируясь на новых проектах "с чистого листа". Надо уметь управляться в той реальности, в которой мы живем, не так ли? Однако, в этот раз я хочу рассказать не об управлении разработкой при цикле "поддержка и развитие", а о том, что данная реальность вовсе не так тягостна для молодых программистов, как им кажется.
Дело в том, что писать код - это не самое большое удовольствие. Это ерунда, слабенькое средство, от которого торкает не так сильно. Истинное удовольствие, гораздо более сильное, и подсев на которое, сложно слезть - кроется именно в нелюбимой ими "поддержке".
Да вот взять хотя бы меня. Проработав 6 лет в цикле поддержки и развития, и будучи "чистым" менеджером последние 4 года, единственное, мимо чего я не могу пройти спокойно мимо - это когда парни, матерясь, ловят злую багу! Волной накатывает охотничий азарт, и я сразу понимаю, как же я по этому соскучился! :)
Вы смотрели сериал "доктор Хаус"? Вы читали детективы про Шерлока Холмса? Значит, вы можете понять, на что похожа лобля багов, уважаемые коллеги. И на кого похож профессионал в этом деле. Холмс, как вы догадались?! - Это элементарно, Ватсон. Для человека, владеющего дедукцией, не составит труда понять, что Вы прибыли именно из Афганистана. Без всяких в жопу логов, отладчиков, и прочей ерунды. :)
Да что аллегории, расскажу одно из последнего. Сейчас я один из руководителей разработки микросхемы-процессора для цифровых телевизионных приставок. Баги, соответственно, у нас а) злые, программно-аппаратные, и б) чрезвычайно красивые, ибо заключаются, например, в артефактах на картике на телевизоре высокой четкости. Мимо такого бага истинный их ценитель равнодушно пройти не сможет никак :).
Короче, парни впервые подключают телевизор, и на нем наблюдаются, помимо картинки, случайно расположенные мерцающие белые точки. Черт знает что. Непронятно, где бага, учитывая, что печатные платы, шлейфы, сам видеоконтроллер в микросхеме, и драйвер к нему - все это дело наших рук. Багу ловило человека 3. Перед телевизором постоянно сидело трое, и задумчиво смотрело на точки. Иногда кто-то что-то мерял осциллографом.
Собственно, мимо такого пройти совершенно невозможно, хоть я и не микроэлектронщик, а программист, и я подключился к расследованию. Драйвер мы исключили сразу. Оставалось понять, проблема цифровая, или аналоговая. Сначала мне удалось установить систему в расположении белых точек - они определялись цветовым паттерном точек вокруг. Что было уже прикольно, заподозрили шлейф и аналоговую багу.
Потом, один из аппаратчиков отключил питание платы с трансивером (внешняя плата формирователя телесигнала, не наша), и я, будучи единственным, кто в данный момент смотрел на экран (парни смотрели на плату и на монитор), заметил, что изображение почему-то не пропало, зато белых точек стало больше.
Это был подарок, ибо любой человек, владеющий дедукцией, поймет, что плата работает при отключенном питании не чудом, а получая его с USB с подключенного компа, которое у нас (кажется) 3.3 вольта, а 5 как от родного блока питания, что понижает уровень единицы, и, соответственно, мы однозначно заключаем, что белые точки появляются из-за того, что "гуляет" уровень единицы в шлейфе. Что объясняет их мерцание, и все эффекты.
Осталось понять, почему это происходит. То-ли и-за рассогласованного питания на двух платах (земля общая, но питание разное), или из-за наводок в шлейфе, в котором провода не проложены через один землей, или... из-за внешней наводки, что в данном случае настолько невероятно, что данный вариант никому не пришел в голову. Уже можно пробовать укоротить шлейф, и это с высокой вероятностью поможет. Но это долго.
Один из аппаратчиков решил проверить, как влияет картинку наводка на кабель, положив мобильник на кабель, и позвонив на него. Он, собственно, хотел создать наводку. У него ничего не получилось. В этот момент я опять внимательно смотрел на экран, и заметил, что ТОЧЕК СТАЛО ЧУТЬ-ЧУТЬ МЕНЬШЕ, с мобильником лежащим на кабеле! А не больше! Что говорит нам дедукция? Правильно, это означает наличие ВНЕШНЕЙ наводки, ибо мобильник экранирует собой маленький участок шлейфа!
Я хватаю с полки компакт-диск (внутри компакт-дисков есть слой металла), и кладу сверху шлейфа - и точек становится СИЛЬНО меньше! Тут я, приходя в крайнее волнение, говорю - "нужна фольга! У кого-нибудь есть шоколадка? А, у Вити есть, я помню, он ел ее утром", - и убегаю в соседнюю комнату.
- Влад, тебе надо спокойнее относиться к работе, - улыбаясь говорит мне вслед Женя, руководитель группы мультимедиа.
- Витя, где твоя шоколадка?! Я видел, утром она у тебя была.
- Съел, - подозрительно смотрит на меня Витя.
- Отдай мне фольгу! - я вытаскиваю смятую фольгу из мусорной корзины.
- В чем дело-то?
- Мы ту злую багу поймали, прикинь?! Внешняя наводка на шлейф! Надо в фольгу завернуть!
- Сейчас, подожди, я тебе другой фольги дам, у меня еще шоколадка есть!
- Да какая разница! Догоняй!
Возвращаюсь с фольгой, и заворачиваю в нее кабель. Точки исчезают полностью. Мы видим идеальную картинку.
- Хренассе, откуда это здесь такая наводка? - поражаются аппаратчики.
- Да черт его знает! Интересно, как в этих условиях вообще хоть что-то работает! Надо все нахрен заэкранировать!
- Я же говорил, это аналоговая проблема, - лениво заключает Гоша (руководитель другой группы микроэлектроники, зашедший посмотреть, как соседняя группа полным составом ловит такую зычную и диковинную багу) - а ты, Влад, по-моему, не тем занимаешься :). Тебе лаборантом надо работать, а не менеджером :).
- Шесть лет на поддержке даром не проходят, Гоша! - говорю я, - Рефлексы остались, ничего не могу с собой поделать. Ну что, парни, я разливаю коньяк. Ибо есть повод.
Витя медленно, с достоинством несет идеально отглаженную фольгу от второй своей шоколадки, ребята заворачивают в нее шлейф, и аккуратно заматывают его скотчем. Так оно и работает до сих пор. :)
- Первый созданный в России видеоконтроллер телевидения высокой четкости, наконец, заработал, и дал на настоящий телевизор чистую картинку, - говорю я, включая видеозапись, - Слово предоставляется главному конструктору видеоконтроллера, руководителю группы мультимедиа, кандидату технических наук, Евгению Янкевичу.
- Гхм! - важно говорит Женя в видеокамеру, поправляя очки - Инопланетный разум, пнимаете-ли, передавал на наш макет свои сигналы, препятствуя испытаниям последних образцов отечественной микроэлектроники. Однако, в сжатые сроки нашими учеными было разработано специальное покрытие для шлейфа, - Женя демонстрирует шлейф обмотанный фольгой камере, - которое надежно защищает макет от сигналов инопланетного разума. Очередная попытка инопланетного разума помешать прогрессу Российской науки в очередной раз пресечена! Ура, товарищи! Выпьем за триумф Российской науки!
Вот как много удовольствия приносит процесс ловли багов. :) Собственно, говоря серьезно, этот баг парни нашли бы и без меня, несколько позже. :) Как они без меня устранили множество других, не менее, а более тяжелых, и трудноуловимых ошибок. Это я бы без них не справился. Но свою дозу экстаза в данном случае я получил. :)
В ловле багов доставляет не только результат, но и сам процесс. И это требует охрененно большой компетенции и практики. Интуиции и наблюдательности. Логики и умения делать выводы. Внимания к мелочам, и одновременно умения абстрагироваться от них. Знаний принципиальных закономерностей, и понимания архитектуры. Умения читать код, и умения его писать. Умения проективать в голове вообще необходимо - это, как ни парадоксально, помогает _читать_ код, и диагностировать ошибки.
Короче, диагностика ошибок, это такое занятие, которое требует ВСЕХ умений сразу. Когда вы начнете получать удовольствие от диагностики ошибок, и в особенности - в чужом коде, это будет признаком того, что вы становитесь настоящим профессионалом. Как доктор Хаус.
Не бойтесь поддержки. Не работая на поддержке, сложно стать хорошим инженером. И главное, отказываясь работать на поддержке, вы лишаете себя огромной порции удовольствия, достойного настоящих гурманов :).