Эффективность VS Сопровождаемость
От: Gattaka Россия  
Дата: 03.03.17 07:27
Оценка: -1
Коллеги,
На мой взгляд программисты делятся на два лагеря: приверженцы эффективного кода и приверженцы сопровождаемоего кода. Эти два подхода зачастую противоречат друг другу — отсюда и возникают споры. В частности писать ли бизнес-логику в хранимых процедурах? С точки зрения эффективности это идеальный вариант, с точки зрения сопровождаемости — худший. Нельзя тестировать, нет наследования и intellicense. Да и вобще луче использовать MongoDB. Ее любой может освоить за день, пихаешь себе джейсон и не паришься. Тогда база данных выступает как хранилище да и только.
Понятно, что в жизни полно промежуточных вариантов. Например, Linq2DB у вас и эффективность кода нормальная и сопровождаемость отличная. Но не всегда это реализуемо. Либо хинта какого-то нет либо поддержки СУБД какой-то.
Еще пример — посмотрите доклады ребят из команды Решарпера. Там в C# им приходится делать выкрутасы, которые явно бьют по сопровождаемости в пользу производительности.
Собственно вопрос стоит в том почему возникло это противречие? Почему эффективность != сопровождаемость?
Re: Эффективность VS Сопровождаемость
От: ry Россия  
Дата: 03.03.17 07:45
Оценка: +1 -1
Здравствуйте, Gattaka, Вы писали:

G>Почему эффективность != сопровождаемость?

— Плохо поставленные процессы
— Разный уровень разработчиков
— Отсутствие или плохая/неактуальная документация
Re[2]: Эффективность VS Сопровождаемость
От: Gattaka Россия  
Дата: 03.03.17 07:52
Оценка:
Здравствуйте, ry, Вы писали:

ry>Здравствуйте, Gattaka, Вы писали:


G>>Почему эффективность != сопровождаемость?

ry>- Плохо поставленные процессы
ry>- Разный уровень разработчиков
ry>- Отсутствие или плохая/неактуальная документация
Ну это все влияет, конечно. Но ведь спор между С++никами и C#стами тоже имеет такую природу. Одни говорят зато у нас программы офигенно производительные, другие парируют что пока изучишь ваш язык — обалдеешь. NodeJS еще проще, но и с произодительностью еще хуже. Тут дело не только в процессах, причины глубже.
Re[3]: Эффективность VS Сопровождаемость
От: ry Россия  
Дата: 03.03.17 09:20
Оценка:
Здравствуйте, Gattaka, Вы писали:

G>Тут дело не только в процессах, причины глубже.

Честно говоря, не очень понимаю, что значит "глубже".
Разработка, как впрочем и любая другая деятельность, — это процессы (сложные или простые, тяжёлые или лёгкие, формальные или нет)
Если плохо с производительностью, то с большей вероятностью это происходит от низкого уровня алгоритмической подготовки разработчиков.
Если плохо с сопровождаемостью, то это — 100% плохо поставленные процессы.
Куда нужно погрузиться глубже?
Re: Эффективность VS Сопровождаемость
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.03.17 09:28
Оценка: 6 (2)
Здравствуйте, Gattaka, Вы писали:

G>Коллеги,

G>На мой взгляд программисты делятся на два лагеря: приверженцы эффективного кода и приверженцы сопровождаемоего кода.

В чём-то это "Пять миров" Спольски на новый лад.

Я бы ещё добавил к этому аспект типа "у нас на этом 5 лет один человек сидит и все вопросы к нему" и антипод — "есть халтура добавить сюда новый блок, времени неделя вместе с тестированием у заказчика". Принципы типа SOLID на 99% предназначены для второго случая — не просто сопровождаемость, а сопровождаемость в условиях гарантированного цейтнота.

G>Собственно вопрос стоит в том почему возникло это противречие? Почему эффективность != сопровождаемость?


