Различия

Здесь показаны различия между двумя версиями данной страницы.

Ссылка на это сравнение

articles:prg-f [2017/09/05 02:55] (текущий)
Строка 1: Строка 1:
 +====== prg-f ======
 +<​sub>​{{prg-f.odt|Original file}}</​sub>​
 +
 +====== 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****:​**** ****как защититься от хакеров?​!**
 +
 +**А:​** хакеры ломают все, что трассируется (а что не трассируется то дизассемблируется) и надеяться,​ что выбранная системы остановит их, может только идеалист. хакеры существуют — это факт и развивать свой бизнес,​ игнорируя краки, все равно что вести строительство в сибири из расчета,​ что лето никогда не закончится и температура всегда будет держаться выше нуля. если ваша программа — продукт,​ вы — покойник. если же ваша программа — услуга,​ хакеры идут лесом, поскольку "​взломать"​ _услугу_ нельзя. следовательно,​ нужно развивать он-лайновые службы,​ организовывать обучающие семинары,​ ориентироваться на комплексные решения (где сама программа всего лишь часть большой бизнес-машины и сама по себе лишена смысла). допустим,​ вы написали такую _простейшую_ штуку как каталогизатор аудио-дисков. а теперь прикрутите к нему ог-лайновую службу,​ позволяющую пользователями обмениваться своими базами данных (если один человек "​вбил"​ описание дисков в базу, на хрена тысячам других делать то же самое?​!),​ затем начинайте привлекать лейблов (или просто магазины,​ торгующие дисками),​ предоставив им возможность информировать пользователей о новинках и вести мониторинг реальной популярности своей продукции. в этом случае,​ основным источником прибыли окажутся именно лейблы и прибыль будет тем выше, чем больше у вас пользователей,​ а для этого программа должна распространятся бесплатно. но, даже, если она платна,​ то взломать ее все равно очень и очень сложно,​ поскольку основную ценность составит онлайновая база данных,​ доступ к которой легко контролировать,​ отправив хакеров отдыхать!
 +
 +