Узкая специализация ведет к потере навыков программирования ?

[Zhek@Ch]

На страницах издания IT World рассмотрена проблема потери основополагающих навыков программирования в среде разработчиков современных высокоуровневых систем. Известная парадигма гласит: 'помни основы'. Программист должен знать принципы работы того уровня, на котором работает. Например, веб-программисту не нужно беспокоиться о машинном коде в который преобразуется его приложение, но он должен знать о работе сетевого стека, кэшировании, базах данных и т.п. Сегодня разработчики могут на скорую руку написать скрипт на PHP или расширение для Drupal. Однако есть множество фактов, которые не знают программисты нашего времени, но знали их предшественники. О том, нужны или нет подобные расширенные знания, и какие навыки необходимы каждому программисту, были заданы вопросы опытными и признанными разработчиками, несколько десятков лет работающими в индустрии разработки программного обеспечения. Перевод некоторых ответов представлен ниже.


[size="3"]Понимание как работает аппаратное обеспечение[/size]

 Bernard Hayes: "Процессор редко является узким местом, когда речь заходит о необходимости оптимизации производительности. Многие пытаются оптимизировать циклы для повышения производительности, в то время как часто на её уровень больше влияют проблемы ввода/вывода. Всё чаще люди перекладывают причины проблем на неполадки аппаратного обеспечения, абсолютно не понимая принципов его работы и последствий аппаратных ошибок."


[size="3"]Программирование не одно и тоже, что программная инженерия. [/size]

 Bernard Hayes: "Многие из новых разработчиков испытывают сложности в определении и понимании возможных зависимостей и их диагностики/отладке. Некоторые сторонники открытого кода приобретают этот навык, работая со сложными и взаимодействующими со многими подсистемами проектами, такими как MySQL. Но я не наблюдаю интуитивного ощущения компромисса между размером и производительностью в реализации алгоритмов. Мы живем во время больших объёмов памяти и высокоскоростных систем, поэтому многие проблемы программирования не столь заметны."

Chris De Herrera: "Похоже, структурное программирование уходит навеки, особенно благодаря таким компаниям как Facebook и Google. Они спонсируют проведение мозговых штурмов, принимая любые идеи, которые могут быть включены в их продукты. Я абсолютно уверен, что проектирование структурированного программного обеспечения определяет жизненный цикл разработки и критичность к повторному использованию и безопасному проектированию."

Kris Rudin: "Одним из 'утерянных навыков' я вижу отладку без встроенного отладчика. Когда я начинал программировать, у нас не было интегрированных сред разработки и отладчиков, и мы вставляли операторы трассировки в код для отслеживания значений и слежения за выполнением программы. Если же сегодня молодые программисты не могут использовать встроенный отладчик, они теряются и пытаются исправить проблему наугад."


[size="3"]Никогда не популярно, но всегда полезно [/size]

 Suford Lewis: "Хорошим подходом является метод 'семь раз отмерь, один раз отрежь'. Множество раз я видел программное обеспечение, от одиночных программ до больших систем, разработанное с недостаточным вниманием к поставленной задаче. Исправление такого программного обеспечения сводится к удалению и изменению кода в различных местах, пока он не будет на вид работать правильно. Современные средства позволяют это делать так легко, что инженеры-программисты дольше пытаются понять, что же является проблемой. Данный подход можно охарактеризовать как 'некогда делать правильно, но есть время переделать'. Он всегда дольше. Сложно, но нужно противостоять давлению говорящих: 'Почему ещё не готово?'"

 Paula Lieberman: "Одной из ужасных ошибок инженеров программного обеспечения и программистов я вижу отсутствие обработки исключений и тщательного проектирования. Многие разработчики, далекие от компьютерной безопасности, редко задумываются о том, что будет если пользователь сделает ошибку или намеренно попытается сломать их программу. Кроме того, разработчики сейчас почти не используют блок-схемы, которые наглядно показывали, что нужно сделать. В отличие от блок-схем, список требований не покажет взаимозависимость и сочетаемость идей."


[size="3"]Работа с сетью[/size]

 Ben Summers: "Навыки, приобретенные при написании сетевых приложений во времена модемов на 14400 довольно полезны и сегодня. Когда скорость составляет несколько килобайт в секунду, а задержки сотни миллисекунд, приходится задумываться о минимизации размера передаваемых страниц, и что не менее важно, о минимизации передаваемой в обе стороны информации. Сегодня задержки в мобильных каналах связи бывают выше, чем в модемном соединении, что усугубляется процентом ошибок из-за взаимных помех в густонаселенных городских центрах. Скоростные широкополосные соединения как правило мало влияют на скорость взаимодействия с веб-приложениями, задержки в основном обусловлены производительностью самих web-приложений. Задержка определяет ощущение длительности ответа, и использованные ранее в телефонных модемах приемы здесь становятся чрезвычайно полезными."


[size="3"]Предчувствие ошибок[/size]

 Bernard Hayes: "Уши сегодняшних технарей глухи к ошибкам. Я не вижу осознания системных звуков компьютера или электронного оборудования, их связи с риском ошибки или поломки. Я чувствителен к странным звукам, издаваемым оборудованием. Около 6 месяцев назад я услышал, что мой 4-летний диск в 8-летнем ноутбуке начал постукивать, и предусмотрительно сделал копии данных. Поэтому я не был слишком шокирован его поломкой двумя неделями позднее."


[size="3"]Отдельные средства, знания которых не хватает [/size]

 Jude Miller: "Не хватает знания ассемблера, обработки прерываний, понимания состояния гонки и когерентности кэша".

Pete Kaiser: "Наблюдается низкий уровень общего развития. Многие из 'экспертов', о которых я слышал в прессе, кажутся слишком узконаправленными. Я читал о людях, знающих всё об API для Microsoft Windows VSS, но не имеющих понятия о журналируемых файловых системах. Или тех, кто советует купить больше оперативной памяти для сервера, но не понимает архитектурных принципов, из-за которых в некоторых задачах система Linux с 4 Гб памяти может превзойти по производительности Windows с 16 Гб. Они в восторге от интерфейса Aero от Microsoft для Windows, но не имеют понятия о том, как мало изменилось в концепции GUI с 1980-х. Поэтому они не знают куда двигаться дальше или чего стоит сторониться."

# opennet.ru