А почему есть грузовики, а есть самокаты?
The God is real, unless declared integer.
Re: Эффективность VS Сопровождаемость
От: Pzz Россия https://github.com/alexpevzner
Дата: 03.03.17 09:40
Оценка: 4 (3) +3
Здравствуйте, Gattaka, Вы писали:

G>Собственно вопрос стоит в том почему возникло это противречие? Почему эффективность != сопровождаемость?


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

К счастью, в реальной программе вопросы производительности обычно стоят в очень небольшой ее части, а в прочих частях производительность не слишком важна. Кроме того, быстрая часть редко бывает сложной, а сложная — быстрой. Поэтому писать эти части надо по-разному, и не надо жертвовать читаемостью или эффективностью ради единообразия.
Re[4]: Эффективность VS Сопровождаемость
От: Pzz Россия https://github.com/alexpevzner
Дата: 03.03.17 09:43
Оценка: +1
Здравствуйте, ry, Вы писали:

ry>Если плохо с производительностью, то с большей вероятностью это происходит от низкого уровня алгоритмической подготовки разработчиков.


Или наоборот, от слишком высокого. Heap sort на массиве из 5-и чисел будет работать медленнее, чем тривиальная сортировка пузырьком, и линейный поиск на небольшом объеме данных работает быстрее, чем хеширование или двоичное дерево.

К сожалению, многие программисты, познав для себя интересные алгоритмы, стесняются применять простые алгоритмы там, где это уместно. Я тоже, бывает, этим грешу
Re: Есть две категории людей:
От: koandrew Канада http://thingselectronic.blogspot.ca/
Дата: 03.03.17 12:51
Оценка: +3
Здравствуйте, Gattaka, Вы писали:

Те, которые делят остальных на две категории, и все остальные (С)
[КУ] оккупировала армия.
Re[2]: Есть две категории людей:
От: Privalov  
Дата: 03.03.17 14:10
Оценка:
Здравствуйте, koandrew, Вы писали:

K>Те, которые делят остальных на две категории, и все остальные (С)


Умные и те, кто делит людей на две категории. ©
Re: Эффективность VS Сопровождаемость
От: Dym On Россия  
Дата: 03.03.17 14:42
Оценка: +1
G>На мой взгляд программисты делятся на два лагеря: приверженцы эффективного кода и приверженцы сопровождаемоего кода.
Есть еще третий лагерь, небольшая группа, вымирающий вид, практически: приверженцы правильно работающего кода. Но о них не будем — кому они нужны, эти правильно работающие программы...
Счастье — это Glück!
Re[2]: Эффективность VS Сопровождаемость
От: Gattaka Россия  
Дата: 03.03.17 14:45
Оценка:
Здравствуйте, Dym On, Вы писали:

G>>На мой взгляд программисты делятся на два лагеря: приверженцы эффективного кода и приверженцы сопровождаемоего кода.

DO>Есть еще третий лагерь, небольшая группа, вымирающий вид, практически: приверженцы правильно работающего кода. Но о них не будем — кому они нужны, эти правильно работающие программы...
Критерий правильности?
Re: Эффективность VS Сопровождаемость
От: Философ Ад http://vk.com/id10256428
Дата: 03.03.17 16:50
Оценка:
Здравствуйте, Gattaka, Вы писали:

G>В частности писать ли бизнес-логику в хранимых процедурах? С точки зрения эффективности это идеальный вариант, с точки зрения сопровождаемости — худший.

Да, согласен, они сопровождаются крайне плохо. Но иногда это почти единственный вариант написать всегда корректно работающую программу.

G>Нельзя тестировать...

Можно.

G>Да и вобще луче использовать MongoDB.


И этот человек говорит о сопровождаемости .... Да чо уж там, пишите сразу в файл: в файлы умеют писать все — этому вообще на первом курсе учатся. А чтоб вообще проще было — в текстовые. А чтоб ещё проще — в один файл, чтоб "сразу всё перед глазами"(с). Файл сразу целиком в память зачитывайте — так проще (про эффективность не надо — пользователь ещё памяти докупит, если надо).

