Изменение восприятия сложности07.05.2017 14:17

Комментарии (14)

DaneSoul

7 мая 2017 в 12:57

0

↑

↓

Говоря о сложности, надо бы отдельно рассматривать два момента:
— Сложность уникальную — когда мы делаем что-то сильно новое и большая часть наших решений уникальна.
— Сложность стандартизованную — когда мы используем сложные инструменты и технологии, но эти технологии отлажены уже многократным использованием в других проектах.
Вот со стандартизованной сложностью все не так страшно. Да, используемая библиотека может быть мега-сложной внутри, но если она уже была оттестирована и отлажена на сотнях проектов, то проблем от нее обычно мало.
А с уникальной сложностью по-возможности надо бороться, либо переводя ее в стандартизованную (используя готовые блоки), либо максимально упрощая архитектуру проекта, чтобы он был четкий и понятный.
- Tiendil
  
  7 мая 2017 в 13:06
  
  +1
  
  ↑
  
  ↓
  
  С одно стороны всё так. С другой, стандартизованная сложность может восриниматься уникальной для человека, который только входит в предметную область. А таких большинство (и, на мой вгляд, всегда будет большинство).
  - DaneSoul
    
    7 мая 2017 в 13:15
    
    0
    
    ↑
    
    ↓
    
    Это не совсем так, правильно организованный инструмент скрывает эту сложность давая тому кто его использует простой и понятный интерфейс.
    Да, кто-то должен заниматься поддержкой и на самом глубоком уровне, но:
    — таких людей нужно значительно меньше, по сравнению с теми кто просто использует инструмент
    — такие люди имеют более узкую специализацию, каждый в своей сфере
    Примеры такой стандартизованной сложности:
    — JQuery для новичка будет очень сложен, если лезть в его внутренности, но в этом новичку нет необходимости, он может им пользоваться через простые методы.
    — Точно также и автомобиль, например, внутри устроен очень сложно, но для того чтобы просто ездить, знать его внутренности досконально нет необходимости, достаточно освоить достаточно простые органы управления и знать ограниченя (углы поворота, тормозной путь и т.п.).
- joker2k1
  
  7 мая 2017 в 13:10
  
  +1
  
  ↑
  
  ↓
  
  Как не странно, подумал совершенно наоборот. Если решение разовое — оно может быть сложным, потому что делается быстро, и вся сложность вполне умещается в голову. Как кино — снимается один раз, и вполне можно ради одного кадра нагородить огород.
  А вот если решение на года/на много раз — тот тут я сложности боюсь. Из головы это вылетит, и потом будет сложно дорабатывать/поддерживать/эксплуатировать. Тут лучше иметь простое решение. Каждый раз городить огород дорого.
  - DaneSoul
    
    7 мая 2017 в 13:17
    
    0
    
    ↑
    
    ↓
    
    Смотря что понимать под «разовым». Если сделал и забыл, как фильм, то да, очень верная мысль.
    А если оно уникальное и разовое, но его надо поддерживать после годами, то все не так радужно уже получается. Особенно это актуально для всякого уникального научного оборудования.
- VioletGiraffe
  
  7 мая 2017 в 13:29 (комментарий был изменён)
  
  0
  
  ↑
  
  ↓
  
  Согласен с вашим вторым абзацем. Главный инструмент борьбы со сложностью в инженерии (а особенно в IT) — абстракции. Описанная и документированная абстракция — интерфейс. Либо просто спецификация (то есть документ, а не фрагмент кода). Реализованная в коде — модуль (это может быть класс, или целове приложение, или железка). Если вся система корректно работает через эти интерфейсы, замена одного модуля на другой с тем же интерфейсом не повлияет на работопособность системы, в этом прелесть и красота хорошо спроектировнной системы. И это (правильно выделенные абстракции) — единственное, что позволяет человеческому мозгу, способному одновременно удержать в голове всего лишь около 7 понятий, создавать такие сложные инженерные произведения.
  Из этой же оперы — готовые решения (код, алгоритмы, формулы, методики — это может быть любая инженерная сущность), которые можно применять, не понимая, как они работают внутри.
mayorovp

