Re: Эффективность VS Сопровождаемость
От: Слава  
Дата: 03.03.17 20:01
Оценка: +1
Здравствуйте, Gattaka, Вы писали:

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


Автоматически сделать из красивого кода быстрый — может только компилятор. А компилятор дописывать никто и нигде не берётся, это дико сложное занятие потому что.

Лично меня бесит код, где программист делает кучу вложенных вызовов/тернарных операторов или строит какие-то длинные навороты на linq, не думая о возможной отладке этого. Введённые в код промежуточные переменные типа var x = ... никак не повлияют на производительность, но позволят в случае проблем хотя бы добавить отладочную печать. Проблема здесь больше психологическая — см. как мощны мои лапищи, кто-то привык переть, как трактор и не думать о последствиях. А что, лапищи у него действительно мощны, отлаживать-то другие будут.
Re[4]: Эффективность VS Сопровождаемость
От: Gattaka Россия  
Дата: 04.03.17 03:14
Оценка:
Здравствуйте, ry, Вы писали:

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


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

ry>Очень простой: соответствие ТЗ, согласованному с заказчиком.
В ТЗ часто ни слова про производительность. Большинство заказчиков наивные ребята в этом плане
Re[5]: Эффективность VS Сопровождаемость
От: ry Россия  
Дата: 04.03.17 04:30
Оценка:
Здравствуйте, Gattaka, Вы писали:

G>В ТЗ часто ни слова про производительность. Большинство заказчиков наивные ребята в этом плане

Про "часто" и "большинство" ты сильно загнул — я вообще не встречал таковых. Но если вдруг, то адекватный подрядчик должен сам внести такой раздел в ТЗ и согласовать его с заказчиком. Но если вдруг, то уж во внутренних документах.
Re: Эффективность VS Сопровождаемость
От: elmal  
Дата: 04.03.17 05:08
Оценка: +2
Здравствуйте, Gattaka, Вы писали:

G>Коллеги,

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

Под либами понимаются ни черта не либы фреймворка. Ибо они и так написаны. Под либами понимается прослойка между бизнес логикой и фреймворком, причем такая прослойка, которая позволяет эффективно решать абстрактные бизнес задачи, заточенные под предполагаемую предметную область. Эффективно и сопровождаемо, то есть для бизнес логики пишется минимум кода, весь код относится только в бизнес логике и этот код короче и более структурирован, чем та каша, которую написал аналитик. В либах есть нагруженные места, есть ненагруженные. Для нагруженных мест делаем эффективно, для всех остальных мест — сопровождаемо.

И все, никакого противоречия. Проблема в том, что минимум 90 процентов называющих себя программистами либы не пишут вообще. И кодируют бизнес логику вместе с тем кодом, который библиотечный. А тот код, который должен быть библиотечный — копипастят с небольшими изменениями. Ну в потом начинается пипец, но тем, кто этот пипец организовал, уже пофигу, ибо они работают давно в другом месте, ну и так как они детали не изолировали, а копипастили изо дня в день, на собеседованиях легче, они эти детали лучше помнят .
Re[6]: Эффективность VS Сопровождаемость
От: Gattaka Россия  
Дата: 04.03.17 08:05
Оценка: :)
Здравствуйте, ry, Вы писали:

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


G>>В ТЗ часто ни слова про производительность. Большинство заказчиков наивные ребята в этом плане

ry>Про "часто" и "большинство" ты сильно загнул — я вообще не встречал таковых. Но если вдруг, то адекватный подрядчик должен сам внести такой раздел в ТЗ и согласовать его с заказчиком. Но если вдруг, то уж во внутренних документах.
Не-е-е-е-е ты спалился совсем в другом Фраза ТЗ подписанное заказчиком. У тут заказчик попал
Re: Эффективность VS Сопровождаемость
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.03.17 16:39
Оценка: +1
Здравствуйте, Gattaka, Вы писали:

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


Программисты делятся на другие лагеря. Одни решают реально возникающие проблемы, а это может быть как эффективность, так и сопровождаемость, другие решают проблемы диктуемые своим Эго, и это так же может быть как эффективность, так и сопровождаемость

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


Нет противоречия, есть путаница в твоем тексте.

1 Эффективность это общее слово, означает эффект поделить на затраты. Пудозреваю ты имел ввиду расход ресурсов.
2 Сопровождаемость — это эффективность сопровождения, то есть, эффект — выпуск следующих версий обходится низкой ценой.

Оба этих понятия означают экономику проекта. Вместе с приоритетами получается так — при конфликте интересов(требований) решаем в пользу выбраного направления.

Сопровождение это, например, возможность посадить студента и иметь гаранти, что он легко и непринужденно сможет переписать хоть всю бизнеслогику. Решение — писать простой читабельный код, даже если это кое где повредит расходу ресурсов. Пример — нарисовать кнопку — съест 1мб памяти, хер с ним, абы код был простой.

Расход ресурсов — пиши как угодно, лишь бы цель была достигнута. Пример — нарисовать кнопку расходуя 0 доп. памяти и 0 процессора, как будет выглядеть код, неважно, ибо ресурсов свободных вообще нет. Поймет ли этот код студент, дело десятое.

Еще пример, шоб понянее было. Если ты хочешь шоб в кухню не было двери, а была арка ибо это круто и всё такое, в детстве у тебя так и было. Кул. И при этом хочешь, что бы запахи не проникали в квартиру, даже если вентиляция не работает, а дети не слышали как ты с женой ругаешься на кухе. Противоречие ? Противоречие. Где именно ? У тебя в голове. Опаньки!

Ну и надо вспомнить, что приоритеты разработки могут быть совсем другими. Например — переносимость на другие платформы. Это похоже на сопровождаемость, но сильно отдалённо.
Re: Эффективность VS Сопровождаемость
От: VladCore  
Дата: 16.03.17 20:09
Оценка:
Здравствуйте, Gattaka, Вы писали:

G>Коллеги,

G>На мой взгляд программисты делятся на два лагеря: приверженцы эффективного кода и приверженцы сопровождаемоего кода. Эти два подхода зачастую противоречат друг другу — отсюда и возникают споры. В частности писать ли бизнес-логику в хранимых процедурах? С точки зрения эффективности это идеальный вариант, с точки зрения сопровождаемости — худший. Нельзя тестировать, нет наследования и intellicense. Да и вобще луче использовать MongoDB. Ее любой может освоить за день, пихаешь себе джейсон и не паришься. Тогда база данных выступает как хранилище да и только.
G>Понятно, что в жизни полно промежуточных вариантов. Например, Linq2DB у вас и эффективность кода нормальная и сопровождаемость отличная. Но не всегда это реализуемо. Либо хинта какого-то нет либо поддержки СУБД какой-то.
G>Еще пример — посмотрите доклады ребят из команды Решарпера. Там в C# им приходится делать выкрутасы, которые явно бьют по сопровождаемости в пользу производительности.
G>Собственно вопрос стоит в том почему возникло это противречие? Почему эффективность != сопровождаемость?

Вы не написали критерии эффективности.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.