prg-f

FAQ по программированию

крис касперски ака мыщъх, ака nezumino-email

Q: какие языки программирования следует изучать в первую очередь?

A: важен не сам язык, а мысли, которые этим языком выражают, практически любую алгоритмическую задачу можно решить на любом языке (за какое время и с какой эффективностью — это уже другой вопрос), поэтому, неважно с какого языка начинать (все равно за время его изучения он успеет устареть) и следует выбирать тот язык, для которого есть хорошие учебники по программированию, а так же знакомые специалисты, способные проконсультировать и помочь если вдруг что-то пойдет не так, ведь язык это не только способ записи алгоритма, но еще и средство общения! в этом качестве языку Си — нет равных и defacto он стал международным стандартом типа английского. знать его нужно, не только затем, чтобы на нем программировать, но и понимать листинги, приведенные в книгах, посвященным сетевым протоколам или устройству осей. VisualBasic – defacto стандарт в области макроязыков на платформе Windows и без знания с ним невозможно эффективно работать с MicrosoftVisualStudio, но Basic совершенно чужд миру UNIX, где ведущую роль играют Perl, AWK и другие скриптовые языки. но, если человек, может решить свою задачу на языке Х, перейти на другой язык для него не станет проблемой.

Q: стоит ли хвататься за новые технологии типа .NET или держаться старых?

A: отечественная система образования до безобразия консервативна и крайне неохотно реагирует на новые технологические веяния и прорывы, поэтому, в 99% случаев выпускник ВУЗа к реальной работе не готов и ему следует еще учиться и учиться, а все потому, что у нас традиционно учили фундаментальным основам. американцы, напротив, делают упор на конкретное практическое применение, и девушки, окончившие 2х недельные курсы по VisualBasic'у уже составляют определенную конкуренцию специалистам, знающим Си++, потому что в курсе того, какие есть библиотеки и как ими пользоваться, но! создать их самостоятельно не в состоянии. все, что они могут — это сложить готовые компоненты воедино (а другого, зачастую и не требуется). алгоритмически-ореентированный программист готов запрограммировать, что угодно но… он совершенно не в курсе какие существуют библиотеки и не умеет с ними работать. поэтому, при решении типовых задач, наиболее конкурентоспособным оказывается программист, идущий в ногу с прогрессом и осваивающий новые библиотеки и framewaork'и по мере их появления, а вот при решении нетипичных задач, программисты, знающие фундаментальные основы получают _огромное_ преимущество. некоторые ухитряются совмещать оба качества, но это удается лишь немногим.

Q: насколько важно знать ассемблер?

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

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

A: главное — просто шевелить хвостом, неважно даже в каком направлении. из двух работ лучшей будет та, которая больше нравится вам. отсюда следует, что работу следует искать в соответствии со своими предпочтениями, при этом, не пытаясь навязывать эти предпочтения другим. в чужую хату со своим хвостом не ходят и если на такой-то фирме используется преимущественно DELPHI, глупо пытаться втиснуться туда, зная один лишь Си или Ассемблер. знания чего бы то ни было при трудоустройстве вообще _вторичны_ !!! первично — умение себя подать! мат. часть здесь отдыхает, а bodylanguage очень рулит. вот две основные ошибки начинающих — перечисление в резюме огромного перечня языков, сред программирования, операционных систем и библиотек с которыми они как бы умеют работать (нанимателю не нужен программист-универсал, по чуть-чуть нахватавшийся всего, ему нужен человек, знающий свою предметную область, но знающий ее глубоко), еще — не так важно сколько программ вы написали, как сколько из них вы поддерживаете в настоящий момент.

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

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

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

A: существует мнение, что если код не поддерживает автоматическое тестирование, то это отстой и что пермаментный рефракторинг — залог успеха. на самом же деле… сложность тестирующих модулей зачастую в разы превосходит сложность тестируемого ими кода, к тому же тестирующие модули нужно тоже как-то тестировать, а это уже бесконечная рекурсия получается. существует определенная граница сложности, ниже которой автоматическое тестирование кода экономически неоправданно, а системы, взаимодействующие с внешней средой, могут быть протестированы в автоматическом режиме только если мы создадим программный эмулятор этой самой среды, который в свою очередь будет нуждаться в тестировании. как разорвать этот замкнутый круг? разбивать код на множество мелких модулей, каждый из которых будет настолько прост, насколько это вообще возможно. тестирование модулей при этом значительно упрощается, но резко возрастет количество связей между модулями и, как следствие, появляются ошибки в их взаимодействии, более того, модульная структура сама по себе гораздо более сложная, чем монолитная. так что, выводы неутешительны. серебренных пуль нет. качество программного обеспечения по прежнему остается низким и радикальных прорывов в этой области не наблюдается. это не значит, что рефракторинг бесполезен, это значит, что он должен применяться с умом.

Q: как защититься от хакеров?!

А: хакеры ломают все, что трассируется (а что не трассируется то дизассемблируется) и надеяться, что выбранная системы остановит их, может только идеалист. хакеры существуют — это факт и развивать свой бизнес, игнорируя краки, все равно что вести строительство в сибири из расчета, что лето никогда не закончится и температура всегда будет держаться выше нуля. если ваша программа — продукт, вы — покойник. если же ваша программа — услуга, хакеры идут лесом, поскольку «взломать» _услугу_ нельзя. следовательно, нужно развивать он-лайновые службы, организовывать обучающие семинары, ориентироваться на комплексные решения (где сама программа всего лишь часть большой бизнес-машины и сама по себе лишена смысла). допустим, вы написали такую _простейшую_ штуку как каталогизатор аудио-дисков. а теперь прикрутите к нему ог-лайновую службу, позволяющую пользователями обмениваться своими базами данных (если один человек «вбил» описание дисков в базу, на хрена тысячам других делать то же самое?!), затем начинайте привлекать лейблов (или просто магазины, торгующие дисками), предоставив им возможность информировать пользователей о новинках и вести мониторинг реальной популярности своей продукции. в этом случае, основным источником прибыли окажутся именно лейблы и прибыль будет тем выше, чем больше у вас пользователей, а для этого программа должна распространятся бесплатно. но, даже, если она платна, то взломать ее все равно очень и очень сложно, поскольку основную ценность составит онлайновая база данных, доступ к которой легко контролировать, отправив хакеров отдыхать!