Пост Complexity Fighting в корне неверный. Связанно это с тем, что автор не понимает природу сложности. Автор не знает, что бывают разные типы сложности и поэтому ошибочно считает, что с любым типом сложности можно бороться при помощи упрощения. При разработке программных систем встречаются следующие типы сложности: 1. Сложность объёма работ. 2. Сложность предметной области. 3. Математическая сложность. 4. Алгоритмическая сложность. 5. Архитектурная сложность. 6. Сложность организации взаимодействия разработчиков. 7. Сложность, связанная с тестированием. И т.д. При помощи упрощения можно бороться со сложностью предметной области, но не получиться бороться с математической сложностью. При помощи декомпозиции можно бороться с архитектурной сложностью, но не получиться бороться с алгоритмической. Например, алгоритм qsort сложный, но его не получиться упростить, разбив на более мелкие части.
Из-за того, что автор не понимает природу сложности и не знает о существовании её типов, вытекает неверное понимание основной задачи архитектора. Основная задача архитектора состоит не в том, что бы сложные вещи делать простыми, а в том, что бы сложные вещи делать простыми в использовании и реализации. Между этими двумя вещами огромная разница. Алгоритм qsort невозможно сделать проще; но можно сделать так, что бы программист мог использовать любой вид сортировки, не задумываясь о том насколько сложен каждый конкретный алгоритм. Так мы используем std::sort из stl не задумываясь об алгоритмической сложности реализованного алгоритма.
Владимир, желаю вам удачи в классификации сложностей! Трудитесь на благо Лиги Наций, открывайте новые виды сложности. Когда будете издавать 5-ый том своих трудов, посмотрите в словаре смысл слова Complexity.
Пост Complexity Fighting в корне неверный. Связанно это с тем, что автор не понимает природу сложности. Автор не знает, что бывают разные типы сложности и поэтому ошибочно считает, что с любым типом сложности можно бороться при помощи упрощения.
Не соглашусь, пожалуй. Сергей говорит скорее об архитектурной сложности, но особо не вдается в подробности. Пост у него такой, обзорный.
То что трудность для понимания именно _понизится_ в результате _выкидывания_ слоя/блока/метода совершенно не факт.
Не факт. Сергей предлагает _подумать_ над тем, что будет в таком случае. Призыва "выкинуть все нафиг" там нет :-)
Бороться со сложностью надо, но по существку вопроса пост ни о чем, поддерживаю первого оратора.
Не соглашусь, пожалуй. Сергей говорит скорее об архитектурной сложности, но особо не вдается в подробности. Пост у него такой, обзорный.
Сергей скорее всего говорит не об архитектурной сложности, а о сложности предметной области. Потому что именно эта сложность хорошо потдаётся упрощению путём абстрагирования - выделения существенных аспектов и игнорирования несущественных.
Если бы Сергей имел в виду архитектурную сложность то он бы говорил о декомпозиции, выделении интерфейса и сокрытии реализации.
И ещё Сергей скорее всего имел в виду, что бороться надо с over-engineering-ом, а не со сложностью как таковой.
to Vladimir Frolov Спасибо, Владимир за ликбез. По счастью, мой блог - это не конспект лекций по системному анализу. Потому там нет ни классификации типов сложности, ни обзора методов борьбы с ними. Одни призывы и лозунги :) Популизм, одним словом. В этом же духе намерен и продолжать. Быть может, кто нибудь начитается моих лозунгов, и откроет после этого учебник, и найдет в нем вашу классификацию, и станет от этого слегка умнее. Вот здорово то будет!
to Sergey Rozovik Проблема не в том, что вы призываете бороться со сложностью при помощи популизма. В самом популизме нет ничего плохого. Проблема в том, что вы призываете бороться с ветряными мельницами.
Пост Complexity Fighting в корне неверный. Связанно это с тем, что автор не понимает природу сложности. Автор не знает, что бывают разные типы сложности и поэтому ошибочно считает, что с любым типом сложности можно бороться при помощи упрощения. При разработке программных систем встречаются следующие типы сложности:
ОтветитьУдалить1. Сложность объёма работ.
2. Сложность предметной области.
3. Математическая сложность.
4. Алгоритмическая сложность.
5. Архитектурная сложность.
6. Сложность организации взаимодействия разработчиков.
7. Сложность, связанная с тестированием.
И т.д.
При помощи упрощения можно бороться со сложностью предметной области, но не получиться бороться с математической сложностью. При помощи декомпозиции можно бороться с архитектурной сложностью, но не получиться бороться с алгоритмической. Например, алгоритм qsort сложный, но его не получиться упростить, разбив на более мелкие части.
Из-за того, что автор не понимает природу сложности и не знает о существовании её типов, вытекает неверное понимание основной задачи архитектора. Основная задача архитектора состоит не в том, что бы сложные вещи делать простыми, а в том, что бы сложные вещи делать простыми в использовании и реализации. Между этими двумя вещами огромная разница. Алгоритм qsort невозможно сделать проще; но можно сделать так, что бы программист мог использовать любой вид сортировки, не задумываясь о том насколько сложен каждый конкретный алгоритм. Так мы используем std::sort из stl не задумываясь об алгоритмической сложности реализованного алгоритма.
Владимир, желаю вам удачи в классификации сложностей! Трудитесь на благо Лиги Наций, открывайте новые виды сложности.
ОтветитьУдалитьКогда будете издавать 5-ый том своих трудов, посмотрите в словаре смысл слова Complexity.
> Когда будете издавать 5-ый том
ОтветитьУдалить> своих трудов, посмотрите в словаре
> смысл слова Complexity
Cложность - качественная характеристика, выражающая трудность алгоритма, задачи и т.п. для понимания (c) Lingvo
То что трудность для понимания именно _понизится_ в результате _выкидывания_ слоя/блока/метода совершенно не факт.
Бороться со сложностью надо, но по существку вопроса пост ни о чем, поддерживаю первого оратора.
Пост Complexity Fighting в корне неверный. Связанно это с тем, что автор не понимает природу сложности. Автор не знает, что бывают разные типы сложности и поэтому ошибочно считает, что с любым типом сложности можно бороться при помощи упрощения.
ОтветитьУдалитьНе соглашусь, пожалуй. Сергей говорит скорее об архитектурной сложности, но особо не вдается в подробности. Пост у него такой, обзорный.
То что трудность для понимания именно _понизится_ в результате _выкидывания_ слоя/блока/метода совершенно не факт.
Не факт. Сергей предлагает _подумать_ над тем, что будет в таком случае. Призыва "выкинуть все нафиг" там нет :-)
Бороться со сложностью надо, но по существку вопроса пост ни о чем, поддерживаю первого оратора.
Пост о том, что сложнее - не значит лучше.
Не соглашусь, пожалуй. Сергей говорит скорее об архитектурной сложности, но особо не вдается в подробности. Пост у него такой, обзорный.
ОтветитьУдалитьСергей скорее всего говорит не об архитектурной сложности, а о сложности предметной области. Потому что именно эта сложность хорошо потдаётся упрощению путём абстрагирования - выделения существенных аспектов и игнорирования несущественных.
Если бы Сергей имел в виду архитектурную сложность то он бы говорил о декомпозиции, выделении интерфейса и сокрытии реализации.
И ещё Сергей скорее всего имел в виду, что бороться надо с over-engineering-ом, а не со сложностью как таковой.
to Vladimir Frolov
ОтветитьУдалитьСпасибо, Владимир за ликбез. По счастью, мой блог - это не конспект лекций по системному анализу. Потому там нет ни классификации типов сложности, ни обзора методов борьбы с ними. Одни призывы и лозунги :) Популизм, одним словом. В этом же духе намерен и продолжать. Быть может, кто нибудь начитается моих лозунгов, и откроет после этого учебник, и найдет в нем вашу классификацию, и станет от этого слегка умнее. Вот здорово то будет!
to Sergey Rozovik
ОтветитьУдалитьПроблема не в том, что вы призываете бороться со сложностью при помощи популизма. В самом популизме нет ничего плохого. Проблема в том, что вы призываете бороться с ветряными мельницами.
Иной взгляд на золотой век :-)
ОтветитьУдалитьhttp://www.gotsulyak.com/2007/05/post71