G>На мой взгляд программисты делятся на два лагеря: приверженцы эффективного кода и приверженцы сопровождаемоего кода.

Откажитесь от многопоточности и вообще параллельных вычислений — корректную синхронизацию не все умеют. Не все даже знают что такое volatile и когда его писать нужно, а уж про барьеры многие вообще никогда не слышали. К тому же всякие локи сильно код портят — он становится неспопровождаемым (на 60 строк алгоритма иногда 120 всяких локов-анлоков/барьеров даблчеков и прочей магии).
А то, что иногда висит UI — ничего страшного, юзер подождёт — не проблема, можно часики песочные повесить на курсор, чтоб пользователя не смущать.
Зато однопоточная, однопроцессная софтина проще в сопровождении чем многопоточная, да ещё и со всякими сервисами.

ЗЫ: я в шоке.
Всё сказанное выше — личное мнение, если не указано обратное.
Отредактировано 03.03.2017 17:07 Философ . Предыдущая версия . Еще …
Отредактировано 03.03.2017 17:03 Философ . Предыдущая версия .
Отредактировано 03.03.2017 16:55 Философ . Предыдущая версия .
Re[2]: Эффективность VS Сопровождаемость
От: Gattaka Россия  
Дата: 03.03.17 17:10
Оценка:
Здравствуйте, Философ, Вы писали:

Ф>ЗЫ: я в шоке.

Судя по вашей реакции вас в этой мясорубке изрядно молотило уже. Ну а так как вы приверженец эффективного кода, то набросились на меня с минусами. Ничего мне не привыкать, сейчас меня еще минусанет приверженец сопровождаемого кода и картина будет более полной.
И все же было бы неплохо если бы вы внимательнее читали исходное сообщение.
Re[3]: Эффективность VS Сопровождаемость
От: IID Россия  
Дата: 03.03.17 17:15
Оценка: +2 :)))
Здравствуйте, Gattaka, Вы писали:

G>сейчас меня еще минусанет приверженец сопровождаемого кода и картина будет более полной.


Блин, и как теперь определиться, я умный или красивый ?
kalsarikännit
Re[4]: Эффективность VS Сопровождаемость
От: Gattaka Россия  
Дата: 03.03.17 17:16
Оценка:
Здравствуйте, IID, Вы писали:

IID>Блин, и как теперь определиться, я умный или красивый ?


Не хочу тебя расстраивать, но скорее всего ты страшный и глупый
Но это так, шутка. На самом деле вопрос понял. Большинство где-то посередки или даже находятся в противоречии. В частности по Монге, что я выше написал была позиция одного человека. Но этот же человек нагородил с помощью emit маппер сущностей типа для того чтобы быстро было. Другой вопрос, что если у тебя происходит эксепшен в этом маппере, то ничего не понятно.
Отредактировано 03.03.2017 17:20 Gattaka . Предыдущая версия . Еще …
Отредактировано 03.03.2017 17:19 Gattaka . Предыдущая версия .
Re[3]: Эффективность VS Сопровождаемость
От: Философ Ад http://vk.com/id10256428
Дата: 03.03.17 18:31
Оценка:
Здравствуйте, Gattaka, Вы писали:

G>Здравствуйте, Философ, Вы писали:


Ф>>ЗЫ: я в шоке.

G>Судя по вашей реакции вас в этой мясорубке изрядно молотило уже. Ну а так как вы приверженец эффективного кода, то набросились на меня с минусами. Ничего мне не привыкать, сейчас меня еще минусанет приверженец сопровождаемого кода и картина будет более полной.
G>И все же было бы неплохо если бы вы внимательнее читали исходное сообщение.

