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

[rssbot]

На страницах издания IT World рассмотрена проблема потери основополагающих навыков программирования в среде разработчиков современных высокоуровневых систем. Известная парадигма гласит: 'помни основы'. Программист должен знать принципы работы того уровня, на котором работает. Например, веб-программисту не нужно беспокоиться о машинном коде в который преобразуется его приложение, но он должен знать о работе сетевого стека, кэшировании, базах данных и т.п. Сегодня разработчики могут на скорую руку написать скрипт на PHP или расширение для Drupal. Однако есть множество фактов, которые не знают программисты нашего времени, но знали их предшественники. О том, нужны или нет подобные расширенные знания, и какие навыки необходимы каждому программисту, были заданы вопросы опытными и признанными разработчиками, несколько десятков лет работающими в индустрии разработки программного обеспечения. Перевод некоторых ответов представлен ниже. Понимание как работает аппаратное обеспечение Bernard Hayes: "Процессор редко является узким местом, когда речь заходит о необходимости оптимизации производительности. Многие пытаются оптимизировать циклы для повышения производительности, в то время как часто на её уровень больше влияют проблемы ввода/вывода. Всё чаще люди перекладывают причины проблем на неполадки аппаратного обеспечения, абсолютно не понимая принципов его работы и последствий аппаратных ошибок." Программирование не одно и тоже, что программная инженерия. Bernard Hayes: "Многие из новых разработчиков испытывают сложности в определении и понимании возможных зависимостей и их диагностики/отладке. Некоторые сторонники открытого кода приобретают этот навык, работая с со сложными и взаимодействующими со многими подсистемами проектами, такими как MySQL. Но я не наблюдаю интуитивного ощущения компромисса между размером и производительностью в реализации алгоритмов. Мы живем во время больших объёмов памяти и высокоскоростных систем, поэтому многие проблемы программирования не столь заметны." Chris De Herrera: "Похоже, структурное программирование уходит навеки, особенно благодаря таким компаниям как Facebook и Google. Они спонсируют проведение мозговых штурмов, принимая любые идеи, которые могут быть включены в их продукты. Я абсолютно уверен, что проектирование структурированного программного обеспечения определяет жизненный цикл разработки и критичность к повторному использованию и безопасному проектированию." Kris Rudin: "Одним из 'утерянных навыков' я вижу отладку без встроенного отладчика. Когда я начинал программировать, у нас не было интегрированных сред разработки и отладчиков, и мы вставляли операторы трассировки в код для отслеживания значений и слежения за выполнением программы. Если же сегодня молодые программисты не могут использовать встроенный отладчик, они теряются и пытаются исправить проблему наугад." Никогда не популярно, но всегда полезно Suford Lewis: "Хорошим подходом является метод 'семь раз отмерь, один раз отрежь'. Множество раз я видел программное обеспечение, от одиночных программ до больших систем, разработанное с недостаточным вниманием к поставленной задаче. Исправление такого программного обеспечения сводится к удалению и изменению кода в различных местах, пока он не будет на вид работать правильно. Современные средства позволяют это делать так легко, что инженеры-программисты дольше пытаются понять, что же является проблемой. Данный подход можно охарактеризовать как 'некогда делать правильно, но есть время переделать'. Он всегда дольше. Сложно, но нужно противостоять давлению говорящих: 'Почему ещё не готово?'" Paula Lieberman: "Одной из ужасных ошибок инженеров программного обеспечения и программистов я вижу отсутствие обработки исключений и тщательного проектирования. Многие разработчики, далекие от компьютерной безопасности, редко задумываются о том, что будет если пользователь сделает ошибку или намеренно попытается сломать их программу. Кроме того, разработчики сейчас почти не используют блок-схемы, которые наглядно показывали, что нужно сделать. В отличие от блок-схем, список требований не покажет взаимозависимость и сочетаемость идей." Работа с сетью Ben Summers: "Навыки, приобретенные при написании сетевых приложений во времена модемов на 14400 довольно полезны и сегодня. Когда скорость составляет несколько килобайт в секунду, а задержки сотни миллисекунд, приходится задумываться о минимизации размера передаваемых страниц, и что не менее важно, о минимизации передаваемой в обе стороны информации. Сегодня задержки в мобильных каналах связи бывают выше, чем в модемном соединении, что усугубляется процентом ошибок из-за взаимных помех в густонаселенных городских центрах. Скоростные широкополосные соединения как правило мало влияют на скорость взаимодействия с веб-приложениями, задержки в основном обусловлены производительностью самих web-приложений. Задержка определяет ощущение длительности ответа, и использованные ранее в телефонных модемах приемы здесь становятся чрезвычайно полезными." Предчувствие ошибок Bernard Hayes: "Уши сегодняшних технарей глухи к ошибкам. Я не вижу осознания системных звуков компьютера или электронного оборудования, их связи с риском ошибки или поломки. Я чувствителен к странным звукам, издаваемым оборудованием. Около 6 месяцев назад я услышал, что мой 4-летний диск в 8-летнем ноутбуке начал постукивать, и предусмотрительно сделал копии данных. Поэтому я не был слишком шокирован его поломке двумя неделями позднее." Отдельные средства, знания которых не хватает Jude Miller: "Не хватает знания ассемблера, обработки прерываний, понимания состояния гонки и когерентности кэша". Pete Kaiser: "Наблюдается низкий уровень общего развития. Многие из 'экспертов', о которых я слышал в прессе, кажутся слишком узконаправленными. Я читал о людях, знающих всё об API для Microsoft Windows VSS, но не имеющих понятия о журналируемых файловых системах. Или тех, кто советует купить больше оперативной памяти для сервера, но не понимает архитектурных принципов, из-за которых в некоторых задачах система Linux с 4 Гб памяти может превзойти по производительности Windows с 16 Гб. Они в восторге от интерфейса Aero от Microsoft для Windows, но не имеют понятия о том, как мало изменилось в концепции GUI с 1980-х. Поэтому они не знают куда двигаться дальше или чего стоит сторониться."


