special faq

Спецвыпуск: Хакер, номер #071, стр. 071-088-2

Q:

Как устроиться на хорошую работу в России и за рубежом?

A:

Из двух работ лучшей будет та, которая больше нравится тебе. Отсюда следует, что работу нужно искать в соответствии со своими предпочтениями, при этом не пытаясь навязывать эти предпочтения другим. Если на такой-то фирме используется преимущественно DELPHI, глупо пытаться втиснуться туда, зная один лишь Си или Ассемблер. Знания чего бы то ни было при трудоустройстве вообще вторичны. Первично умение себя подать. Матчасть здесь отдыхает, а body language очень рулит. Основная ошибка начинающих — перечисление в резюме огромного перечня языков, сред программирования, операционных систем и библиотек, с которыми они как бы умеют работать. А работодателю на фиг не нужен программист-универсал, по чуть-чуть нахватавшийся всего. Ему нужен как раз человек, знающий свою узкую предметную область, но знающий ее глубоко. К тому же не так важно, сколько программ ты написал, - важнее, сколько из них ты поддерживаешь в настоящий момент.

Q:

Почему большинство программистских проектов проваливаются?

A:

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

Q:

Рефракторинг — бузворд или серебряная пуля?

A:

Существует мнение, что если код не поддерживает автоматическое тестирование, то это отстой, и что перманентный рефракторинг — залог успеха. На самом же деле, сложность тестирующих модулей зачастую в разы превосходит сложность тестируемого ими кода, к тому же тестирующие модули нужно тоже как-то тестировать, а это уже бесконечная рекурсия получается. Существует определенная граница сложности, ниже которой автоматическое тестирование кода экономически неоправданно. А системы, взаимодействующие с внешней средой, могут быть протестированы в автоматическом режиме, только если мы создадим программный эмулятор этой самой среды, который, в свою очередь, тоже будет нуждаться в тестировании. Как разорвать этот замкнутый круг? Разбивать код на множество мелких модулей, каждый из которых будет настолько прост, насколько это вообще возможно. Тестирование модулей при этом значительно упрощается, но резко возрастает количество связей между модулями и, как следствие, появляются ошибки в их взаимодействии. Более того, модульная структура сама по себе гораздо более сложная, чем монолитная. Так что выводы неутешительны. Серебряных пуль нет, качество программного обеспечения по-прежнему остается низким и радикальных прорывов в этой области не наблюдается. Это не значит, что рефракторинг бесполезен, это значит, что он должен применяться с умом.