Я нахожу совершенно удивительной невозмутимость, с которой мировое сообщество программистов приняло этого нотационного монстра (Н. Вирт).
Представьте себе, что такое занятие, как программирование получило официальный статус «Искусство». На сегодняшний день, занимаясь очередной прикладной программой или web-порталом программист не решает тех проблем, которые решал бы еще 5-10 лет назад. Очевидно? Факт? С повсеместным приходом доступных кросс-платформенных технологий, производительных вычислительных ресурсов, скоростных электронно-вычислительных сетей, пришла повсеместная расслабленность в профессиональных кругах. Проблеме оценки программного кода посвящено немало литературы, различные методы свертки и единицы измерения качества. Я же хочу остановиться на почти незаметном, практически неощутимом — красоте программного кода.
Мы легко можем выделить красивую вещь, обратить внимание на изящную страницу в сети, оценить прелесть нового спорт-кара. Занимаясь групповой разработкой программного обеспечения, зачастую можно выделить «неплохого программиста» и «школьника-домохозяйку». Что же будет являться критериями оценки красоты программного кода? Можно ли попробовать систематизировать наши понимания в этой области, несмотря на то, что большая их часть находится на стороне эмоций и чувств?
Оценку красоты любого объекта, по-моему мнению, следует проводить системно, а именно, рассматривая не только сам объект и сопоставляя его с неким идеалом (оптимумом, как это принято в теории оптимизации), но и ряд сопряженных с ним вещей. Для программного кода можно выделить:
Рассмотрением первых двух аспектов, в этой статье пренебрежем, оставив постановку задачи заказчикам и аналитикам, а выбор алгоритмов решения теоретикам-физикам-ядерщикам. Основное внимание в свою очередь, предлагаю все же, сконцентрировать на рассмотрении и выбор средств и инструментов реализации любезно составленных нам алгоритмов. Тут-то и начинается самое интересное. Допустим, что нас никто не ограничивает в выборе любимого языка, IDE, библиотек, да что там, даже платформу подгонят под наше ПО, а что дальше? Большинство разработчиков — узкие специалисты и спасибо им за это, но все же, приходя к решению определенной задачи необходимо опираться на заточенность средств, а не своих убеждений. «Студентов, ранее изучавших Бейсик, практически невозможно обучить хорошему программированию. Как потенциальные программисты они подверглись необратимой умственной деградации», сказал Дейкстра и, наверное был прав, не знаю, мне не приходилось преподавать программирование, но в его фразе хорошо раскрыта тема несоответствия языка и задачи обучения. Так черт возьми, надо ли уметь копать вилкой, когда есть лопата? А если рядом стоит бульдозер, зачем вообще пачкать руки?
Я верю в то, что у всего создаваемого есть своя причина. Создавая такой сложный механизм, как язык программирования, авторы, будь они хоть люди, хоть роботы, опираются на причины, подвигнувшие их на это весьма трудоемкое мероприятие. Отсюда задача разработчика, на мой взгляд, уметь оценить имеющиеся продукты, понимать причины их создания и осознавать свои задачи и сопоставлять эти самые задачи с теми причинами, ради которых авторы языков делали свои разработки. Нет и не будет универсального языка программирования, нет и не будет универсального программиста. Красота реализации кода, как в любом языке (имею ввиду и натуральные) достигается непрерывной практикой, тут никакого секрета нет. Искусство — писать масляную картину кистью, уметь это делать и, что немало важно, достойно оформить ее в подходящем месте. Представьте себе шикарную клумбу с живыми цветами, красиво? А что, если эта клумба стоит в неблагополучном районе где-то на окраине мегаполиса, рабочий квартал, темень, грязь, разбитые дороги и пьяные бомжи? Выходит, что программирование (в узком понимании — кодинг) не самоцель, отнюдь. Рассматривая решение проблемы как комплекс можно увидеть красоту или ее отсутствие.
Мне кажется, что люди должны понимать, что красота элемента никогда не сравниться с красотой композиции и только системный анализ способен хотя бы немного приблизить нас к объективности. Никлаус Вирт рассуждая о конструкциях языка Си, решал проблему синтаксического анализатора, вряд ли поэт-песенник, оценил бы созданный самим Виртом (почитаемый мной как лучший язык обучения) Паскаль.
Представьте себе, что такое занятие, как программирование получило официальный статус «Искусство». На сегодняшний день, занимаясь очередной прикладной программой или web-порталом программист не решает тех проблем, которые решал бы еще 5-10 лет назад. Очевидно? Факт? С повсеместным приходом доступных кросс-платформенных технологий, производительных вычислительных ресурсов, скоростных электронно-вычислительных сетей, пришла повсеместная расслабленность в профессиональных кругах. Проблеме оценки программного кода посвящено немало литературы, различные методы свертки и единицы измерения качества. Я же хочу остановиться на почти незаметном, практически неощутимом — красоте программного кода.
Задача
Мы легко можем выделить красивую вещь, обратить внимание на изящную страницу в сети, оценить прелесть нового спорт-кара. Занимаясь групповой разработкой программного обеспечения, зачастую можно выделить «неплохого программиста» и «школьника-домохозяйку». Что же будет являться критериями оценки красоты программного кода? Можно ли попробовать систематизировать наши понимания в этой области, несмотря на то, что большая их часть находится на стороне эмоций и чувств?
Тезис
Оценку красоты любого объекта, по-моему мнению, следует проводить системно, а именно, рассматривая не только сам объект и сопоставляя его с неким идеалом (оптимумом, как это принято в теории оптимизации), но и ряд сопряженных с ним вещей. Для программного кода можно выделить:
- решаемая задача
- алгоритм решения
- средства и инструменты реализации
- реализация (сам код)
- всевозможные взаимодействия перечисленных элементов.
Рассмотрением первых двух аспектов, в этой статье пренебрежем, оставив постановку задачи заказчикам и аналитикам, а выбор алгоритмов решения теоретикам-физикам-ядерщикам. Основное внимание в свою очередь, предлагаю все же, сконцентрировать на рассмотрении и выбор средств и инструментов реализации любезно составленных нам алгоритмов. Тут-то и начинается самое интересное. Допустим, что нас никто не ограничивает в выборе любимого языка, IDE, библиотек, да что там, даже платформу подгонят под наше ПО, а что дальше? Большинство разработчиков — узкие специалисты и спасибо им за это, но все же, приходя к решению определенной задачи необходимо опираться на заточенность средств, а не своих убеждений. «Студентов, ранее изучавших Бейсик, практически невозможно обучить хорошему программированию. Как потенциальные программисты они подверглись необратимой умственной деградации», сказал Дейкстра и, наверное был прав, не знаю, мне не приходилось преподавать программирование, но в его фразе хорошо раскрыта тема несоответствия языка и задачи обучения. Так черт возьми, надо ли уметь копать вилкой, когда есть лопата? А если рядом стоит бульдозер, зачем вообще пачкать руки?
Причины, задачи, понятия
Я верю в то, что у всего создаваемого есть своя причина. Создавая такой сложный механизм, как язык программирования, авторы, будь они хоть люди, хоть роботы, опираются на причины, подвигнувшие их на это весьма трудоемкое мероприятие. Отсюда задача разработчика, на мой взгляд, уметь оценить имеющиеся продукты, понимать причины их создания и осознавать свои задачи и сопоставлять эти самые задачи с теми причинами, ради которых авторы языков делали свои разработки. Нет и не будет универсального языка программирования, нет и не будет универсального программиста. Красота реализации кода, как в любом языке (имею ввиду и натуральные) достигается непрерывной практикой, тут никакого секрета нет. Искусство — писать масляную картину кистью, уметь это делать и, что немало важно, достойно оформить ее в подходящем месте. Представьте себе шикарную клумбу с живыми цветами, красиво? А что, если эта клумба стоит в неблагополучном районе где-то на окраине мегаполиса, рабочий квартал, темень, грязь, разбитые дороги и пьяные бомжи? Выходит, что программирование (в узком понимании — кодинг) не самоцель, отнюдь. Рассматривая решение проблемы как комплекс можно увидеть красоту или ее отсутствие.
Вывод
Мне кажется, что люди должны понимать, что красота элемента никогда не сравниться с красотой композиции и только системный анализ способен хотя бы немного приблизить нас к объективности. Никлаус Вирт рассуждая о конструкциях языка Си, решал проблему синтаксического анализатора, вряд ли поэт-песенник, оценил бы созданный самим Виртом (почитаемый мной как лучший язык обучения) Паскаль.
