Красота кода
22.06.2014
|
Pauel
 |
Есть в разработке софта очень удобное слово — дизайн. Почему то большей частью люди понимают это слово как синоним личного комфорта, красоты. На мой взгляд это, мягко говоря, преступное заблуждение. Более того, лично я считаю, что красота в инженерном деле просто неуместна.
Красота вообще очень интересное слово. Как правило, люди понимают под ним каждый своё собственное. Как известно, в ИТ всё изобретается заново. Потому, что бы поговорить за красоту, нужно посмотреть чего же под ней понимают в других областях. Можно например, посмотреть что думают про красоту человеческого тела. Как ни странно, понятие красоты отражает точку зрения носителей некоторой общности. То есть, красота примерно как мода, везде разная, меняется со временем.
Хотя красота это непрактическая категория, тем не менее для практичности место есть. Например ассиметричность почти никогда не являлась признаком красоты человеческого тела. Практический смысл довольно очевиден — ассиметричность у человека всегда появляется при различных травмах, опухолях и иных проблемах со здоровьем. С другими признаками не так просто. Если общество озабочено проблемами деторождения, признаком красоты почти наверняка будет являться широкий женский таз. Если общество ударилось в педофилию, то эталоном красоты будет скорее всего подросток. В обществе, где сильные воинственные настроениея, скорее всего эталоном будет атлетическое телосложение.
Как то так получатеся, что какие то отголоски практичности имеются, но пользоваться этим для решения практических проблем никак нельзя. Например врач не может руководствоваться понятиями красоты когда делает операцию. Попросить сделать аккуратный разрез можно, но в общем случае резать надо там где можно добраться до того или иного органа. Потому для операций на сердце спокойно вскрывают грудную клетку и на всю жизнь остаётся широкий длинный шрам который сильно вряд ли является признаком красоты.
Если, скажем, от меня требуется дать ответ, что же такое красота, то, очевидно, этот ответ будет отражать именно мои взгляды на разработку, а не прочитаные в какой то книге модный фразы. Для меня такой ответ будет примерно таким: "Красиво, это когда смотришь в код и тебе сходу понятны и детали, и абстракции и точки для расширения, и возможности оптимизации и код раз за разом своей работоспособностью вселяет уверенность."
На самом деле в такой формулировке нет ничего про красоту. Меня интересует именно практический смысл, а эта часть в понятии красота имеет сильно второстепенный смысл. Если посмотреть в толковый словарь, то окажется, что практический смысл имеет непосредтсвенное отношение к понятию дизайн. Более того, слово качество и дизайн сильно связаны. Я бы сказал это две стороны одной монеты.
Например, для меня практический смысл имеют
1. корректность и работоспособность
2. эффективность решения в пересчете на ресурсы (включая время)
3. эффективность создания решения в пересчете на ресурсы (включая время)
4. понятность (начиная с читабельности)
5. грамотность (xml парсить не регэкспами, а специальными инструментами — xml dom parser, xml sax parse)
6. сложность сопровождения
7. сложность багфикса
Соответсвенно хороший дизайн обеспечивает все эти требования. Более того, цель дизайна это именно обеспечение выполнимости всех условий согласно требованиям выше.
Пример
Необходимо написать UI слой для веб-приложения. "Красивость" может подсказать решение в одну строчку. Но вот вопрос — например, время обновления данных с сервера слишком велико, а специфика приложения требует это обновление постоянно. Внезапно, "красовость" перестала работать и в бой вступает тот самый дизайн. Решением является, например, переход на Ajax с целью удешевить обновления в терминах ресурсов(и времени). Что характерно, эта часть влияет и на серверную часть. С точки зрения дизайна здесь нет никакой крамолы.
Еще пример
Есть некоторый визуальный компонент, навроде редактора UML-диаграм, с одной лишь разнией, что квадраты и связи обновляются системой мониторинга, которая шлет данные каждые 100мс. Важно обеспечить быстрое время отклика и успевать обновлять-рисовать все квадраты и связи, да еще и накапливать данные.
В бой снова вступает тот самый дизайн. В зависимости от того, какие требования к возможностям, обновление всей картины может занять не менее 100мс.
Здесь много самых разных решений. Например, человек сильно вряд ли сможет различить картинки через 100мс. Если данных много, то и нескольких секунд недостаточно.
Отсюда решение — отделить прием данных от всего процессинга, а визуализация будет рисовать скажем 2 раза в секунду или даже раз в секунду. При этом сами данные можно накапливать как угодно. Если сам квадрат-связь обновились, то нет нужды сразу все перерисововать. Достаточно вызвать например метод Invalidate, и нужный кусочек данных перерисуется в следующем кадре.
В понятие красоты вполне может входить и краткость решения, и правильно расставленые скобочки, и каменты, и разные стили именования, и красивые UML-диаграмы типа "все наследуется отсюда".
В понятие дизайн ничего этого не входит и входить не может. Дизайн — сугубо прикладное, практическое решение актуальных проблем, включая как функциональные требования(фича1,2...N), так и нефункциональные (производительность, энергосбережение, загрузка процессора и тд)
Что же такое качество, снова в следующий раз.
P.S. Берегитесь людей, кто под словом дизайн понимает "красота". С большой вероятностью они будут работать по принципу "дизайн-красота это хорошо, но это когда время появится, а пока что и говнокода хватит". Или так "давай код писать, а думать потом будем". На самом деле это просто одно из оправданий для ухода от решения проблем.
P.P.S. Очень внимательно нужно следить за теми, кто уделяет много внимания эстетической стороне кода, а именно стили, скобочки и тд. Есть мнение, красота для них имеет бОльший приоритет, нежели решение проблем.
Красота вообще очень интересное слово. Как правило, люди понимают под ним каждый своё собственное. Как известно, в ИТ всё изобретается заново. Потому, что бы поговорить за красоту, нужно посмотреть чего же под ней понимают в других областях. Можно например, посмотреть что думают про красоту человеческого тела. Как ни странно, понятие красоты отражает точку зрения носителей некоторой общности. То есть, красота примерно как мода, везде разная, меняется со временем.
Хотя красота это непрактическая категория, тем не менее для практичности место есть. Например ассиметричность почти никогда не являлась признаком красоты человеческого тела. Практический смысл довольно очевиден — ассиметричность у человека всегда появляется при различных травмах, опухолях и иных проблемах со здоровьем. С другими признаками не так просто. Если общество озабочено проблемами деторождения, признаком красоты почти наверняка будет являться широкий женский таз. Если общество ударилось в педофилию, то эталоном красоты будет скорее всего подросток. В обществе, где сильные воинственные настроениея, скорее всего эталоном будет атлетическое телосложение.
Как то так получатеся, что какие то отголоски практичности имеются, но пользоваться этим для решения практических проблем никак нельзя. Например врач не может руководствоваться понятиями красоты когда делает операцию. Попросить сделать аккуратный разрез можно, но в общем случае резать надо там где можно добраться до того или иного органа. Потому для операций на сердце спокойно вскрывают грудную клетку и на всю жизнь остаётся широкий длинный шрам который сильно вряд ли является признаком красоты.
Если, скажем, от меня требуется дать ответ, что же такое красота, то, очевидно, этот ответ будет отражать именно мои взгляды на разработку, а не прочитаные в какой то книге модный фразы. Для меня такой ответ будет примерно таким: "Красиво, это когда смотришь в код и тебе сходу понятны и детали, и абстракции и точки для расширения, и возможности оптимизации и код раз за разом своей работоспособностью вселяет уверенность."
На самом деле в такой формулировке нет ничего про красоту. Меня интересует именно практический смысл, а эта часть в понятии красота имеет сильно второстепенный смысл. Если посмотреть в толковый словарь, то окажется, что практический смысл имеет непосредтсвенное отношение к понятию дизайн. Более того, слово качество и дизайн сильно связаны. Я бы сказал это две стороны одной монеты.
Например, для меня практический смысл имеют
1. корректность и работоспособность
2. эффективность решения в пересчете на ресурсы (включая время)
3. эффективность создания решения в пересчете на ресурсы (включая время)
4. понятность (начиная с читабельности)
5. грамотность (xml парсить не регэкспами, а специальными инструментами — xml dom parser, xml sax parse)
6. сложность сопровождения
7. сложность багфикса
Соответсвенно хороший дизайн обеспечивает все эти требования. Более того, цель дизайна это именно обеспечение выполнимости всех условий согласно требованиям выше.
Пример
Необходимо написать UI слой для веб-приложения. "Красивость" может подсказать решение в одну строчку. Но вот вопрос — например, время обновления данных с сервера слишком велико, а специфика приложения требует это обновление постоянно. Внезапно, "красовость" перестала работать и в бой вступает тот самый дизайн. Решением является, например, переход на Ajax с целью удешевить обновления в терминах ресурсов(и времени). Что характерно, эта часть влияет и на серверную часть. С точки зрения дизайна здесь нет никакой крамолы.
Еще пример
Есть некоторый визуальный компонент, навроде редактора UML-диаграм, с одной лишь разнией, что квадраты и связи обновляются системой мониторинга, которая шлет данные каждые 100мс. Важно обеспечить быстрое время отклика и успевать обновлять-рисовать все квадраты и связи, да еще и накапливать данные.
В бой снова вступает тот самый дизайн. В зависимости от того, какие требования к возможностям, обновление всей картины может занять не менее 100мс.
Здесь много самых разных решений. Например, человек сильно вряд ли сможет различить картинки через 100мс. Если данных много, то и нескольких секунд недостаточно.
Отсюда решение — отделить прием данных от всего процессинга, а визуализация будет рисовать скажем 2 раза в секунду или даже раз в секунду. При этом сами данные можно накапливать как угодно. Если сам квадрат-связь обновились, то нет нужды сразу все перерисововать. Достаточно вызвать например метод Invalidate, и нужный кусочек данных перерисуется в следующем кадре.
В понятие красоты вполне может входить и краткость решения, и правильно расставленые скобочки, и каменты, и разные стили именования, и красивые UML-диаграмы типа "все наследуется отсюда".
В понятие дизайн ничего этого не входит и входить не может. Дизайн — сугубо прикладное, практическое решение актуальных проблем, включая как функциональные требования(фича1,2...N), так и нефункциональные (производительность, энергосбережение, загрузка процессора и тд)
Что же такое качество, снова в следующий раз.
P.S. Берегитесь людей, кто под словом дизайн понимает "красота". С большой вероятностью они будут работать по принципу "дизайн-красота это хорошо, но это когда время появится, а пока что и говнокода хватит". Или так "давай код писать, а думать потом будем". На самом деле это просто одно из оправданий для ухода от решения проблем.
P.P.S. Очень внимательно нужно следить за теми, кто уделяет много внимания эстетической стороне кода, а именно стили, скобочки и тд. Есть мнение, красота для них имеет бОльший приоритет, нежели решение проблем.
| 22.06.2014 4 комментария |
I>Например, для меня практический смысл имеют
I>1. корректность и работоспособность
I>2. эффективность решения в пересчете на ресурсы (включая время)
I>3. эффективность создания решения в пересчете на ресурсы (включая время)
I>4. понятность (начиная с читабельности)
I>5. грамотность (xml парсить не регэкспами, а специальными инструментами — xml dom parser, xml sax parse)
I>6. сложность сопровождения
I>7. сложность багфикса
Короче.
Все это можно назвать технологичность.
Штука. которая сокращает затраты на разработку.
Почему паттерны важны? Потому, что они технологичны: инкапсулируют изменения кода.
Что является повседневной практикой программирования.
Поэтому ИМХО любые приемы, повышающие технологичность — приветствуются!
А красоту можно видеть при решении отдельных задач.
Например, реверс строки — есть красивейшее решение.
И дизайн с технологичность тут никакой рояли не играют...
LVV>Короче.
LVV>Все это можно назвать технологичность.
LVV>Штука. которая сокращает затраты на разработку.
Не сокращает, а обеспечивает сам результат. Технологичность это только часть перечисленного.
LVV>Почему паттерны важны? Потому, что они технологичны: инкапсулируют изменения кода.
Я бы сказал паттерны технологичны, если их выбирали после решения задачи, а не вместо решения задачи, и они применены действительно правильно.
Если вместо решения задачи получается хрень "вот здесь будет синглтон", то профит как правило отрицательный, потому что в большинстве своем те же синглтоны это ровно та же глобальная переменная, только больше кода.
То есть, идея такая — решить задачу, а потом перегонять решение в код. И вот здесь, возможно, понадобится тот или другой паттерн, а может и нет. Например если оказывается, что некоторый объект должен менять своё поведение, то можно сделать своё решение, а можно посмотреть чего есть в типовых решениях на этот счет. Никто не обязует копировать код из книги ГоФ или какой другой.
При этом сводить решение к объекту, который меняет поведение на том основании, что есть паттерн State, мягко говоря, глупость.
LVV>А красоту можно видеть при решении отдельных задач.
LVV>Например, реверс строки — есть красивейшее решение.
LVV>И дизайн с технологичность тут никакой рояли не играют...
Вообще говоря это самое красивейшее решение реверса и есть хороший дизайн. А красота никакого отношения к практичности не имеет. Дизайн как раз наоборот, он весь целиком и весь сама практичность.
Вообще, я про паттерны такого мнения — мастер не применяет паттерны. Из этого, кстати говоря, совсем не следует, что в таком коде не найдется синглтон, фасад или стратегия. Правильный профессионал руководствуется не паттернами, более простыми вещами — обязанности, зависимости, состояние, поведение и тд и тд.
LVV>>Все это можно назвать технологичность.
LVV>>Штука, которая сокращает затраты на разработку.
I>Не сокращает, а обеспечивает сам результат. Технологичность это только часть перечисленного.
А, ну да.
LVV>>Почему паттерны важны? Потому, что они технологичны: инкапсулируют изменения кода.
I>Я бы сказал паттерны технологичны, если их выбирали после решения задачи, а не вместо решения задачи, и они применены действительно правильно.
Вот чем больше я преподаю у программистов, тем более проникаюсь мыслью, что надо разделять специализации.
Проектировщики ПО — это одно, а реализаторы ПО — это другое.
В материальном производстве такое сплошь и рядом. Более того, деление еще более детальное.
Вот строительство: архитекторы, инженеры (которые сичтают сопромат...
Самолеты — то же самое: Конструкторы, инженеры, строители. Да еще и испытатели — тестировщики.
Кто на что учился.
Разработка ПО — слишком молодая отрасль, такого разделения пока не прозошло, но к тому идет.
Красота кода — это при индивидуальной "кустарной" разработке имеет право на жизнь.
При корпоративной разработке нужно применять технологию.
В которой должен быть прописан каждый чих разработчика. Творчеству тут места мало должно быть (хотя, естественно, оно тоже присутствует) .
I>Если вместо решения задачи получается хрень "вот здесь будет синглтон", то профит как правило отрицательный, потому что в большинстве своем те же синглтоны это ровно та же глобальная переменная, только больше кода.
I>То есть, идея такая — решить задачу, а потом перегонять решение в код. И вот здесь, возможно, понадобится тот или другой паттерн, а может и нет. Например если оказывается, что некоторый объект должен менять своё поведение, то можно сделать своё решение, а можно посмотреть чего есть в типовых решениях на этот счет. Никто не обязует копировать код из книги ГоФ или какой другой.
I>При этом сводить решение к объекту, который меняет поведение на том основании, что есть паттерн State, мягко говоря, глупость.
Ну, естественно. Это не относится к технологии.
Но квалификация разработчика должна быть такова, чтобы он НЕ ЗАДУМЫВАЯСЬ, видел.какой паттерн СЛЕДУЕТ применить в данном конкретном месте разработки.
LVV>>А красоту можно видеть при решении отдельных задач.
LVV>>Например, реверс строки — есть красивейшее решение.
LVV>>И дизайн с технологичность тут никакой рояли не играют...
I>Вообще говоря это самое красивейшее решение реверса и есть хороший дизайн. А красота никакого отношения к практичности не имеет. Дизайн как раз наоборот, он весь целиком и весь сама практичность.
Ну, если слово "дизайн" понимать буквально как "разработка" — согласен.
I>Вообще, я про паттерны такого мнения — мастер не применяет паттерны. Из этого, кстати говоря, совсем не следует, что в таком коде не найдется синглтон, фасад или стратегия. Правильный профессионал руководствуется не паттернами, более простыми вещами — обязанности, зависимости, состояние, поведение и тд и тд.
Не. Не совсем согласен.
Вот я тут намедни книжонку купил от Соммерфилда: http://www.ozon.ru/context/detail/id/27292816/
Питон на практике.
Там он в первых главах описывает паттерны из Банды 4 (в том же порядке!).
И в некоторых случаях прямо говорит, что этот паттерн в питон ВСТРОЕН!
Отсюда следует, что обязанности, зависимости, поведение и т.д. — это все правильно. Но это на уровне анализа и проектирования задачи.
А на уровне реализации — паттерны применять необходимо.
Естественно, не ради самих паттернов, а для инкапсуляции будущих изменений.
Для повышения технологичности разработки.
LVV>>>Почему паттерны важны? Потому, что они технологичны: инкапсулируют изменения кода.
I>>Я бы сказал паттерны технологичны, если их выбирали после решения задачи, а не вместо решения задачи, и они применены действительно правильно.
LVV>Вот чем больше я преподаю у программистов, тем более проникаюсь мыслью, что надо разделять специализации.
LVV>Проектировщики ПО — это одно, а реализаторы ПО — это другое.
Не надо ничего разделять. Разработка софта это проектирование задолго до начала и до самого конца.
Учить нужно не паттернам, а внятным вещам. Рассказывать не про "три кита ООП" а про АТД, обязанности, зависимости, контракты, время жизни, агрегирование, делегирование, композиция.
LVV>В материальном производстве такое сплошь и рядом. Более того, деление еще более детальное.
LVV>Вот строительство: архитекторы, инженеры (которые сичтают сопромат...
LVV>Самолеты — то же самое: Конструкторы, инженеры, строители. Да еще и испытатели — тестировщики.
LVV>Кто на что учился.
Здесь имеем четкое разделение проектирования от разработки. А в софте это все вместе. Программа представляет проект самой себя.
LVV>Разработка ПО — слишком молодая отрасль, такого разделения пока не прозошло, но к тому идет.
Её всеми силами пытаются туда загнать. Ничего не выйдет. Степень реюзания слишком высока — все время надо решать новые задачи. А в случаес теми же самолетами — один раз спроектировал и далее штампуй самолеты на конвейере.
LVV>При корпоративной разработке нужно применять технологию.
LVV>В которой должен быть прописан каждый чих разработчика. Творчеству тут места мало должно быть (хотя, естественно, оно тоже присутствует) .
Не чих, а результат. Если технология будет подавлять творчество, от нее будет мало толку, потому что как я уж сказал, степень реюзания очень высока.
I>>При этом сводить решение к объекту, который меняет поведение на том основании, что есть паттерн State, мягко говоря, глупость.
LVV>Ну, естественно. Это не относится к технологии.
LVV>Но квалификация разработчика должна быть такова, чтобы он НЕ ЗАДУМЫВАЯСЬ, видел.какой паттерн СЛЕДУЕТ применить в данном конкретном месте разработки.
Это тупик. Я бюсь что мы уже видим результат этого подхода — разработчики уже не задумываясь видят, какой паттерн следуюет применить.
Более того, даже выяснить нельзя, почему именно этот и какую проблему он решает: "Тут всё просто", "Мы так решили", "А как еще ?"
Вобщем, твоя максима уже реализована, только у ней один конец — разработчики вообще не хотят думать, строят софт из паттернов как из кирпичиков. Собственно, потому и тупик.