Нет, я просто думаю, что немного лучше понимаю, что такое сопровождаемость кода. Ещё раз попытаюсь донести:
существует такой суперпростой и примитивный язык "ассемблер": есть только примитивные операции, регистры и ячейчки памяти — никаких функторов, лямбд, ленивых вычислений, никаких видов наследования, никаких шаблонов, нет статических полей/полей инстанса — всё предельно просто "inc ebx; move [eax], ebx" — делает ровно то, что написано и ничего больше. Но людям почему-то на нём писать слолжно — понапридумывали всяких абракадабр, в которые далеко не каждый студент воткнёт, и далеко не каждый программист знает. Ассемблер — идеальный код: минимум нюансов, читать легко, написанное всегда однозначно, работает быстро. И тем не менее ассемблерные программы почему-то хуже сопровождаются нежели программы на ЯВУ. Вывод тут такой: простые инструменты и технологии никак не гарантирую сопровождаемости кода.
Файлы вместо БД я уже предлагал — там тоже самое.
Сопровождаемость — свойство самого кода, его структуризации и изоляции ошибок в нём. И хранимые процедуры хуже сопровождаются не потому что ими пытались увеличить скорость, и не потому что они внутри БД, а потому что языки СУБД имеют мало средств выразительности и плохую поддержку со стороны IDE'шек — те же CTE лет шесть назад всего появилсь.
Всё сказанное выше — личное мнение, если не указано обратное.
Re[4]: Эффективность VS Сопровождаемость
От: Gattaka Россия  
Дата: 03.03.17 18:50
Оценка:
Здравствуйте, Философ, Вы писали:

Ф>Нет, я просто думаю, что немного лучше понимаю, что такое сопровождаемость кода. Ещё раз попытаюсь донести:

Ф>существует такой суперпростой и примитивный язык "ассемблер": есть только примитивные операции, регистры и ячейчки памяти — никаких функторов, лямбд, ленивых вычислений, никаких видов наследования, никаких шаблонов, нет статических полей/полей инстанса — всё предельно просто "inc ebx; move [eax], ebx" — делает ровно то, что написано и ничего больше. Но людям почему-то на нём писать слолжно — понапридумывали всяких абракадабр, в которые далеко не каждый студент воткнёт, и далеко не каждый программист знает. Ассемблер — идеальный код: минимум нюансов, читать легко, написанное всегда однозначно, работает быстро. И тем не менее ассемблерные программы почему-то хуже сопровождаются нежели программы на ЯВУ.
Все верно.

Ф> Вывод тут такой: простые инструменты и технологии никак не гарантирую сопровождаемости кода.

А вот тут стоп! Простые? У вас программа на Си положим 1000 строк кода превращается в 20000 кода на асемблере. Так что проще 1000 строчек или 20000. Конечно на Си программа проще. Си — простой. Ассемблер элементраный и именно поэтому сложный.
Но часто получается не так эффективно если бы мы напряглись на недельку заперлись и налабали на чистом асемблере. Мы приносим в жертву немного эффективности ради сопровождаемости и удобства. На Си вы в несколько раз быстрее напишите то что требуется, а также сможете быстро внести правки в существующий код.

Ф>Файлы вместо БД я уже предлагал — там тоже самое.

Файлы вместо БД это как ассемблер вместо Си. БД ведь базируется на файлах в конечном итоге. Ровно как и Си базируется на ассемблере. Так что в данном случае вы как раз копаете в противоположном направлении.

Ф>Сопровождаемость — свойство самого кода, его структуризации и изоляции ошибок в нём. И хранимые процедуры хуже сопровождаются не потому что ими пытались увеличить скорость, и не потому что они внутри БД, а потому что языки СУБД имеют мало средств выразительности и плохую поддержку со стороны IDE'шек — те же CTE лет шесть назад всего появилсь.

