среда, 14 мая 2014 г.
Ссылка. Критерии плохого дизайна
http://sergeyteplyakov.blogspot.ru/2013/01/blog-post_29.html
"Проблема старого дизайна это - проблема старого человека, если можно так метафорично выразиться :). Если дизайн не омолаживать, не лечить, то в конце концов, это будет неподвижный монстр, малейшее телодвижение которого приводит, к тому, что у него то тут не работает, то там что-то отваливается.
А теперь подробнее про косметологию в программировании, гг... :) Продукт со временем эволюционирует, в него добавляется новый функционал и адаптируется/изменяется старый. В первую очередь меняется код. И если всегда меняется только код, то скоро "пациент будет скорее мертв, чем жив". Т.к. за изменениями кода по необходимости должны следовать изменения в дизайне, и может в архитектуре.
Текущее состояние каждой абстракции продукта (код, дизайн, архитектура) должны соответствовать идеям и обязанностям, которые были на этот уровень возложены. Когда текущее состояние уровня абстракции не соответствует, тем идеям и обязанностям, которые были заложены, то на этом уровне необходимо сделать изменения. Иначе возникает "Технический долг".
Возникновение "технического долга" происходить из-за того, что менеджмент компании не знает внутреннего состояния продукта и процесса разработки софта. Из двух предложенных программистами вариантов: "быстрый " и "правильный", руководство очень редко выбирает "правильный" и чаще выбирает "быстрый", потому что работает сейчас, а внутреннее качество нас не особо интересует.
Так вот костыли плохого дизайна, прежде всего растут от корявого руководства с рукавами в районе пояса, а не от плохих программистов. При том что последних, можно отсеять при приеме, как-то научить или отстранить от изменений в дизайне."
есть один БОЛЬШОЙ фактор - "программист должен САМ вырасти над собой"...
и НИКТО ему в этом не поможет...
это я по своему опыту говорю
ЛЮБОГО программиста можно "учить" умно и "правильно" и он будет СЛУШАТЬ, но он НЕ СТАНЕТ "копией вас", он САМ ВЫРАСТЕТ... Сам "набив свои шишки".. И только так...
"Проблема старого дизайна это - проблема старого человека, если можно так метафорично выразиться :). Если дизайн не омолаживать, не лечить, то в конце концов, это будет неподвижный монстр, малейшее телодвижение которого приводит, к тому, что у него то тут не работает, то там что-то отваливается.
А теперь подробнее про косметологию в программировании, гг... :) Продукт со временем эволюционирует, в него добавляется новый функционал и адаптируется/изменяется старый. В первую очередь меняется код. И если всегда меняется только код, то скоро "пациент будет скорее мертв, чем жив". Т.к. за изменениями кода по необходимости должны следовать изменения в дизайне, и может в архитектуре.
Текущее состояние каждой абстракции продукта (код, дизайн, архитектура) должны соответствовать идеям и обязанностям, которые были на этот уровень возложены. Когда текущее состояние уровня абстракции не соответствует, тем идеям и обязанностям, которые были заложены, то на этом уровне необходимо сделать изменения. Иначе возникает "Технический долг".
Возникновение "технического долга" происходить из-за того, что менеджмент компании не знает внутреннего состояния продукта и процесса разработки софта. Из двух предложенных программистами вариантов: "быстрый " и "правильный", руководство очень редко выбирает "правильный" и чаще выбирает "быстрый", потому что работает сейчас, а внутреннее качество нас не особо интересует.
Так вот костыли плохого дизайна, прежде всего растут от корявого руководства с рукавами в районе пояса, а не от плохих программистов. При том что последних, можно отсеять при приеме, как-то научить или отстранить от изменений в дизайне."
есть один БОЛЬШОЙ фактор - "программист должен САМ вырасти над собой"...
и НИКТО ему в этом не поможет...
это я по своему опыту говорю
ЛЮБОГО программиста можно "учить" умно и "правильно" и он будет СЛУШАТЬ, но он НЕ СТАНЕТ "копией вас", он САМ ВЫРАСТЕТ... Сам "набив свои шишки".. И только так...
вторник, 13 мая 2014 г.
Ссылка. Модульный тест: определение
http://sergeyteplyakov.blogspot.ru/2014/05/unit-testthe-definition.html
Особенно вот что понравилось:
"DIP - это не решение проблемы в данном случае. Это ее причина. Подробнее - в статье "Критика DIP""
"авторы идеи являются более разумными и прагматичными людьми, нежели ярые сторонники этой идеи"
Особенно вот что понравилось:
"DIP - это не решение проблемы в данном случае. Это ее причина. Подробнее - в статье "Критика DIP""
"авторы идеи являются более разумными и прагматичными людьми, нежели ярые сторонники этой идеи"
И ещё к вопросу об ARC
По мотивам - http://programmingmindstream.blogspot.ru/2014/05/arc.html
Пусть мы печатаем документ.
И пусть мы делаем это используя не TCanvas, а ICanvas.
И пусть "машина печати" имеет свойство Canvas типа ICanvas.
Так вот.
500 страниц Налогового Кодекса с 40-ка параграфами на страницу приводит вот к чему.
Как минимум для каждого параграфа мы получаем канву и сохраняем её в локальную переменную.
Это - 500*40*2 = 40000 операций InterlockedIncrement/Decrement. За "просто так".
Понятное дело, что можно и по-другому оптимизировать. Например не получать канву "на каждый чих". И при этом не забывать ставить модификатор const перед ВХОДНЫМИ интерфейсными параметрами. Ибо если не поставить const то имеем пару InterlockedIncrement/Decrement.
Пусть мы печатаем документ.
И пусть мы делаем это используя не TCanvas, а ICanvas.
И пусть "машина печати" имеет свойство Canvas типа ICanvas.
Так вот.
500 страниц Налогового Кодекса с 40-ка параграфами на страницу приводит вот к чему.
Как минимум для каждого параграфа мы получаем канву и сохраняем её в локальную переменную.
Это - 500*40*2 = 40000 операций InterlockedIncrement/Decrement. За "просто так".
Понятное дело, что можно и по-другому оптимизировать. Например не получать канву "на каждый чих". И при этом не забывать ставить модификатор const перед ВХОДНЫМИ интерфейсными параметрами. Ибо если не поставить const то имеем пару InterlockedIncrement/Decrement.
К вопросу об ARC...
Я тут закончил "большую переделку".
"Зачем-то"...
Избавился от использования интерфейсов на большинстве базовых классов. В пользу использования примесей и абстрактных классов.
Что сказать. Результат - превзошёл ожидания.
Производительность увеличилась на 30%. (Естественно далеко не на ВСЕХ прецедентах)
И это только за счёт отказа от "паразитного" подсчёта ссылок "на каждый чих".
(Читай отказался от InterlockedIncrement/Decrement)
Только и всего.
Наиболее заметно это на "операциях ввода/вывода", а ОСОБЕННО - отрисовки данных на канве.
Вот так вот...
Теперь я погружён в УНЫНИЕ...
Ведь НАМ "светит ARC"...
Всем и "в вену"...
Где всё те же - "паразитный подсчёт ссылок" и InterlockedIncrement/Decrement.
Светит.
И куда от этого уйти? Или к тому моменту "рост мощностей" нивелирует данные потери?
P.S. Кстати.. Есть вопрос к ЗНАТОКАМ. А атрибут [Weak] для локальных переменных работает?
P.P.S. Возвращаясь к интерфейсам... Хочу отметить, что отказ от них позволил съэкономить как минимум по 4-ре байта на каждый класс (где был произведён отказ от интерфейсов). Немного.
Налоговый кодекс занимает примерно 500 страниц. На каждой странице примерно 40 параграфов. Соответственно на НК съэкономлено примерно 80 Кб. Немного.
"Зачем-то"...
Избавился от использования интерфейсов на большинстве базовых классов. В пользу использования примесей и абстрактных классов.
Что сказать. Результат - превзошёл ожидания.
Производительность увеличилась на 30%. (Естественно далеко не на ВСЕХ прецедентах)
И это только за счёт отказа от "паразитного" подсчёта ссылок "на каждый чих".
(Читай отказался от InterlockedIncrement/Decrement)
Только и всего.
Наиболее заметно это на "операциях ввода/вывода", а ОСОБЕННО - отрисовки данных на канве.
Вот так вот...
Теперь я погружён в УНЫНИЕ...
Ведь НАМ "светит ARC"...
Всем и "в вену"...
Где всё те же - "паразитный подсчёт ссылок" и InterlockedIncrement/Decrement.
Светит.
И куда от этого уйти? Или к тому моменту "рост мощностей" нивелирует данные потери?
P.S. Кстати.. Есть вопрос к ЗНАТОКАМ. А атрибут [Weak] для локальных переменных работает?
P.P.S. Возвращаясь к интерфейсам... Хочу отметить, что отказ от них позволил съэкономить как минимум по 4-ре байта на каждый класс (где был произведён отказ от интерфейсов). Немного.
Налоговый кодекс занимает примерно 500 страниц. На каждой странице примерно 40 параграфов. Соответственно на НК съэкономлено примерно 80 Кб. Немного.
понедельник, 5 мая 2014 г.
Подписаться на:
Сообщения (Atom)