7 мая 2017 в 13:15 (комментарий был изменён)

0

↑

↓

Какое-то странное у вас понимание борьбы со сложностью. Получается что технологии, созданные для борьбы со сложностью, вдруг начали делать решение сложнее —, а технологии, которые сложность «принимают», делают все проще… Какая-то борьба в минус получается.

Правильная борьба со сложностью — это когда решение становится проще для реализации и для понимания, а не сложнее.
- Tiendil
  
  7 мая 2017 в 13:21
  
  +1
  
  ↑
  
  ↓
  
  И новый и старый подход призваны справляться со сложностью. В этом у них нет отличия. Просто они справляются с ней по-разному.
  «Старый» путь тотального огораживания и формализации до определённого момента выгоднее, но по мере роста количества сущностей и связей между ними, издержки на него начинают превышать выгоду.
  Тут уже себя проявлет «новый» подход, экономя ресурсы за счёт гибкости.
  - mayorovp
    
    7 мая 2017 в 13:39 (комментарий был изменён)
    
    0
    
    ↑
    
    ↓
    
    Напротив, формализация и огораживание начинают работать после некоторого момента — когда спецификация и документация перестает помещаться в голове у разработчика. В этот момент они либо где-то записываются — либо безвозвратно теряются, и с этого момента код начинают называть ругательным словом legacy.
- DaneSoul
  
  7 мая 2017 в 13:25
  
  +1
  
  ↑
  
  ↓
  
  Правильная борьба со сложностью — это когда решение становится проще для реализации и для понимания, а не сложнее.
  Все зависит от точки отсчета.
  Смотрите, допустим есть математическая задача.
  Для ее решения можно написать уникальное решение, допустим в 100 строк кода.
  А можно взять математический пакет в котором 100 000 строк кода, но лично нам для решения задачи надо написать 1 строку.
  Вот если оценивать общую сложность системы — решение с математическим пакетом на порядки сложней, а в практической реализации оно на порядке проще, так как решение в нем уже фактически есть, его надо просто вызывать.
  - Tiendil
    
    7 мая 2017 в 13:27
    
    0
    
    ↑
    
    ↓
    
    Надо добавить, что чтобы написать эту одну строку, может потребовать изучить работу всего пакета.
mayorovp

7 мая 2017 в 13:32

+1

↑

↓
Нельзя говорить, что XML — «жесткий» формат, а JSON — «гибкий». На самом деле все совсем наоборот. Возьмем для примера вот такие фрагменты:
```
    
    
    


{ products: [ ..., ..., ... ] }
```
И там, и там — сериализованный массив из трех элементов. Теперь попробуем добавить немного метаданных:
```
    
    
    
    


{ 
  products: { 
     foo: 'foo' , 
     items: [ {
         type: 'product',
         data: ...
       }, {
         type: 'product',
         bar: 'bar',
         data: ...
       }, {
         type: 'baz'
       }, {
         type: 'product',
         data: ...
       }
     ]
  }
}
```
В случае XML удалось добавить метаданные, сохранив исходную структуру. Если скормить такое документ старому коду — тот может вовсе не заметить лишних метаданных! В случае JSON пришлось радикально менять схему данных, потому что мета-информация туды уже не влазила.

Именно XML является гибким форматом, который из-за своей гибкости бывает довольно сложен. А JSON — это простой жесткий формат, в котором, во-первых, нет ничего лишнего —, а во-вторых, он хорошо укладывается именно в задачи сериализации простых структур данных, за что он и получил распространение.

Переход от XML к JSON — это именно продолжение борьбы со сложностью, а не ее принятие.
apro

7 мая 2017 в 13:57

+1

↑

↓

языки с динамической типизацией
Но почему-то по мере взросления Python обзавелся type hiting,
появился TypeScript и т.п.
- Tiendil
  
  7 мая 2017 в 14:10
  
  0
  
  ↑
  
  ↓
  
  Конретно по Python могу сказать, что это не первая попытка добавить в него статическую типизацию и пока ни она ни предыдущие успехом не увенчались.
  На мой взгляд, заигрыванание со статической типизацией без чёткого плана (а его нет) — самая большая проблема Python.