Ну а какая разница почему ХП хуже сопровождаются. IDE или инструментальные средства, важен сам факт и люди выбирают Linq2DB. Потому что под дебагером могут в тесте смотреть что происходит. Другой вопрос что здесь возникает лишний трафик между базой и сервером приложений. Ну так на это просто забивают, т.е. приносят в жерту эффективность ради удобства и сопровождаемости.
SQL плохо структурируется, copy paste в нем обычное дело.
Отредактировано 03.03.2017 18:50 Gattaka . Предыдущая версия .
Re[5]: Эффективность VS Сопровождаемость
От: Философ Ад http://vk.com/id10256428
Дата: 03.03.17 19:02
Оценка:
Здравствуйте, Gattaka, Вы писали:

Ф>> Вывод тут такой: простые инструменты и технологии никак не гарантирую сопровождаемости кода.

G>А вот тут стоп! Простые? У вас программа на Си положим 1000 строк кода превращается в 20000 кода на асемблере. Так что проще 1000 строчек или 20000. Конечно на Си программа проще. Си — простой.

А что же это мы на C++ перешли? Почему на си не писать — он же проще? Зачем нам миллиард способов отстрелить себе ногу? Давайте на си — там всего лишь миллион!

Да и вообще...

«Си» позволяет очень просто выстрелить себе в ногу. На «Си++» сделать это сложнее, но, когда вам это удается, ногу отрывает полностью.

Вот только я с автором не согласен по этому вопросу.

Ф>>Сопровождаемость — свойство самого кода, его структуризации и изоляции ошибок в нём. И хранимые процедуры хуже сопровождаются не потому что ими пытались увеличить скорость, и не потому что они внутри БД, а потому что языки СУБД имеют мало средств выразительности и плохую поддержку со стороны IDE'шек — те же CTE лет шесть назад всего появилсь.

G>...важен сам факт и люди выбирают Linq2DB. Потому что под дебагером могут в тесте смотреть что происходит.

Сдаётся мне, что не поэтому.
Всё сказанное выше — личное мнение, если не указано обратное.
Re[6]: Эффективность VS Сопровождаемость
От: Gattaka Россия  
Дата: 03.03.17 19:39
Оценка:
Здравствуйте, Философ, Вы писали:

Ф>Здравствуйте, Gattaka, Вы писали:


Ф>>> Вывод тут такой: простые инструменты и технологии никак не гарантирую сопровождаемости кода.

G>>А вот тут стоп! Простые? У вас программа на Си положим 1000 строк кода превращается в 20000 кода на асемблере. Так что проще 1000 строчек или 20000. Конечно на Си программа проще. Си — простой.
Ф>А что же это мы на C++ перешли? Почему на си не писать — он же проще? Зачем нам миллиард способов отстрелить себе ногу? Давайте на си — там всего лишь миллион!
Для больших программ еще проще. Потому что есть классы. Именно для больших программ. Для маленьких да — пишите на Си и все будет ок. С++ будет проще за счет абстраций и переиспользования.

Ф>Да и вообще...

Ф>

«Си» позволяет очень просто выстрелить себе в ногу. На «Си++» сделать это сложнее, но, когда вам это удается, ногу отрывает полностью.

Ф>Вот только я с автором не согласен по этому вопросу.

Ф>>>Сопровождаемость — свойство самого кода, его структуризации и изоляции ошибок в нём. И хранимые процедуры хуже сопровождаются не потому что ими пытались увеличить скорость, и не потому что они внутри БД, а потому что языки СУБД имеют мало средств выразительности и плохую поддержку со стороны IDE'шек — те же CTE лет шесть назад всего появилсь.

G>>...важен сам факт и люди выбирают Linq2DB. Потому что под дебагером могут в тесте смотреть что происходит.

Ф>Сдаётся мне, что не поэтому.

А почему?
Re[3]: Эффективность VS Сопровождаемость
От: ry Россия  
Дата: 03.03.17 19:43
Оценка: 1 (1) +1
Здравствуйте, Gattaka, Вы писали:

G>Критерий правильности?

Очень простой: соответствие ТЗ, согласованному с заказчиком.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.