Источник: http://www.opennet.ru/opennews/art.shtml?num=31416


View the full article

[Aviator]

Абсолютно правильно.

[frp]

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

Ага, ага. Скажите это участникам кодфорсов, acmp, acm.timus.ru, прочих олимпиад по программирования, даже CodeJam-а, который не предъявляет столь жестких требований по времени. Это справедливо только для софта, который почти ничего не вычисляет (хотя таковыми и являются 90% веб-приложений и много десктопного софта).

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

Test-Driven Development не спасет программиста любого уровня?

Во всем остальном, особенно насчет сети, на 100% согласен.

[Bluetooth]

Ага, ага. Скажите это участникам кодфорсов, acmp, acm.timus.ru, прочих олимпиад по программирования, даже CodeJam-а, который не предъявляет столь жестких требований по времени. Это справедливо только для софта, который почти ничего не вычисляет (хотя таковыми и являются 90% веб-приложений и много десктопного софта).

Так в том-то и дело, что састо оптимизация по процу нужна на олмипиаде, а на практике больше нужны более другие оптимизации, о чем там и говорилось

[deadhead]

Так в том-то и дело, что састо оптимизация по процу нужна на олмипиаде, а на практике больше нужны более другие оптимизации,

энергоэкономичные решения чувствительны, помимо всего прочего, и к такго рода оптимизации.

[frp]

Так в том-то и дело, что састо оптимизация по процу нужна на олмипиаде, а на практике больше нужны более другие оптимизации, о чем там и говорилось smile.gif

энергоэкономичные решения чувствительны, помимо всего прочего, и к такго рода оптимизации.

Как бы есть главный принцип оптимизации - "не оптимизируй преждевременно". Если есть хоть капля времени, лучше написать "как получится", без особых оптимизаций, а потом прогнать профайлером и переписать тормозящие вещи (сразу будет видно, по какому критерию оптимизировать).

[drBatty]

Это справедливо только для софта, который почти ничего не вычисляет (хотя таковыми и являются 90% веб-приложений и много десктопного софта).

ВНЕЗАПНО: мои приложения в продакшене тратят кучу времени на сортировку. т.е. на вычисления. любопытно, что на i686 Intel® Celeron® D CPU 3.06GHz GenuineIntel всё заметно тормозит... Ну в продакшене оно летает конечно, там побыстрей процессоры, но всё равно...

кстати Дональд Кнут придерживается того-же мнения...

[deadhead]

Как бы есть главный принцип оптимизации - "не оптимизируй преждевременно".

Когда сталкиваются теория и практика, всегда побеждает практика.(с) Торвальдс, вроде как
Иногда критерии оптимизации довольно явны и следуют, как правило из ограничений, в этом случае не остается ничего другого как применять оптимизацию сходу. Пример? Системное ПО :-)

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

Если времени, как вы выразились, "капля", то на дальнейшее профилирование, видимо, времени не будет вообще:-)

[frp]

Иногда критерии оптимизации довольно явны и следуют, как правило из ограничений, в этом случае не остается ничего другого как применять оптимизацию сходу.

Очевидно, что если вы знаете, куда оптимизировать, то можно и нужно сразу. Но в новости упоминался случай, когда программисту неочевидно, в каком направлении оптимизировать.

Если времени, как вы выразились, "капля", то на дальнейшее профилирование, видимо, времени не будет вообще:-)

Напомнило: "У меня нет времени, чтобы улучшить эфективность моего труда, чтобы я мог сэкономить время." Критично только если счет идет на минуты (я знаю один такой случай - всякие там олимпиады, но там профайлер в 90% случаев и не нужен - и так все очевидно).

[deadhead]

Но в новости упоминался случай, когда программисту неочевидно, в каком направлении оптимизировать.

Ага, ввиду отсутсвия знаний... кстати, AFAIK такие эффеты как cache-thrashing и false-sharing профайлeром не отлавливаются ;-)