Коллеги,
На мой взгляд программисты делятся на два лагеря: приверженцы эффективного кода и приверженцы сопровождаемоего кода. Эти два подхода зачастую противоречат друг другу — отсюда и возникают споры. В частности писать ли бизнес-логику в хранимых процедурах? С точки зрения эффективности это идеальный вариант, с точки зрения сопровождаемости — худший. Нельзя тестировать, нет наследования и intellicense. Да и вобще луче использовать MongoDB. Ее любой может освоить за день, пихаешь себе джейсон и не паришься. Тогда база данных выступает как хранилище да и только.
Понятно, что в жизни полно промежуточных вариантов. Например, Linq2DB у вас и эффективность кода нормальная и сопровождаемость отличная. Но не всегда это реализуемо. Либо хинта какого-то нет либо поддержки СУБД какой-то.
Еще пример — посмотрите доклады ребят из команды Решарпера. Там в C# им приходится делать выкрутасы, которые явно бьют по сопровождаемости в пользу производительности.
Собственно вопрос стоит в том почему возникло это противречие? Почему эффективность != сопровождаемость?
Здравствуйте, Gattaka, Вы писали:
G>Почему эффективность != сопровождаемость?
— Плохо поставленные процессы
— Разный уровень разработчиков
— Отсутствие или плохая/неактуальная документация
Здравствуйте, ry, Вы писали:
ry>Здравствуйте, Gattaka, Вы писали:
G>>Почему эффективность != сопровождаемость? ry>- Плохо поставленные процессы ry>- Разный уровень разработчиков ry>- Отсутствие или плохая/неактуальная документация
Ну это все влияет, конечно. Но ведь спор между С++никами и C#стами тоже имеет такую природу. Одни говорят зато у нас программы офигенно производительные, другие парируют что пока изучишь ваш язык — обалдеешь. NodeJS еще проще, но и с произодительностью еще хуже. Тут дело не только в процессах, причины глубже.
Здравствуйте, Gattaka, Вы писали:
G>Тут дело не только в процессах, причины глубже.
Честно говоря, не очень понимаю, что значит "глубже".
Разработка, как впрочем и любая другая деятельность, — это процессы (сложные или простые, тяжёлые или лёгкие, формальные или нет)
Если плохо с производительностью, то с большей вероятностью это происходит от низкого уровня алгоритмической подготовки разработчиков.
Если плохо с сопровождаемостью, то это — 100% плохо поставленные процессы.
Куда нужно погрузиться глубже?
Здравствуйте, Gattaka, Вы писали:
G>Коллеги, G>На мой взгляд программисты делятся на два лагеря: приверженцы эффективного кода и приверженцы сопровождаемоего кода.
В чём-то это "Пять миров" Спольски на новый лад.
Я бы ещё добавил к этому аспект типа "у нас на этом 5 лет один человек сидит и все вопросы к нему" и антипод — "есть халтура добавить сюда новый блок, времени неделя вместе с тестированием у заказчика". Принципы типа SOLID на 99% предназначены для второго случая — не просто сопровождаемость, а сопровождаемость в условиях гарантированного цейтнота.
G>Собственно вопрос стоит в том почему возникло это противречие? Почему эффективность != сопровождаемость?
Здравствуйте, Gattaka, Вы писали:
G>Собственно вопрос стоит в том почему возникло это противречие? Почему эффективность != сопровождаемость?
Потому что чтобы выжать из железа максимум, приходится на уши вставать, и читать/писать такой код нелегко. Кроме того, удобный для человека код — максимально обобщенный, а удобный для компьютера — наоборот, максимально конкретный.
К счастью, в реальной программе вопросы производительности обычно стоят в очень небольшой ее части, а в прочих частях производительность не слишком важна. Кроме того, быстрая часть редко бывает сложной, а сложная — быстрой. Поэтому писать эти части надо по-разному, и не надо жертвовать читаемостью или эффективностью ради единообразия.
Здравствуйте, ry, Вы писали:
ry>Если плохо с производительностью, то с большей вероятностью это происходит от низкого уровня алгоритмической подготовки разработчиков.
Или наоборот, от слишком высокого. Heap sort на массиве из 5-и чисел будет работать медленнее, чем тривиальная сортировка пузырьком, и линейный поиск на небольшом объеме данных работает быстрее, чем хеширование или двоичное дерево.
К сожалению, многие программисты, познав для себя интересные алгоритмы, стесняются применять простые алгоритмы там, где это уместно. Я тоже, бывает, этим грешу
G>На мой взгляд программисты делятся на два лагеря: приверженцы эффективного кода и приверженцы сопровождаемоего кода.
Есть еще третий лагерь, небольшая группа, вымирающий вид, практически: приверженцы правильно работающего кода. Но о них не будем — кому они нужны, эти правильно работающие программы...
Здравствуйте, Dym On, Вы писали:
G>>На мой взгляд программисты делятся на два лагеря: приверженцы эффективного кода и приверженцы сопровождаемоего кода. DO>Есть еще третий лагерь, небольшая группа, вымирающий вид, практически: приверженцы правильно работающего кода. Но о них не будем — кому они нужны, эти правильно работающие программы...
Критерий правильности?
Здравствуйте, Gattaka, Вы писали:
G>В частности писать ли бизнес-логику в хранимых процедурах? С точки зрения эффективности это идеальный вариант, с точки зрения сопровождаемости — худший.
Да, согласен, они сопровождаются крайне плохо. Но иногда это почти единственный вариант написать всегда корректно работающую программу.
G>Нельзя тестировать...
Можно.
G>Да и вобще луче использовать MongoDB.
И этот человек говорит о сопровождаемости .... Да чо уж там, пишите сразу в файл: в файлы умеют писать все — этому вообще на первом курсе учатся. А чтоб вообще проще было — в текстовые. А чтоб ещё проще — в один файл, чтоб "сразу всё перед глазами"(с). Файл сразу целиком в память зачитывайте — так проще (про эффективность не надо — пользователь ещё памяти докупит, если надо).
G>На мой взгляд программисты делятся на два лагеря: приверженцы эффективного кода и приверженцы сопровождаемоего кода.
Откажитесь от многопоточности и вообще параллельных вычислений — корректную синхронизацию не все умеют. Не все даже знают что такое volatile и когда его писать нужно, а уж про барьеры многие вообще никогда не слышали. К тому же всякие локи сильно код портят — он становится неспопровождаемым (на 60 строк алгоритма иногда 120 всяких локов-анлоков/барьеров даблчеков и прочей магии).
А то, что иногда висит UI — ничего страшного, юзер подождёт — не проблема, можно часики песочные повесить на курсор, чтоб пользователя не смущать.
Зато однопоточная, однопроцессная софтина проще в сопровождении чем многопоточная, да ещё и со всякими сервисами.
ЗЫ: я в шоке.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>ЗЫ: я в шоке.
Судя по вашей реакции вас в этой мясорубке изрядно молотило уже. Ну а так как вы приверженец эффективного кода, то набросились на меня с минусами. Ничего мне не привыкать, сейчас меня еще минусанет приверженец сопровождаемого кода и картина будет более полной.
И все же было бы неплохо если бы вы внимательнее читали исходное сообщение.
Здравствуйте, IID, Вы писали:
IID>Блин, и как теперь определиться, я умный или красивый ?
Не хочу тебя расстраивать, но скорее всего ты страшный и глупый
Но это так, шутка. На самом деле вопрос понял. Большинство где-то посередки или даже находятся в противоречии. В частности по Монге, что я выше написал была позиция одного человека. Но этот же человек нагородил с помощью emit маппер сущностей типа для того чтобы быстро было. Другой вопрос, что если у тебя происходит эксепшен в этом маппере, то ничего не понятно.
Здравствуйте, Gattaka, Вы писали:
G>Здравствуйте, Философ, Вы писали:
Ф>>ЗЫ: я в шоке. G>Судя по вашей реакции вас в этой мясорубке изрядно молотило уже. Ну а так как вы приверженец эффективного кода, то набросились на меня с минусами. Ничего мне не привыкать, сейчас меня еще минусанет приверженец сопровождаемого кода и картина будет более полной. G>И все же было бы неплохо если бы вы внимательнее читали исходное сообщение.
Нет, я просто думаю, что немного лучше понимаю, что такое сопровождаемость кода. Ещё раз попытаюсь донести:
существует такой суперпростой и примитивный язык "ассемблер": есть только примитивные операции, регистры и ячейчки памяти — никаких функторов, лямбд, ленивых вычислений, никаких видов наследования, никаких шаблонов, нет статических полей/полей инстанса — всё предельно просто "inc ebx; move [eax], ebx" — делает ровно то, что написано и ничего больше. Но людям почему-то на нём писать слолжно — понапридумывали всяких абракадабр, в которые далеко не каждый студент воткнёт, и далеко не каждый программист знает. Ассемблер — идеальный код: минимум нюансов, читать легко, написанное всегда однозначно, работает быстро. И тем не менее ассемблерные программы почему-то хуже сопровождаются нежели программы на ЯВУ. Вывод тут такой: простые инструменты и технологии никак не гарантирую сопровождаемости кода.
Файлы вместо БД я уже предлагал — там тоже самое.
Сопровождаемость — свойство самого кода, его структуризации и изоляции ошибок в нём. И хранимые процедуры хуже сопровождаются не потому что ими пытались увеличить скорость, и не потому что они внутри БД, а потому что языки СУБД имеют мало средств выразительности и плохую поддержку со стороны IDE'шек — те же CTE лет шесть назад всего появилсь.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Нет, я просто думаю, что немного лучше понимаю, что такое сопровождаемость кода. Ещё раз попытаюсь донести: Ф>существует такой суперпростой и примитивный язык "ассемблер": есть только примитивные операции, регистры и ячейчки памяти — никаких функторов, лямбд, ленивых вычислений, никаких видов наследования, никаких шаблонов, нет статических полей/полей инстанса — всё предельно просто "inc ebx; move [eax], ebx" — делает ровно то, что написано и ничего больше. Но людям почему-то на нём писать слолжно — понапридумывали всяких абракадабр, в которые далеко не каждый студент воткнёт, и далеко не каждый программист знает. Ассемблер — идеальный код: минимум нюансов, читать легко, написанное всегда однозначно, работает быстро. И тем не менее ассемблерные программы почему-то хуже сопровождаются нежели программы на ЯВУ.
Все верно.
Ф> Вывод тут такой: простые инструменты и технологии никак не гарантирую сопровождаемости кода.
А вот тут стоп! Простые? У вас программа на Си положим 1000 строк кода превращается в 20000 кода на асемблере. Так что проще 1000 строчек или 20000. Конечно на Си программа проще. Си — простой. Ассемблер элементраный и именно поэтому сложный.
Но часто получается не так эффективно если бы мы напряглись на недельку заперлись и налабали на чистом асемблере. Мы приносим в жертву немного эффективности ради сопровождаемости и удобства. На Си вы в несколько раз быстрее напишите то что требуется, а также сможете быстро внести правки в существующий код.
Ф>Файлы вместо БД я уже предлагал — там тоже самое.
Файлы вместо БД это как ассемблер вместо Си. БД ведь базируется на файлах в конечном итоге. Ровно как и Си базируется на ассемблере. Так что в данном случае вы как раз копаете в противоположном направлении.
Ф>Сопровождаемость — свойство самого кода, его структуризации и изоляции ошибок в нём. И хранимые процедуры хуже сопровождаются не потому что ими пытались увеличить скорость, и не потому что они внутри БД, а потому что языки СУБД имеют мало средств выразительности и плохую поддержку со стороны IDE'шек — те же CTE лет шесть назад всего появилсь.
Ну а какая разница почему ХП хуже сопровождаются. IDE или инструментальные средства, важен сам факт и люди выбирают Linq2DB. Потому что под дебагером могут в тесте смотреть что происходит. Другой вопрос что здесь возникает лишний трафик между базой и сервером приложений. Ну так на это просто забивают, т.е. приносят в жерту эффективность ради удобства и сопровождаемости.
SQL плохо структурируется, copy paste в нем обычное дело.
Здравствуйте, Gattaka, Вы писали:
Ф>> Вывод тут такой: простые инструменты и технологии никак не гарантирую сопровождаемости кода. G>А вот тут стоп! Простые? У вас программа на Си положим 1000 строк кода превращается в 20000 кода на асемблере. Так что проще 1000 строчек или 20000. Конечно на Си программа проще. Си — простой.
А что же это мы на C++ перешли? Почему на си не писать — он же проще? Зачем нам миллиард способов отстрелить себе ногу? Давайте на си — там всего лишь миллион!
Да и вообще...
«Си» позволяет очень просто выстрелить себе в ногу. На «Си++» сделать это сложнее, но, когда вам это удается, ногу отрывает полностью.
Вот только я с автором не согласен по этому вопросу.
Ф>>Сопровождаемость — свойство самого кода, его структуризации и изоляции ошибок в нём. И хранимые процедуры хуже сопровождаются не потому что ими пытались увеличить скорость, и не потому что они внутри БД, а потому что языки СУБД имеют мало средств выразительности и плохую поддержку со стороны IDE'шек — те же CTE лет шесть назад всего появилсь. G>...важен сам факт и люди выбирают Linq2DB. Потому что под дебагером могут в тесте смотреть что происходит.
Сдаётся мне, что не поэтому.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, Gattaka, Вы писали:
Ф>>> Вывод тут такой: простые инструменты и технологии никак не гарантирую сопровождаемости кода. G>>А вот тут стоп! Простые? У вас программа на Си положим 1000 строк кода превращается в 20000 кода на асемблере. Так что проще 1000 строчек или 20000. Конечно на Си программа проще. Си — простой. Ф>А что же это мы на C++ перешли? Почему на си не писать — он же проще? Зачем нам миллиард способов отстрелить себе ногу? Давайте на си — там всего лишь миллион!
Для больших программ еще проще. Потому что есть классы. Именно для больших программ. Для маленьких да — пишите на Си и все будет ок. С++ будет проще за счет абстраций и переиспользования.
Ф>Да и вообще... Ф>
«Си» позволяет очень просто выстрелить себе в ногу. На «Си++» сделать это сложнее, но, когда вам это удается, ногу отрывает полностью.
Ф>Вот только я с автором не согласен по этому вопросу.
Ф>>>Сопровождаемость — свойство самого кода, его структуризации и изоляции ошибок в нём. И хранимые процедуры хуже сопровождаются не потому что ими пытались увеличить скорость, и не потому что они внутри БД, а потому что языки СУБД имеют мало средств выразительности и плохую поддержку со стороны IDE'шек — те же CTE лет шесть назад всего появилсь. G>>...важен сам факт и люди выбирают Linq2DB. Потому что под дебагером могут в тесте смотреть что происходит.
Ф>Сдаётся мне, что не поэтому.
А почему?