День девятьсот третий.
8 Признаков Того, Что Вы не Контролируете Техническую Сложность
Обладая почти 25-летним опытом работы в качестве консультанта, я помогаю организациям, работающим в области .NET, повышать квалификацию в разработке программного обеспечения, от идеи до производства. Во время таких визитов я тщательно изучаю их методы разработки, стандарты качества, принципы проектирования, инструменты, которые они используют, их конвейер развёртывания, динамику команды, процесс выработки требований и многое другое.
В этом посте рассмотрим проблемы, с которыми сталкиваются компании, в области контроля технической сложности. Это не только может вызвать ненужные задержки при создании новой функциональности, привести к оверинжинирингу и неоправданному усложнению системы, что поставит под угрозу простоту поддержки, но также затрудняет поиск опытных разработчиков, которые смогут справиться с такой сложностью. Вот пара примеров того, с чем я столкнулся.
1. Архитектура, не соответствующая функциональным и техническим требованиям. Иногда это происходит потому, что автор вдохновился новой технологией, фреймворком или другой хайповой штукой, о которой прочитал или узнал во время посещения популярной конференции по разработке ПО. Но я также встречал ситуации, когда совет архитекторов диктовал эталонную архитектуру, которой должны были соответствовать все системы.
2. Внедрение технологии, «потому что круто», потому что это помогает привлечь новый персонал, или просто потому, что руководство купилось на золотые горы, обещанные им разработчиками, поставщиками ПО или архитекторами.
3. Предоставление доступа к HTTP API или служебным конечным точкам другим командам или партнерам без контроля обязательств, которые необходимы в этом случае, например, чётко определённого управления версиями, обратной и прямой совместимости, надлежащей документации для разработчиков и т.п.
4. Команды, которые добавляют ненужную сложность, такую как чрезмерное использование абстракций и дополнительных уровней, не обязательных в текущих требованиях. Часто это происходит под предлогом «подготовки к будущему» или для того, чтобы сделать систему «более тестируемой» (обычно это называют попыткой «замокать» всё на свете).
5. Архитекторы и технические руководители, которые любят хвастаться архитектурными принципами, шаблонами проектирования и универсальными эвристиками, необходимыми для «создания лучшего программного обеспечения», но в итоге насаждают свои догматические убеждения. Проблема не в том, что эти принципы плохие, а в том, что у архитекторов не хватает опыта, чтобы понять контекст, в котором эти принципы применяются, а также их плюсы и минусы.
6. Дисбаланс между тактической и стратегической архитектурой, с краткосрочными решениями на одном конце шкалы и чрезвычайно амбициозными (и нереалистичными) воздушными замками - на другом.
7. Команды, которые изо всех сил пытаются понять и сопоставить зависимости между многими компонентами, строительными блоками, сервисами и продуктами, что приводит к сложным планам разработки, связанным с коммуникациями между командами.
8. Разработчики, которые не могут найти способ совместной работы над одним и тем же фрагментом функциональности, потому что не знают, как объединить усилия или разбить работу на относительно независимые задачи.
С какими из описанных (или не описанных) здесь проблем сталкивались вы в своей карьере?
Источник: https://ddoomen.medium.com/8-signals-that-you-dont-control-your-technical-complexity-87ac4ae66975
Автор оригинала – Dennis Doomen
8 Признаков Того, Что Вы не Контролируете Техническую Сложность
Обладая почти 25-летним опытом работы в качестве консультанта, я помогаю организациям, работающим в области .NET, повышать квалификацию в разработке программного обеспечения, от идеи до производства. Во время таких визитов я тщательно изучаю их методы разработки, стандарты качества, принципы проектирования, инструменты, которые они используют, их конвейер развёртывания, динамику команды, процесс выработки требований и многое другое.
В этом посте рассмотрим проблемы, с которыми сталкиваются компании, в области контроля технической сложности. Это не только может вызвать ненужные задержки при создании новой функциональности, привести к оверинжинирингу и неоправданному усложнению системы, что поставит под угрозу простоту поддержки, но также затрудняет поиск опытных разработчиков, которые смогут справиться с такой сложностью. Вот пара примеров того, с чем я столкнулся.
1. Архитектура, не соответствующая функциональным и техническим требованиям. Иногда это происходит потому, что автор вдохновился новой технологией, фреймворком или другой хайповой штукой, о которой прочитал или узнал во время посещения популярной конференции по разработке ПО. Но я также встречал ситуации, когда совет архитекторов диктовал эталонную архитектуру, которой должны были соответствовать все системы.
2. Внедрение технологии, «потому что круто», потому что это помогает привлечь новый персонал, или просто потому, что руководство купилось на золотые горы, обещанные им разработчиками, поставщиками ПО или архитекторами.
3. Предоставление доступа к HTTP API или служебным конечным точкам другим командам или партнерам без контроля обязательств, которые необходимы в этом случае, например, чётко определённого управления версиями, обратной и прямой совместимости, надлежащей документации для разработчиков и т.п.
4. Команды, которые добавляют ненужную сложность, такую как чрезмерное использование абстракций и дополнительных уровней, не обязательных в текущих требованиях. Часто это происходит под предлогом «подготовки к будущему» или для того, чтобы сделать систему «более тестируемой» (обычно это называют попыткой «замокать» всё на свете).
5. Архитекторы и технические руководители, которые любят хвастаться архитектурными принципами, шаблонами проектирования и универсальными эвристиками, необходимыми для «создания лучшего программного обеспечения», но в итоге насаждают свои догматические убеждения. Проблема не в том, что эти принципы плохие, а в том, что у архитекторов не хватает опыта, чтобы понять контекст, в котором эти принципы применяются, а также их плюсы и минусы.
6. Дисбаланс между тактической и стратегической архитектурой, с краткосрочными решениями на одном конце шкалы и чрезвычайно амбициозными (и нереалистичными) воздушными замками - на другом.
7. Команды, которые изо всех сил пытаются понять и сопоставить зависимости между многими компонентами, строительными блоками, сервисами и продуктами, что приводит к сложным планам разработки, связанным с коммуникациями между командами.
8. Разработчики, которые не могут найти способ совместной работы над одним и тем же фрагментом функциональности, потому что не знают, как объединить усилия или разбить работу на относительно независимые задачи.
С какими из описанных (или не описанных) здесь проблем сталкивались вы в своей карьере?
Источник: https://ddoomen.medium.com/8-signals-that-you-dont-control-your-technical-complexity-87ac4ae66975
Автор оригинала – Dennis Doomen
День девятьсот четвёртый. #BestPractices
Лучшие Практики Написания Комментариев к Коду. Начало
Знаменитый профессор MIT Хэл Абельсон сказал: «Программы должны писаться для того, чтобы быть прочитанными людьми и лишь на всякий случай - для выполнения машинами». Хотя он, возможно, намеренно недооценил важность исполнения кода, он чётко понимает, что у программ есть две очень разные аудитории. Компиляторы и интерпретаторы игнорируют комментарии и считают, что все синтаксически правильные программы одинаково просты для понимания. Читатели-люди сильно от них отличаются. Нам кажется, что одни программы труднее понять, чем другие, и мы ищем комментарии, которые помогут нам разобраться в них.
Существует множество ресурсов, помогающих программистам писать код лучше, вроде книг или статических анализаторов, но мало ресурсов для написания хороших комментариев. Количество комментариев в программе измерить легко, трудно измерить их качество, и эти два понятия не обязательно коррелируют. Написание и последующее поддержание комментариев - это расходы. Компилятор не проверяет ваши комментарии, поэтому невозможно определить их правильность. С другой стороны, он гарантирует, что компьютер делает именно то, что ему говорит ваш код. А плохой комментарий хуже, чем его отсутствие. Но было бы ошибкой впасть в другую крайность и никогда не писать комментарии. Вот несколько правил, которые помогут вам достичь золотой середины.
1. Комментарии не должны дублировать код
Многие начинающие программисты пишут слишком много комментариев, потому что их научили этому в школе. Кого-то учили добавлять комментарий к каждой закрытой скобке, чтобы указать, какой блок заканчивается:
Комментарии, которые не добавляют информации, имеют отрицательную ценность, потому что они:
- добавляют визуального беспорядка,
- требуют времени на написание и чтение,
- могут устаревать.
Канонический плохой пример:
2. Хорошие комментарии не оправдывают непонятный код.
Ещё одно неправильное использование комментариев - предоставление информации, которая должна быть в коде. Простой пример - когда кто-то называет переменную одной буквой, а затем добавляет комментарий, описывающий ее назначение:
Продолжение следует…
Источник: https://stackoverflow.blog/2021/07/05/best-practices-for-writing-code-comments/
Лучшие Практики Написания Комментариев к Коду. Начало
Знаменитый профессор MIT Хэл Абельсон сказал: «Программы должны писаться для того, чтобы быть прочитанными людьми и лишь на всякий случай - для выполнения машинами». Хотя он, возможно, намеренно недооценил важность исполнения кода, он чётко понимает, что у программ есть две очень разные аудитории. Компиляторы и интерпретаторы игнорируют комментарии и считают, что все синтаксически правильные программы одинаково просты для понимания. Читатели-люди сильно от них отличаются. Нам кажется, что одни программы труднее понять, чем другие, и мы ищем комментарии, которые помогут нам разобраться в них.
Существует множество ресурсов, помогающих программистам писать код лучше, вроде книг или статических анализаторов, но мало ресурсов для написания хороших комментариев. Количество комментариев в программе измерить легко, трудно измерить их качество, и эти два понятия не обязательно коррелируют. Написание и последующее поддержание комментариев - это расходы. Компилятор не проверяет ваши комментарии, поэтому невозможно определить их правильность. С другой стороны, он гарантирует, что компьютер делает именно то, что ему говорит ваш код. А плохой комментарий хуже, чем его отсутствие. Но было бы ошибкой впасть в другую крайность и никогда не писать комментарии. Вот несколько правил, которые помогут вам достичь золотой середины.
1. Комментарии не должны дублировать код
Многие начинающие программисты пишут слишком много комментариев, потому что их научили этому в школе. Кого-то учили добавлять комментарий к каждой закрытой скобке, чтобы указать, какой блок заканчивается:
if (x > 3) {
…
} // if
Некоторые преподаватели требовали от студентов комментировать каждую строчку кода. Хотя это может быть разумной политикой для совсем уж новичков, но такие комментарии похожи на ходунки для младенцев, и их следует удалять, как только вы научились ходить.Комментарии, которые не добавляют информации, имеют отрицательную ценность, потому что они:
- добавляют визуального беспорядка,
- требуют времени на написание и чтение,
- могут устаревать.
Канонический плохой пример:
i = i + 1; // Добавляем 1 к iКомментарий не несёт никакой информации, но повышает стоимость поддержки кода.
2. Хорошие комментарии не оправдывают непонятный код.
Ещё одно неправильное использование комментариев - предоставление информации, которая должна быть в коде. Простой пример - когда кто-то называет переменную одной буквой, а затем добавляет комментарий, описывающий ее назначение:
private static Node getBestChildNode(Node node) {
Node n; //кандидат на лучшего потомка
foreach (Node node in node.getChildren()) {
//обновляем n, если текущий лучше
if (n == null || utility(node) > utility(n))
n = node;
}
return n;
}
Необходимость в комментариях отпадает, если лучше обозвать переменные:…Не комментируйте плохой код, просто перепишите его.
Node bestNode;
foreach (Node currentNode in node.getChildren()) {
…
}
Продолжение следует…
Источник: https://stackoverflow.blog/2021/07/05/best-practices-for-writing-code-comments/
День девятьсот пятый. #BestPractices
Лучшие Практики Написания Комментариев к Коду. Продолжение
Начало
3. Если вы не можете написать чёткий комментарий, возможно, проблема в коде
Самый печально известный комментарий в исходном коде Unix: «Никто не ожидает, что вы это поймёте», - располагался перед каким-то непонятным кодом переключения контекста. Позже Деннис Ричи объяснил, что это было написано в смысле "Этого не будет на экзамене", а не чтобы потроллить читателей. К сожалению, выяснилось, что ни он, ни соавтор Кен Томпсон сами не понимали этого кода и позже пришлось его переписать.
Это напоминает закон Кернигана: «Отладка в два раза сложнее, чем изначальное написание кода. Следовательно, если вы напишете код настолько умно, насколько это возможно, вы по определению недостаточно умны, чтобы отлаживать его.»
Предупреждать читателей, что они могут не понять ваш код, всё равно что включить аварийку в машине: признаться, что вы знаете, что нарушаете ПДД. Вместо этого перепишите код так, чтобы вы понимали его достаточно хорошо, чтобы объяснить кому-то, или, ещё лучше, чтобы объяснения не требовалось.
4. Комментарии должны прояснять ситуацию, а не запутывать
Обсуждение плохих комментариев было бы неполным без этой истории из книги Стивена Леви «Хакеры: герои компьютерной революции»:
[Питер Сэмсон] отличался тем, что отказывался добавлять поясняющие комментарии к своему исходному коду. Одна хорошо распространённая программа, написанная Сэмсоном, содержала сотни инструкций на языке ассемблера, с одним комментарием рядом с инструкцией, содержащей число 1750. Комментарий был: «RIPJSB», - и люди ломали голову над его значением, пока кто-то не понял, что 1750 - это был год смерти Баха, и что Сэмсон написал аббревиатуру для «Покойся с миром Иоганн Себастьяна Баха».
Иногда бывают ситуации, когда можно сумничать, и это могут оценить окружающие, но это не тот случай. Если ваш комментарий вызывает замешательство, а не поясняет запутанный код, удалите его.
5. Поясняйте нестандартный код в комментариях
Рекомендуется комментировать код, который кто-то может счесть ненужным или избыточным, например этот код из App Inventor:
Необходимо принять решение относительно того, требует ли код пояснения. Например, в учебнике по Kotlin есть такой код:
Продолжение следует…
Источник: https://stackoverflow.blog/2021/07/05/best-practices-for-writing-code-comments/
Лучшие Практики Написания Комментариев к Коду. Продолжение
Начало
3. Если вы не можете написать чёткий комментарий, возможно, проблема в коде
Самый печально известный комментарий в исходном коде Unix: «Никто не ожидает, что вы это поймёте», - располагался перед каким-то непонятным кодом переключения контекста. Позже Деннис Ричи объяснил, что это было написано в смысле "Этого не будет на экзамене", а не чтобы потроллить читателей. К сожалению, выяснилось, что ни он, ни соавтор Кен Томпсон сами не понимали этого кода и позже пришлось его переписать.
Это напоминает закон Кернигана: «Отладка в два раза сложнее, чем изначальное написание кода. Следовательно, если вы напишете код настолько умно, насколько это возможно, вы по определению недостаточно умны, чтобы отлаживать его.»
Предупреждать читателей, что они могут не понять ваш код, всё равно что включить аварийку в машине: признаться, что вы знаете, что нарушаете ПДД. Вместо этого перепишите код так, чтобы вы понимали его достаточно хорошо, чтобы объяснить кому-то, или, ещё лучше, чтобы объяснения не требовалось.
4. Комментарии должны прояснять ситуацию, а не запутывать
Обсуждение плохих комментариев было бы неполным без этой истории из книги Стивена Леви «Хакеры: герои компьютерной революции»:
[Питер Сэмсон] отличался тем, что отказывался добавлять поясняющие комментарии к своему исходному коду. Одна хорошо распространённая программа, написанная Сэмсоном, содержала сотни инструкций на языке ассемблера, с одним комментарием рядом с инструкцией, содержащей число 1750. Комментарий был: «RIPJSB», - и люди ломали голову над его значением, пока кто-то не понял, что 1750 - это был год смерти Баха, и что Сэмсон написал аббревиатуру для «Покойся с миром Иоганн Себастьяна Баха».
Иногда бывают ситуации, когда можно сумничать, и это могут оценить окружающие, но это не тот случай. Если ваш комментарий вызывает замешательство, а не поясняет запутанный код, удалите его.
5. Поясняйте нестандартный код в комментариях
Рекомендуется комментировать код, который кто-то может счесть ненужным или избыточным, например этот код из App Inventor:
final Object value = (new JSONTokener(jsonString)).nextValue();Без этого комментария кто-то может «упростить» код или рассматривать его как загадочное, но важное заклинание. Сэкономьте время и беспокойство будущих читателей, написав, зачем нужен код.
// Note that JSONTokener.nextValue() may return
// a value equals() to null.
if (value == null || value.equals(null)) {
return null;
}
Необходимо принять решение относительно того, требует ли код пояснения. Например, в учебнике по Kotlin есть такой код:
if (b == true)Странно, почему бы не использовать просто
if (b), как это было бы в Java или C# (да и куче других языков). Однако, оказывается, что обнуляемые булевы переменные в Kotlin специально явно сравниваются с true, чтобы избежать уродливой проверки на null:
if (b != null && b)Понятно, что не нужно добавлять комментарий для идиом, распространённых в конкретном языке, если только вы не пишете руководство для новичков.
Продолжение следует…
Источник: https://stackoverflow.blog/2021/07/05/best-practices-for-writing-code-comments/
День девятьсот шестой. #BestPractices
Лучшие Практики Написания Комментариев к Коду. Продолжение
Начало
Продолжение
6. Предоставляйте ссылки на источник скопированного кода
Если вы такой же, как и большинство программистов, вы «иногда» используете код, который находите в Интернете. Добавление ссылки на источник позволяет будущим читателям получить полный контекст, например:
- какая проблема решалась,
- кто предоставил код,
- почему рекомендовано это решение,
- что об этом думают комментаторы,
- работает ли это решение до сих пор,
- как его можно улучшить.
Например, рассмотрим этот комментарий:
- Автор кода - Tomáš Procházka, который входит в топ 3% контрибьюторов на Stack Overflow.
- Один комментатор предлагает оптимизацию, уже включенную в репозиторий.
- Другой комментатор предлагает способ избежать крайнего случая.
Сравните это с этим комментарием (слегка изменённым для защиты авторов):
Некоторые программисты не любят указывать, что не они писали код, но повторное использование кода может быть разумным шагом, экономя время и давая вам возможность написать больше кода. Но конечно, вы никогда не должны вставлять код, который вам непонятен.
Люди копируют много кода из вопросов и ответов на Stack Overflow. Этот код подпадает под действие лицензий Creative Commons, требующей указания авторства. Комментарий со ссылкой удовлетворяет этому требованию.
Точно так же вы можете ссылаться на полезные учебные пособия, чтобы их можно было найти снова, а также в виде благодарности их автору:
Например:
Окончание следует…
Источник: https://stackoverflow.blog/2021/07/05/best-practices-for-writing-code-comments/
Лучшие Практики Написания Комментариев к Коду. Продолжение
Начало
Продолжение
6. Предоставляйте ссылки на источник скопированного кода
Если вы такой же, как и большинство программистов, вы «иногда» используете код, который находите в Интернете. Добавление ссылки на источник позволяет будущим читателям получить полный контекст, например:
- какая проблема решалась,
- кто предоставил код,
- почему рекомендовано это решение,
- что об этом думают комментаторы,
- работает ли это решение до сих пор,
- как его можно улучшить.
Например, рассмотрим этот комментарий:
/* Преобразует Drawable в Bitmap.Переход по ссылке на ответ показывает:
См. https://stackoverflow.com/a/46018816/2219998 */
- Автор кода - Tomáš Procházka, который входит в топ 3% контрибьюторов на Stack Overflow.
- Один комментатор предлагает оптимизацию, уже включенную в репозиторий.
- Другой комментатор предлагает способ избежать крайнего случая.
Сравните это с этим комментарием (слегка изменённым для защиты авторов):
// Магическая формула, взятая со stackoverflow.Любому, кто захочет понять этот код, придётся искать формулу. Вставить URL-адрес намного быстрее, чем искать ссылку позже.
// По общему мнению, основана на человеческом восприятии.
return (int) (0.3 * red + 0.59 * green + 0.11 * blue);
Некоторые программисты не любят указывать, что не они писали код, но повторное использование кода может быть разумным шагом, экономя время и давая вам возможность написать больше кода. Но конечно, вы никогда не должны вставлять код, который вам непонятен.
Люди копируют много кода из вопросов и ответов на Stack Overflow. Этот код подпадает под действие лицензий Creative Commons, требующей указания авторства. Комментарий со ссылкой удовлетворяет этому требованию.
Точно так же вы можете ссылаться на полезные учебные пособия, чтобы их можно было найти снова, а также в виде благодарности их автору:
// Большое спасибо Chris Veness за отличные примеры:7. Добавляйте ссылки на внешние источники, где они будут наиболее полезны
// https://www.movable-type.co.uk/scripts/latlong.html
Например:
/* На https://tools.ietf.org/html/rfc4180Ссылки на стандарты и другую документацию могут помочь читателям понять проблему, которую решает ваш код. Хотя эта информация может быть где-то в проектном документе, комментарий в правильном месте даст читателям информацию там, где она больше всего нужна. В этом случае переход по ссылке даст полезную информацию о том, что стандарт RFC 4180 был обновлен до RFC 7111.
советуют завершать строки в CSV файле символом CRLF
поэтому используем \r\n */
csvStringBuilder.append("\r\n");
Окончание следует…
Источник: https://stackoverflow.blog/2021/07/05/best-practices-for-writing-code-comments/
День девятьсот седьмой. #BestPractices
Лучшие Практики Написания Комментариев к Коду. Окончание
Начало
Продолжение 1
Продолжение 2
8. Добавляйте комментарии при исправлении ошибок
Комментарии следует добавлять не только при первоначальном написании кода, но и при его изменении, особенно при исправлении ошибок. Обратите внимание на этот комментарий:
Также может быть полезно сослаться на проблему в багтрекере:
9. Используйте комментарии, чтобы отмечать незавершённые реализации
Иногда необходимо внести код в систему контроля версий, даже если он не завершён. Хотя может возникнуть соблазн не сообщать об известных недостатках в коде, лучше сделать их явными, например, с помощью комментария TODO:
Итого
Я надеюсь, что приведённые выше примеры показали, что комментарии не извиняют и не исправляют плохой код; они дополняют хороший код, предоставляя информацию другого типа. Как писал соучредитель Stack Overflow Джефф Этвуд: «Код говорит вам, как, а комментарии говорят вам, почему».
Следование этим правилам поможет вам и вашим товарищам по команде сэкономить время и нервы. Тем не менее, я уверен, что эти правила не являются исчерпывающими, и с нетерпением жду ваших вариантов в комментариях.
Источник: https://stackoverflow.blog/2021/07/05/best-practices-for-writing-code-comments/
Лучшие Практики Написания Комментариев к Коду. Окончание
Начало
Продолжение 1
Продолжение 2
8. Добавляйте комментарии при исправлении ошибок
Комментарии следует добавлять не только при первоначальном написании кода, но и при его изменении, особенно при исправлении ошибок. Обратите внимание на этот комментарий:
/* ПРИМЕЧАНИЕ: как минимум, в Firefox 2, если пользователь уводит курсор за пределы окна браузера, событие перемещения мыши (и даже отпускания мыши) не будет получено, пока пользователь не перетащит курсор обратно в окно. Обойти проблему можно, реализовав onMouseLeave(). */Комментарий не только помогает читателю понять код в текущем и связанных методах, но и помогает определить, нужен ли ещё этот код и как его протестировать.
public void onMouseMove(Widget sender, int x, int y) { … }
Также может быть полезно сослаться на проблему в багтрекере:
// Имя используется в качестве заголовка,Если в системе контроля версий вы чётко следите за сообщениями коммитов, и добавляете в них ссылки на проблемы багтрекера,
// если свойство заголовка не задано (баг #1425).
git blame можно использовать для поиска коммита, в котором было изменение. Хотя здесь могут быть варианты. Если исправление состояло из нескольких коммитов или были более серьёзные изменения, вроде перемещения метода в другой класс или переименования/перемещения файлов, тогда поиск источника исправления может сильно усложниться.9. Используйте комментарии, чтобы отмечать незавершённые реализации
Иногда необходимо внести код в систему контроля версий, даже если он не завершён. Хотя может возникнуть соблазн не сообщать об известных недостатках в коде, лучше сделать их явными, например, с помощью комментария TODO:
/* TODO(hal): мы используем десятичный разделитель точку, вне зависимости от региона пользователя. Нам нужно подумать о том, как разрешить запятую в качестве десятичного разделителя, что потребует обновления синтаксического анализа чисел и других мест, где числа парсятся из строк, таких как FormatAsDecimal */Использование стандартного формата для таких комментариев помогает измерить и устранить технический долг. А ещё лучше добавить проблему в багтрекер и указать ссылку на неё в своём комментарии.
Итого
Я надеюсь, что приведённые выше примеры показали, что комментарии не извиняют и не исправляют плохой код; они дополняют хороший код, предоставляя информацию другого типа. Как писал соучредитель Stack Overflow Джефф Этвуд: «Код говорит вам, как, а комментарии говорят вам, почему».
Следование этим правилам поможет вам и вашим товарищам по команде сэкономить время и нервы. Тем не менее, я уверен, что эти правила не являются исчерпывающими, и с нетерпением жду ваших вариантов в комментариях.
Источник: https://stackoverflow.blog/2021/07/05/best-practices-for-writing-code-comments/
День девятьсот восьмой. #DesignPatterns #Microservices
Паттерны в Микросервисах
7. Душитель (Strangler)
Если мы хотим использовать микросервисную архитектуру в унаследованном проекте, нам необходимо перенести устаревшие или существующие монолитные приложения на микросервисы. Перемещение существующих и работающих крупных монолитных приложений на микросервисы является довольно сложной задачей, так как это может нарушить доступность приложения.
Одно из решений - использовать паттерн Душитель. Он предполагает постепенную миграцию монолитного приложения на микросервисную архитектуру путём постепенной замены определённых функций новыми микросервисами. Кроме того, новый функционал добавляется только в микросервисы, минуя устаревшее монолитное приложение. Затем настраивается фасад (API-шлюз https://t.iss.one/NetDeveloperDiary/1106) для маршрутизации запросов между устаревшим монолитом и микросервисами. После того, как функциональность перенесена на микросервисы, фасад перехватывает клиентский запрос и направляет его на новые микросервисы. После переноса всего функционала старого монолита получается, что монолитное приложение «задушено», то есть оно выводится из эксплуатации. См. картинку ниже.
Достоинства
- Безопасная миграция монолитного приложения на микросервисы.
- Миграция и разработка нового функционала могут идти параллельно.
- Процесс миграции может иметь свой темп, весь функционал постоянно доступен клиентам.
Недостатки
- Совместное использование хранилища данных между существующим монолитным приложением и новыми микросервисами становится сложной задачей.
- Добавление фасада (API-шлюза) увеличит время отклика системы.
- Сквозное тестирование становится трудным.
Когда использовать
- Постепенная миграция большого серверного монолитного приложения на микросервисы.
Когда не использовать
- Если монолитное приложение на бэкенде небольшое, то лучше заменить его целиком.
- Если клиентский запрос к устаревшему монолитному приложению не может быть перехвачен.
Поддержка
Бэкенд фреймворки с поддержкой API-шлюзов.
Подробнее
- Паттерн Душитель
- Microservices Pattern: Strangler application
Источник: https://towardsdatascience.com/microservice-architecture-and-its-10-most-important-design-patterns-824952d7fa41
Паттерны в Микросервисах
7. Душитель (Strangler)
Если мы хотим использовать микросервисную архитектуру в унаследованном проекте, нам необходимо перенести устаревшие или существующие монолитные приложения на микросервисы. Перемещение существующих и работающих крупных монолитных приложений на микросервисы является довольно сложной задачей, так как это может нарушить доступность приложения.
Одно из решений - использовать паттерн Душитель. Он предполагает постепенную миграцию монолитного приложения на микросервисную архитектуру путём постепенной замены определённых функций новыми микросервисами. Кроме того, новый функционал добавляется только в микросервисы, минуя устаревшее монолитное приложение. Затем настраивается фасад (API-шлюз https://t.iss.one/NetDeveloperDiary/1106) для маршрутизации запросов между устаревшим монолитом и микросервисами. После того, как функциональность перенесена на микросервисы, фасад перехватывает клиентский запрос и направляет его на новые микросервисы. После переноса всего функционала старого монолита получается, что монолитное приложение «задушено», то есть оно выводится из эксплуатации. См. картинку ниже.
Достоинства
- Безопасная миграция монолитного приложения на микросервисы.
- Миграция и разработка нового функционала могут идти параллельно.
- Процесс миграции может иметь свой темп, весь функционал постоянно доступен клиентам.
Недостатки
- Совместное использование хранилища данных между существующим монолитным приложением и новыми микросервисами становится сложной задачей.
- Добавление фасада (API-шлюза) увеличит время отклика системы.
- Сквозное тестирование становится трудным.
Когда использовать
- Постепенная миграция большого серверного монолитного приложения на микросервисы.
Когда не использовать
- Если монолитное приложение на бэкенде небольшое, то лучше заменить его целиком.
- Если клиентский запрос к устаревшему монолитному приложению не может быть перехвачен.
Поддержка
Бэкенд фреймворки с поддержкой API-шлюзов.
Подробнее
- Паттерн Душитель
- Microservices Pattern: Strangler application
Источник: https://towardsdatascience.com/microservice-architecture-and-its-10-most-important-design-patterns-824952d7fa41
👍1
День девятьсот девятый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
92. Когда Программисты и Тестировщики Сотрудничают
Когда тестировщики и программисты начинают сотрудничать, случается магия. Меньше времени тратится на отправку ошибок туда-сюда через багтрекер. Меньше времени тратится на попытки выяснить, действительно ли что-то является ошибкой или новой функцией, и больше времени тратится на разработку хорошего программного обеспечения, отвечающего ожиданиям клиентов. Есть много возможностей начать сотрудничать ещё до того, как начнётся кодирование.
Тестировщики могут помочь клиентам писать и автоматизировать приёмочные тесты, используя язык их предметной области, с помощью инструментов вроде SpecFlow. Когда эти тесты передаются программистам до начала кодирования, команда практикует разработку, основанную на приёмочных тестах (ATDD). Программисты пишут основу для запуска тестов, а затем код, чтобы тесты проходили. Затем эти тесты становятся частью набора регрессионных тестов. Когда происходит такое сотрудничество, функциональные тесты завершаются раньше, что даёт время для исследовательского тестирования пограничных условий или более широкого тестирования рабочих процессов.
Мы можем сделать ещё один шаг вперед. Как тестировщик, я могу представить большинство своих идей по тестированию до того, как программисты начнут кодировать новый функционал. Когда я спрашиваю программистов, есть ли у них какие-либо предложения, они почти всегда предоставляют информацию, которая помогает мне лучше покрыть код тестами или не тратить много времени на ненужные тесты. Часто мы предотвращаем дефекты, потому что тесты проясняют многие из первоначальных идей. Например, в одном проекте, над которым я работала, тесты, которые я дала программистам, отображали ожидаемые результаты запроса в ответ на поиск по шаблону. Программист же твёрдо намеревался реализовать поиск только по полным словам. Мы смогли поговорить с заказчиком и определить правильные требования до начала кодирования. Сотрудничая, мы предотвратили дефект, что сэкономило нам обоим много времени.
Программисты также могут сотрудничать с тестировщиками для создания успешной автоматизации. Они разбираются в хороших методах программирования и могут помочь тестировщикам создать надёжный пакет автоматических тестов, который будет работать на пользу всей команде. Я часто видела, как проекты автоматизированного тестирования терпят неудачу, потому что тесты плохо спроектированы. Тесты пытаются проверить слишком много, или тестировщики недостаточно разбираются в технологии, чтобы обеспечить независимость тестов. Тестировщики часто являются узким местом, поэтому программистам имеет смысл работать с ними над такими задачами, как автоматизация. Работа с тестировщиками для понимания того, что можно протестировать на раннем этапе, возможно, с помощью более простого инструмента, даст программистам ещё один цикл обратной связи, который поможет им в долгосрочной перспективе создавать лучший код.
Когда тестировщики перестают думать, что их единственная задача - взламывать программное обеспечение и находить ошибки в коде программистов, программисты перестают думать, что тестировщики только и думают, как испортить им жизнь, и становятся более открытыми для сотрудничества. Когда программисты начинают понимать, что они несут ответственность за обеспечение качества своего кода, возможность тестирования становится естественным качеством кода, и команда сможет вместе автоматизировать большее количество регрессионных тестов. Так зарождается магия успешной командной работы.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Janet Gregory
97 Вещей, Которые Должен Знать Каждый Программист
92. Когда Программисты и Тестировщики Сотрудничают
Когда тестировщики и программисты начинают сотрудничать, случается магия. Меньше времени тратится на отправку ошибок туда-сюда через багтрекер. Меньше времени тратится на попытки выяснить, действительно ли что-то является ошибкой или новой функцией, и больше времени тратится на разработку хорошего программного обеспечения, отвечающего ожиданиям клиентов. Есть много возможностей начать сотрудничать ещё до того, как начнётся кодирование.
Тестировщики могут помочь клиентам писать и автоматизировать приёмочные тесты, используя язык их предметной области, с помощью инструментов вроде SpecFlow. Когда эти тесты передаются программистам до начала кодирования, команда практикует разработку, основанную на приёмочных тестах (ATDD). Программисты пишут основу для запуска тестов, а затем код, чтобы тесты проходили. Затем эти тесты становятся частью набора регрессионных тестов. Когда происходит такое сотрудничество, функциональные тесты завершаются раньше, что даёт время для исследовательского тестирования пограничных условий или более широкого тестирования рабочих процессов.
Мы можем сделать ещё один шаг вперед. Как тестировщик, я могу представить большинство своих идей по тестированию до того, как программисты начнут кодировать новый функционал. Когда я спрашиваю программистов, есть ли у них какие-либо предложения, они почти всегда предоставляют информацию, которая помогает мне лучше покрыть код тестами или не тратить много времени на ненужные тесты. Часто мы предотвращаем дефекты, потому что тесты проясняют многие из первоначальных идей. Например, в одном проекте, над которым я работала, тесты, которые я дала программистам, отображали ожидаемые результаты запроса в ответ на поиск по шаблону. Программист же твёрдо намеревался реализовать поиск только по полным словам. Мы смогли поговорить с заказчиком и определить правильные требования до начала кодирования. Сотрудничая, мы предотвратили дефект, что сэкономило нам обоим много времени.
Программисты также могут сотрудничать с тестировщиками для создания успешной автоматизации. Они разбираются в хороших методах программирования и могут помочь тестировщикам создать надёжный пакет автоматических тестов, который будет работать на пользу всей команде. Я часто видела, как проекты автоматизированного тестирования терпят неудачу, потому что тесты плохо спроектированы. Тесты пытаются проверить слишком много, или тестировщики недостаточно разбираются в технологии, чтобы обеспечить независимость тестов. Тестировщики часто являются узким местом, поэтому программистам имеет смысл работать с ними над такими задачами, как автоматизация. Работа с тестировщиками для понимания того, что можно протестировать на раннем этапе, возможно, с помощью более простого инструмента, даст программистам ещё один цикл обратной связи, который поможет им в долгосрочной перспективе создавать лучший код.
Когда тестировщики перестают думать, что их единственная задача - взламывать программное обеспечение и находить ошибки в коде программистов, программисты перестают думать, что тестировщики только и думают, как испортить им жизнь, и становятся более открытыми для сотрудничества. Когда программисты начинают понимать, что они несут ответственность за обеспечение качества своего кода, возможность тестирования становится естественным качеством кода, и команда сможет вместе автоматизировать большее количество регрессионных тестов. Так зарождается магия успешной командной работы.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Janet Gregory
День девятьсот десятый. #ВопросыНаСобеседовании
Сегодня порекомендую вам не видео, а серию подкаста DotNet & More про вопросы на собеседовании. Серия вышла ещё в конце мая, но вот наткнулся на неё только сейчас. Ребята 2,5 часа обсуждают, что их спрашивали на собеседованиях, и что они стараются спрашивать, когда находятся по другую сторону стола.
Вообще, обсуждение довольно интересное. Поэтому, если у вас есть свободное время по пути на работу (или в отпуск), слушайте.
Выпуск доступен на YouTube или звуком на Anchor.
Сегодня порекомендую вам не видео, а серию подкаста DotNet & More про вопросы на собеседовании. Серия вышла ещё в конце мая, но вот наткнулся на неё только сейчас. Ребята 2,5 часа обсуждают, что их спрашивали на собеседованиях, и что они стараются спрашивать, когда находятся по другую сторону стола.
Вообще, обсуждение довольно интересное. Поэтому, если у вас есть свободное время по пути на работу (или в отпуск), слушайте.
Выпуск доступен на YouTube или звуком на Anchor.
День девятьсот одиннадцатый. #ЗаметкиНаПолях
Объясняем Подходы Code First, Database First и Model First. Начало
Существует два лагеря разработчиков: одни считают Entity Framework интуитивно понятным и простым в использовании, другие считают, что работать с ним - ад. Зачастую это зависит от «подхода» к использованию EF: использовать ли сначала код, сначала базу данных или сначала модель.
Model First включён в этот список, хотя его поддержка была прекращена несколько лет назад. Но люди, которые когда-то с ним мучались, до сих пор думают, что EF - это куча мусора, и они никогда больше не будут с ним работать, хотя подход Code First с тех пор очень сильно усовершенствован.
Здесь мы не будем противопоставлять эти подходы друг другу, а просто рассмотрим, что представляет из себя каждый из них, и почему люди воспринимают EF по-разному в зависимости от подхода, который они использовали.
1. Что такое Code First?
Если вы использовали EF Core или более поздние версии, вы скорее всего использовали подход «Сначала Код». Он состоит в том, что вы сначала строите вашу базу данных с помощью классов C#, а затем «мигрируете» эти сущности в базу данных с помощью команды:
Главное, что нужно понимать о Code First, это то, что, поскольку вы создаёте базу данных с помощью кода C#, этот подход хорошо работает для разработчиков, но не для администраторов баз данных или архитекторов. Когда всё написано на C#, может быть трудно отобразить схему базы данных. Кроме того, создавать такие вещи, как хранимые процедуры или представления, в Code First, конечно, можно, но это может быть чересчур громоздким.
Преимущества использования подхода Code First:
- Ваш код всегда обращается к схеме базы данных, которую он контролирует, поэтому редко бывает «несоответствие» в типах столбцов, определениях таблиц и т. д.
- У вас есть стандартный способ управления миграциями базы данных (так что не потребуется никаких хитрых инструкций, типа «запустить этот скрипт перед развёртыванием»).
- Практически любой разработчик может создать базу данных, если знает C#, даже не слишком хорошо разбираясь в SQL (хотя… это может негативно повлиять на качество).
- Подход работает для самых разных СУБД, таких как Postgres, MySQL и т. д.
В общем, сегодня вы, вероятно, выберете подход Code First почти для каждого нового проекта .NET. Даже если конечной целью является управление базой данных другим способом после публикации, это такой инструмент быстрого прототипирования, который довольно хорошо масштабируется, поэтому вы захотите его использовать.
Продолжение следует…
Источник: https://dotnetcoretutorials.com/2021/06/26/code-first-vs-database-first-vs-model-first-entityframework-approaches-explained/
Объясняем Подходы Code First, Database First и Model First. Начало
Существует два лагеря разработчиков: одни считают Entity Framework интуитивно понятным и простым в использовании, другие считают, что работать с ним - ад. Зачастую это зависит от «подхода» к использованию EF: использовать ли сначала код, сначала базу данных или сначала модель.
Model First включён в этот список, хотя его поддержка была прекращена несколько лет назад. Но люди, которые когда-то с ним мучались, до сих пор думают, что EF - это куча мусора, и они никогда больше не будут с ним работать, хотя подход Code First с тех пор очень сильно усовершенствован.
Здесь мы не будем противопоставлять эти подходы друг другу, а просто рассмотрим, что представляет из себя каждый из них, и почему люди воспринимают EF по-разному в зависимости от подхода, который они использовали.
1. Что такое Code First?
Если вы использовали EF Core или более поздние версии, вы скорее всего использовали подход «Сначала Код». Он состоит в том, что вы сначала строите вашу базу данных с помощью классов C#, а затем «мигрируете» эти сущности в базу данных с помощью команды:
Update-Databaseили
dotnet ef database updateПоскольку всё управляется из кода C#, когда вам нужны дополнительные типы SQL, такие как индексы, ограничения или даже просто сложные внешние ключи, вы должны использовать либо атрибуты аннотации данных, либо EF Fluent Configuration.
Главное, что нужно понимать о Code First, это то, что, поскольку вы создаёте базу данных с помощью кода C#, этот подход хорошо работает для разработчиков, но не для администраторов баз данных или архитекторов. Когда всё написано на C#, может быть трудно отобразить схему базы данных. Кроме того, создавать такие вещи, как хранимые процедуры или представления, в Code First, конечно, можно, но это может быть чересчур громоздким.
Преимущества использования подхода Code First:
- Ваш код всегда обращается к схеме базы данных, которую он контролирует, поэтому редко бывает «несоответствие» в типах столбцов, определениях таблиц и т. д.
- У вас есть стандартный способ управления миграциями базы данных (так что не потребуется никаких хитрых инструкций, типа «запустить этот скрипт перед развёртыванием»).
- Практически любой разработчик может создать базу данных, если знает C#, даже не слишком хорошо разбираясь в SQL (хотя… это может негативно повлиять на качество).
- Подход работает для самых разных СУБД, таких как Postgres, MySQL и т. д.
В общем, сегодня вы, вероятно, выберете подход Code First почти для каждого нового проекта .NET. Даже если конечной целью является управление базой данных другим способом после публикации, это такой инструмент быстрого прототипирования, который довольно хорошо масштабируется, поэтому вы захотите его использовать.
Продолжение следует…
Источник: https://dotnetcoretutorials.com/2021/06/26/code-first-vs-database-first-vs-model-first-entityframework-approaches-explained/
День девятьсот двенадцатый. #ЗаметкиНаПолях
Объясняем Подходы Code First, Database First и Model First. Продолжение
Начало
2. Что такое Database First?
Database First - интересный подход, потому что раньше он был гораздо более распространённым. Независимо от того, назывался ли он «Сначала База Данных» или просто представлял из себя наборы данных (если вспомнить времена WinForms). Это просто означает, что ваше приложение обращается к уже существующей базе данных.
Допустим, есть база данных производственной системы, в которой уже есть, скажем, более 50 таблиц, и каждая из этих таблиц имеет свои обычные столбцы, внешние ключи и ограничения. Если мы выберем подход Code First, возникнет пара проблем:
- Нам нужно вручную ввести определение для каждой таблицы, которую мы хотим использовать, и мы должны сделать всё возможное, чтобы определения в точности соответствовали существующей схеме.
- Мы не можем использовать миграции из Code First, потому что база данных уже существует и, вероятно, управляется другим способом. И хотя это не большая проблема, мы теряем основное преимущество использования Code First.
Итак, мы могли бы сначала написать код, но мы в некоторой степени обманываем себя, имитируя, что код появился первым.
Поэтому вместо этого мы можем использовать подход «Сначала база данных». Он делает то же, что мы делали бы вручную в коде, но делает это путём проверки базы данных и создания классов за нас. Если вы раньше использовали какие-нибудь ORM, то довольно часто можно было попросить ORM «автоматически сгенерировать» тип из базы данных, который можно было бы пересоздавать при каждом изменении базы данных.
Всё, что нам нужно сделать, это выполнить следующую команду:
В официальной документации от Microsoft подход «Сначала база данных» располагается на странице под заголовком «Обратное проектирование», что вполне справедливо.
Несмотря на то, что далее мы рассмотрим подход Model First, следует отметить, что вы можете использовать подход Database First, так же, как если бы вы использовали модель. По сути, Database First, - это такая же автоматическая генерация схемы в Visual Studio, только в виде классов C#, а не файла EDMX.
Окончание следует…
Источник: https://dotnetcoretutorials.com/2021/06/26/code-first-vs-database-first-vs-model-first-entityframework-approaches-explained/
Объясняем Подходы Code First, Database First и Model First. Продолжение
Начало
2. Что такое Database First?
Database First - интересный подход, потому что раньше он был гораздо более распространённым. Независимо от того, назывался ли он «Сначала База Данных» или просто представлял из себя наборы данных (если вспомнить времена WinForms). Это просто означает, что ваше приложение обращается к уже существующей базе данных.
Допустим, есть база данных производственной системы, в которой уже есть, скажем, более 50 таблиц, и каждая из этих таблиц имеет свои обычные столбцы, внешние ключи и ограничения. Если мы выберем подход Code First, возникнет пара проблем:
- Нам нужно вручную ввести определение для каждой таблицы, которую мы хотим использовать, и мы должны сделать всё возможное, чтобы определения в точности соответствовали существующей схеме.
- Мы не можем использовать миграции из Code First, потому что база данных уже существует и, вероятно, управляется другим способом. И хотя это не большая проблема, мы теряем основное преимущество использования Code First.
Итак, мы могли бы сначала написать код, но мы в некоторой степени обманываем себя, имитируя, что код появился первым.
Поэтому вместо этого мы можем использовать подход «Сначала база данных». Он делает то же, что мы делали бы вручную в коде, но делает это путём проверки базы данных и создания классов за нас. Если вы раньше использовали какие-нибудь ORM, то довольно часто можно было попросить ORM «автоматически сгенерировать» тип из базы данных, который можно было бы пересоздавать при каждом изменении базы данных.
Всё, что нам нужно сделать, это выполнить следующую команду:
Scaffold-DbContext "<Строка Подключения>"И Entity Framework сделает всё за нас. Мы можем запустить эту команду снова через некоторое время, чтобы при необходимости получить последние изменения из схемы нашей базы данных. Из-за этого не рекомендуется вообще редактировать классы, которые Entity Framework генерирует для нас, поскольку они будут перезаписаны при следующем запуске скаффолдинга.
В официальной документации от Microsoft подход «Сначала база данных» располагается на странице под заголовком «Обратное проектирование», что вполне справедливо.
Несмотря на то, что далее мы рассмотрим подход Model First, следует отметить, что вы можете использовать подход Database First, так же, как если бы вы использовали модель. По сути, Database First, - это такая же автоматическая генерация схемы в Visual Studio, только в виде классов C#, а не файла EDMX.
Окончание следует…
Источник: https://dotnetcoretutorials.com/2021/06/26/code-first-vs-database-first-vs-model-first-entityframework-approaches-explained/
День девятьсот тринадцатый. #ЗаметкиНаПолях
Объясняем Подходы Code First, Database First и Model First. Окончание
Начало
Продолжение
3. Что такое Model First?
Если вы поговорите с кем-нибудь, кто в последний раз использовал Entity Framework лет пять назад, он скорее всего заговорит о визуальном редакторе, файлах edmx, и о том, как это всё глючило, вылетало и тормозило. И в этом будет большая доля правды.
По сути, это был визуальный редактор для построения схемы базы данных внутри Visual Studio. Проблема заключалась в том, что он очень сильно тормозил, когда вы добавляли туда хотя бы пару десятков таблиц. Этот визуальный редактор был построен на основе файла edmx. По сути, edmx представлял собой огромный XML-файл, описывающий схему базы данных. Как это выглядело, показано на картинке ниже.
Часто бывало, что вместо того, чтобы использовать тормозящий визуальный редактор для внесения изменений, люди редактировали этот XML файл напрямую, чтобы внести изменения, а затем, если могли, открывали конструктор и проверяли, правильно ли всё выглядит, прежде чем сохранять изменения в базе. Если вы случайно открывали визуальный редактор, вы часто могли стать объектом насмешек в офисе, потому что в лучшем случае ваша Visual Studio зависала на несколько минут, а в худшем - висела несколько минут, а затем просто вылетала.
Файл EDMX был не единственным файлом в подходе Model First. На основе EDMX Visual Studio также автоматически генерировала файлы C# для привязки к вашему коду, которые не слишком отличались от файлов кода, которые мы используем при подходе Code First, за исключением того, что они были автоматически сгенерированным хаосом.
Помимо медленного редактора, были и другие проблемы с подходом Model First:
- Он не создавал миграций для баз данных, для этого часто приходилось использовать сторонний инструмент.
- При работе в крупной команде, поскольку вся база данных находилась в одном большом EDMX-файле, конфликты слияния были обычным явлением, и решать их было кошмаром.
- Некоторые из автоматически сгенерированных файлов не создавались автоматически, вам нужно было щёлкнуть правой кнопкой мыши на файле EDMX, а затем выбрать «Создать» и т.д. Если вы забывали это сделать, всё шло наперекосяк.
В общем, Model First умерла несколько лет назад и больше не существует в EF Core, поэтому вы вряд ли вы столкнётесь с ней в наши дни. Но всё же неплохо будет знать, что, когда люди жалуются на плохую работу Entity Framework с файлом edmx, они имеют в виду устаревший подход, а не современный Code First.
Какой подход использовать?
В наши дни это довольно простое решение:
- Если вы начинаете новый проект с новой базой данных, используйте Code First.
- Если вы начинаете новый проект, но база данных, с которой он должен работать, уже существует, используйте Database First.
Источник: https://dotnetcoretutorials.com/2021/06/26/code-first-vs-database-first-vs-model-first-entityframework-approaches-explained/
Объясняем Подходы Code First, Database First и Model First. Окончание
Начало
Продолжение
3. Что такое Model First?
Если вы поговорите с кем-нибудь, кто в последний раз использовал Entity Framework лет пять назад, он скорее всего заговорит о визуальном редакторе, файлах edmx, и о том, как это всё глючило, вылетало и тормозило. И в этом будет большая доля правды.
По сути, это был визуальный редактор для построения схемы базы данных внутри Visual Studio. Проблема заключалась в том, что он очень сильно тормозил, когда вы добавляли туда хотя бы пару десятков таблиц. Этот визуальный редактор был построен на основе файла edmx. По сути, edmx представлял собой огромный XML-файл, описывающий схему базы данных. Как это выглядело, показано на картинке ниже.
Часто бывало, что вместо того, чтобы использовать тормозящий визуальный редактор для внесения изменений, люди редактировали этот XML файл напрямую, чтобы внести изменения, а затем, если могли, открывали конструктор и проверяли, правильно ли всё выглядит, прежде чем сохранять изменения в базе. Если вы случайно открывали визуальный редактор, вы часто могли стать объектом насмешек в офисе, потому что в лучшем случае ваша Visual Studio зависала на несколько минут, а в худшем - висела несколько минут, а затем просто вылетала.
Файл EDMX был не единственным файлом в подходе Model First. На основе EDMX Visual Studio также автоматически генерировала файлы C# для привязки к вашему коду, которые не слишком отличались от файлов кода, которые мы используем при подходе Code First, за исключением того, что они были автоматически сгенерированным хаосом.
Помимо медленного редактора, были и другие проблемы с подходом Model First:
- Он не создавал миграций для баз данных, для этого часто приходилось использовать сторонний инструмент.
- При работе в крупной команде, поскольку вся база данных находилась в одном большом EDMX-файле, конфликты слияния были обычным явлением, и решать их было кошмаром.
- Некоторые из автоматически сгенерированных файлов не создавались автоматически, вам нужно было щёлкнуть правой кнопкой мыши на файле EDMX, а затем выбрать «Создать» и т.д. Если вы забывали это сделать, всё шло наперекосяк.
В общем, Model First умерла несколько лет назад и больше не существует в EF Core, поэтому вы вряд ли вы столкнётесь с ней в наши дни. Но всё же неплохо будет знать, что, когда люди жалуются на плохую работу Entity Framework с файлом edmx, они имеют в виду устаревший подход, а не современный Code First.
Какой подход использовать?
В наши дни это довольно простое решение:
- Если вы начинаете новый проект с новой базой данных, используйте Code First.
- Если вы начинаете новый проект, но база данных, с которой он должен работать, уже существует, используйте Database First.
Источник: https://dotnetcoretutorials.com/2021/06/26/code-first-vs-database-first-vs-model-first-entityframework-approaches-explained/
День девятьсот четырнадцатый. #Оффтоп
Участники нашего чата знают, что я в последнее время приглядывал себе офисное кресло для работы. Старое прослужило лет 5 или 7. Не могу сказать, что верой и правдой, т.к. газлифт на нём стал шалить буквально через пару месяцев после покупки. Все 5 лет хотел довезти его до сервиса, но, видно, не судьба. В итоге недавно что-то в нём сломалось окончательно, и спинка тоже отказалась держать меня в вертикальном положении.
Решил купить новое кресло, и остановился на модели Samurai S2.04 (на фото). В чате посоветовали рассмотреть сетку, и мне вполне понравилось. Не так проваливаешься, как в подушку. Нижним полушариям с непривычки немного жестковато, зато стимулирует работать в режиме 25-5 (об этом тут).
Использую уже больше недели, пока всё устраивает. Нужные места продуваются и не потеют, поднимается довольно высоко, крепко держит спину вертикально, удобный упор для поясницы, подголовник тоже вполне неплох. И бонусом пристёгивающаяся подушка «на зиму».
Участники нашего чата знают, что я в последнее время приглядывал себе офисное кресло для работы. Старое прослужило лет 5 или 7. Не могу сказать, что верой и правдой, т.к. газлифт на нём стал шалить буквально через пару месяцев после покупки. Все 5 лет хотел довезти его до сервиса, но, видно, не судьба. В итоге недавно что-то в нём сломалось окончательно, и спинка тоже отказалась держать меня в вертикальном положении.
Решил купить новое кресло, и остановился на модели Samurai S2.04 (на фото). В чате посоветовали рассмотреть сетку, и мне вполне понравилось. Не так проваливаешься, как в подушку. Нижним полушариям с непривычки немного жестковато, зато стимулирует работать в режиме 25-5 (об этом тут).
Использую уже больше недели, пока всё устраивает. Нужные места продуваются и не потеют, поднимается довольно высоко, крепко держит спину вертикально, удобный упор для поясницы, подголовник тоже вполне неплох. И бонусом пристёгивающаяся подушка «на зиму».
День девятьсот пятнадцатый. #DesignPatterns #Microservices
Паттерны в Микросервисах
8. Прерыватель Цепи (Circuit Breaker)
В микросервисной архитектуре, где микросервисы обмениваются данными синхронно, один микросервис обычно вызывает другие сервисы для выполнения бизнес-логики. Вызов другого сервиса может завершиться ошибкой из-за временных сбоев (медленное сетевое соединение, тайм-ауты или временная недоступность). В таких случаях повторные вызовы могут решить проблему. Однако, если есть серьёзная проблема (полный отказ микросервиса), сервис будет недоступен в течение более длительного времени. Выполнение повторных попыток бессмысленно и впустую тратит драгоценные ресурсы (блокируется поток, тратятся циклы ЦП). Кроме того, отказ одного сервиса может привести к каскадным сбоям во всем приложении. В таких сценариях немедленный отказ - лучший подход.
В таких случаях на помощь может прийти паттерн «Прерыватель Цепи». Микросервис запрашивает другой сервис через прокси-сервер, который работает аналогично электрическому выключателю. Прокси-сервер должен подсчитывать количество недавних сбоев и использовать эти данные, чтобы решить, разрешить ли выполнение операции или просто немедленно вернуть исключение. См. картинку ниже.
Прерыватель цепи может находиться в следующих трёх состояниях:
- Замкнут: прерыватель цепи направляет запросы в микросервис и подсчитывает количество сбоев за заданный период времени. Если количество отказов за определённый период времени превышает пороговое значение, он отключается и переходит в разомкнутое состояние.
- Разомкнут: запрос от микросервиса немедленно завершается ошибкой, и возвращается исключение. По истечении времени ожидания прерыватель цепи переходит в полузамкнутое состояние.
- Полузамкнут: только ограниченное количество запросов от микросервиса может пройти и вызвать выполнение операции. Если эти запросы выполнены успешно, прерыватель цепи переходит в замкнутое состояние. Если какой-либо запрос терпит неудачу, прерыватель цепи переходит в разомкнутое состояние.
Преимущества
- Повышение отказоустойчивости микросервисной архитектуры.
- Прерывание каскадной передачи сбоев в другие микросервисы.
Недостатки
- Нужна сложная обработка исключений.
- Дополнительное логирование и мониторинг.
- Необходимость поддержки ручного сброса.
Когда использовать
- В тесно связанной микросервисной архитектуре, где микросервисы обмениваются данными синхронно.
- Если один микросервис зависит от нескольких других микросервисов.
Когда не использовать
- Слабо связанная микросервисная архитектура, управляемая событиями.
- Если микросервис не зависит от других микросервисов.
Поддержка
API Gateway, Service Mesh, various Circuit Breaker Libraries (Hystrix, Reselience4J, Polly.
Подробнее
- Паттерн Прерыватель Цепи
- Microservices Pattern: Circuit Breaker
Источник: https://towardsdatascience.com/microservice-architecture-and-its-10-most-important-design-patterns-824952d7fa41
Паттерны в Микросервисах
8. Прерыватель Цепи (Circuit Breaker)
В микросервисной архитектуре, где микросервисы обмениваются данными синхронно, один микросервис обычно вызывает другие сервисы для выполнения бизнес-логики. Вызов другого сервиса может завершиться ошибкой из-за временных сбоев (медленное сетевое соединение, тайм-ауты или временная недоступность). В таких случаях повторные вызовы могут решить проблему. Однако, если есть серьёзная проблема (полный отказ микросервиса), сервис будет недоступен в течение более длительного времени. Выполнение повторных попыток бессмысленно и впустую тратит драгоценные ресурсы (блокируется поток, тратятся циклы ЦП). Кроме того, отказ одного сервиса может привести к каскадным сбоям во всем приложении. В таких сценариях немедленный отказ - лучший подход.
В таких случаях на помощь может прийти паттерн «Прерыватель Цепи». Микросервис запрашивает другой сервис через прокси-сервер, который работает аналогично электрическому выключателю. Прокси-сервер должен подсчитывать количество недавних сбоев и использовать эти данные, чтобы решить, разрешить ли выполнение операции или просто немедленно вернуть исключение. См. картинку ниже.
Прерыватель цепи может находиться в следующих трёх состояниях:
- Замкнут: прерыватель цепи направляет запросы в микросервис и подсчитывает количество сбоев за заданный период времени. Если количество отказов за определённый период времени превышает пороговое значение, он отключается и переходит в разомкнутое состояние.
- Разомкнут: запрос от микросервиса немедленно завершается ошибкой, и возвращается исключение. По истечении времени ожидания прерыватель цепи переходит в полузамкнутое состояние.
- Полузамкнут: только ограниченное количество запросов от микросервиса может пройти и вызвать выполнение операции. Если эти запросы выполнены успешно, прерыватель цепи переходит в замкнутое состояние. Если какой-либо запрос терпит неудачу, прерыватель цепи переходит в разомкнутое состояние.
Преимущества
- Повышение отказоустойчивости микросервисной архитектуры.
- Прерывание каскадной передачи сбоев в другие микросервисы.
Недостатки
- Нужна сложная обработка исключений.
- Дополнительное логирование и мониторинг.
- Необходимость поддержки ручного сброса.
Когда использовать
- В тесно связанной микросервисной архитектуре, где микросервисы обмениваются данными синхронно.
- Если один микросервис зависит от нескольких других микросервисов.
Когда не использовать
- Слабо связанная микросервисная архитектура, управляемая событиями.
- Если микросервис не зависит от других микросервисов.
Поддержка
API Gateway, Service Mesh, various Circuit Breaker Libraries (Hystrix, Reselience4J, Polly.
Подробнее
- Паттерн Прерыватель Цепи
- Microservices Pattern: Circuit Breaker
Источник: https://towardsdatascience.com/microservice-architecture-and-its-10-most-important-design-patterns-824952d7fa41
👍2
День девятьсот шестнадцатый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
93. Пишите код так, как если бы вам пришлось поддерживать его всю оставшуюся жизнь
Спросите сотню программистов, что самое важное должен знать и делать каждый программист, и вы можете получить сотню разных ответов. Это пугающе много советов. Все советы хороши, все принципы верны, и все истории убедительны, но с чего начать? И главное, как начать и продолжить придерживаться всех лучших практик, которые вы усвоили, и как сделать их неотъемлемой частью своей практики программирования?
Я думаю, что ответ кроется в вашем настрое или, проще говоря, в вашем отношении. Если вас не заботят коллеги-разработчики, тестировщики, менеджеры, специалисты по продажам и маркетингу, а также конечные пользователи, то вы не станете, например, использовать разработку через тестирование или писать ясные комментарии https://t.iss.one/NetDeveloperDiary/1109 в своем коде. Я думаю, что есть простой способ изменить свое отношение и всегда стремиться поставлять продукт самого высокого качества:
«Пишите код так, как будто вам придётся поддерживать его всю оставшуюся жизнь.»
Вот и всё. Если вы примете это правило, произойдёт много чудесных вещей. Если бы вы согласились с тем, что любой из ваших предыдущих или нынешних работодателей имел право позвонить вам посреди ночи и попросить вас объяснить, почему вы именно так написали метод fooBar, вы бы постепенно стали профессиональным программистом. Вы, естественно, захотели бы придумывать лучшие имена переменных и методов. Вы бы держались подальше от блоков кода, состоящих из сотен строк. Вы бы искали, изучали и использовали паттерны проектирования https://t.iss.one/NetDeveloperDiary/361. Вы должны были бы постоянно писать комментарии, тестировать свой код и проводить рефакторинг. Поддержка всего кода, который вы когда-либо писали, до конца своей жизни, также должна быть масштабируемой задачей. Поэтому у вас не было бы выбора, кроме как стать лучше, умнее и эффективнее.
Если задуматься, то код, который вы написали много лет назад, по-прежнему влияет на вашу карьеру, нравится вам это или нет. Вы оставляете след своих знаний, отношения, упорства, профессионализма, обязательности и удовлетворённости в каждом методе, классе и модуле, которые вы разрабатываете и пишете. Люди будут формировать мнение о вас на основе кода, который они видят. Если эти мнения будут постоянно отрицательными, вы получите меньше от своей карьеры, чем рассчитывали. Позаботьтесь о своей карьере, о своих клиентах и о своих пользователях в каждой строчке кода: пишите код так, как будто вы должны будете поддерживать его всю оставшуюся жизнь.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Yuriy Zubarev
97 Вещей, Которые Должен Знать Каждый Программист
93. Пишите код так, как если бы вам пришлось поддерживать его всю оставшуюся жизнь
Спросите сотню программистов, что самое важное должен знать и делать каждый программист, и вы можете получить сотню разных ответов. Это пугающе много советов. Все советы хороши, все принципы верны, и все истории убедительны, но с чего начать? И главное, как начать и продолжить придерживаться всех лучших практик, которые вы усвоили, и как сделать их неотъемлемой частью своей практики программирования?
Я думаю, что ответ кроется в вашем настрое или, проще говоря, в вашем отношении. Если вас не заботят коллеги-разработчики, тестировщики, менеджеры, специалисты по продажам и маркетингу, а также конечные пользователи, то вы не станете, например, использовать разработку через тестирование или писать ясные комментарии https://t.iss.one/NetDeveloperDiary/1109 в своем коде. Я думаю, что есть простой способ изменить свое отношение и всегда стремиться поставлять продукт самого высокого качества:
«Пишите код так, как будто вам придётся поддерживать его всю оставшуюся жизнь.»
Вот и всё. Если вы примете это правило, произойдёт много чудесных вещей. Если бы вы согласились с тем, что любой из ваших предыдущих или нынешних работодателей имел право позвонить вам посреди ночи и попросить вас объяснить, почему вы именно так написали метод fooBar, вы бы постепенно стали профессиональным программистом. Вы, естественно, захотели бы придумывать лучшие имена переменных и методов. Вы бы держались подальше от блоков кода, состоящих из сотен строк. Вы бы искали, изучали и использовали паттерны проектирования https://t.iss.one/NetDeveloperDiary/361. Вы должны были бы постоянно писать комментарии, тестировать свой код и проводить рефакторинг. Поддержка всего кода, который вы когда-либо писали, до конца своей жизни, также должна быть масштабируемой задачей. Поэтому у вас не было бы выбора, кроме как стать лучше, умнее и эффективнее.
Если задуматься, то код, который вы написали много лет назад, по-прежнему влияет на вашу карьеру, нравится вам это или нет. Вы оставляете след своих знаний, отношения, упорства, профессионализма, обязательности и удовлетворённости в каждом методе, классе и модуле, которые вы разрабатываете и пишете. Люди будут формировать мнение о вас на основе кода, который они видят. Если эти мнения будут постоянно отрицательными, вы получите меньше от своей карьеры, чем рассчитывали. Позаботьтесь о своей карьере, о своих клиентах и о своих пользователях в каждой строчке кода: пишите код так, как будто вы должны будете поддерживать его всю оставшуюся жизнь.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Yuriy Zubarev
День девятьсот семнадцатый. #Оффтоп
Отбываю в (очень) жаркую страну отдохнуть. Посты продолжат выходить, но, возможно, не такие информативные, как обычно.
А пока сообщу вам, что у нас появилось сообщество на Яндекс.Кью, куда будут дублироваться посты, и где можно пообщаться отдельно. Зачем это всё надо, я пока не совсем понимаю. Просто предложили сделать автопостинг туда, ну пусть будет. Выживет так выживет. Да, посты пока туда публикуются немного криво. Не обессудьте, все вопросы в Яндекс.Кью :)
Ну и напоследок, вот вам очередной комикс от Monkeyuser. Ставь лойс, если он вызвал страшные флешбеки)))
Отбываю в (очень) жаркую страну отдохнуть. Посты продолжат выходить, но, возможно, не такие информативные, как обычно.
А пока сообщу вам, что у нас появилось сообщество на Яндекс.Кью, куда будут дублироваться посты, и где можно пообщаться отдельно. Зачем это всё надо, я пока не совсем понимаю. Просто предложили сделать автопостинг туда, ну пусть будет. Выживет так выживет. Да, посты пока туда публикуются немного криво. Не обессудьте, все вопросы в Яндекс.Кью :)
Ну и напоследок, вот вам очередной комикс от Monkeyuser. Ставь лойс, если он вызвал страшные флешбеки)))
День девятьсот восемнадцатый. #Оффтоп
Неожиданные Преимущества Наставничества. Начало
В какой-то момент вашей карьеры вам вполне могут посоветовать поискать наставника. Идея в том, что, если вас направляет кто-то, кто продвинулся дальше на своём пути, вы сможете двигаться быстрее на своём. Чаще всего это правильный совет. Наличие наставника может дать вам бесценную информацию, наставник может оказать индивидуальную поддержку и заставить вас думать так, как вы иначе не стали бы. Однако сегодня рассмотрим, какие преимущества вам может принести быть наставником для других.
1. Углубляйте знания, обучая других
Изучая что-то новое, большинство людей сосредотачиваются на теории. Они берут новый курс, следуют инструкциям и думают, что дело сделано. Гораздо меньшее количество людей затем приступают к применению полученных знаний на практике. Ещё меньше людей решают учить этому других. Не пройдя весь процесс: изучение теории, практика, обучение других, - вы можете упустить важные нюансы на пути к мастерству.
Даже если вам кажется, что вы знакомы с предметом, всегда найдутся новые подходы и способы осмыслить тему. Обучая других, вам нужно не просто понимать теорию. Вам необходимо так сформулировать основные концепции, чтобы другие поняли и усвоили их. Объяснение концепций другим - отличный способ укрепить и углубить свои знания.
Люди подходят к проблемам с разных сторон. Если вы не отвечаете на вопросы и не решаете проблемы других людей, вы видите предмет только с одной стороны. Часто существует множество способов добиться одного и того же результата. Я обнаружил, что мои ментальные модели и подходы к решению проблем менялись, когда я общался с разработчиками разных уровней опыта.
2. Наставничество улучшает софт скилы
В любой профессии ваш набор навыков можно разделить на две категории: «жёсткие» (hard) и «мягкие» (soft). Жёсткие навыки, как правило, представляют собой «техническую» часть вашей профессии (написание кода, разработка архитектуры, контроль версий и т. д.). Мягкие навыки, такие как общение и командная работа, труднее поддаются количественной оценке. Наставляя других, вы обучаете жёстким навыкам, используя свои мягкие навыки, и у вас обоих есть шанс стать лучше.
Мы уделяем много внимания обучению жёстким навыкам. У нас есть множество курсов, учебных пособий и руководств, рассказывающих о новейших и лучших инструментах и технологиях. Но часто именно ваши мягкие навыки выделяют вас среди других в вашей области.
Хотя это и не строгое правило, вы часто можете слышать, как люди говорят, что они предпочли бы работать с менее технически одарёнными, но более разносторонними товарищами по команде, чем с пресловутой «рок-звездой» без мягких навыков. Время, потраченное на улучшение ваших коммуникативных навыков, командной работы и лидерства путем наставничества других, сделает вас лучше как товарища по команде в вашей профессиональной жизни и не будет потрачено зря.
3. Новые знакомства и построение прочных отношений
Существует не так много способов лучше произвести на кого-то неизгладимое впечатление, чем показать свою готовность помочь человеку и направить его на правильный путь. Наставничество - отличный способ познакомиться с другими людьми из вашей области и расширить круг знакомств.
Ваша профессиональная жизнь - это не только работа, которую вы делаете; это также люди, которых вы встречаете на своем пути. Вы никогда не знаете, кого вы можете встретить, каких друзей и знакомых заведёте. Я до сих пор поддерживаю контакты со многими людьми, которых учил, и даже получил множество запросов на собеседование от компаний, в которых бывший студент рекомендовал меня на должность.
Окончание следует…
Источник: https://stackoverflow.blog/2021/07/07/the-unexpected-benefits-of-mentoring-others/
Автор оригинала - Matt Studdert
Неожиданные Преимущества Наставничества. Начало
В какой-то момент вашей карьеры вам вполне могут посоветовать поискать наставника. Идея в том, что, если вас направляет кто-то, кто продвинулся дальше на своём пути, вы сможете двигаться быстрее на своём. Чаще всего это правильный совет. Наличие наставника может дать вам бесценную информацию, наставник может оказать индивидуальную поддержку и заставить вас думать так, как вы иначе не стали бы. Однако сегодня рассмотрим, какие преимущества вам может принести быть наставником для других.
1. Углубляйте знания, обучая других
Изучая что-то новое, большинство людей сосредотачиваются на теории. Они берут новый курс, следуют инструкциям и думают, что дело сделано. Гораздо меньшее количество людей затем приступают к применению полученных знаний на практике. Ещё меньше людей решают учить этому других. Не пройдя весь процесс: изучение теории, практика, обучение других, - вы можете упустить важные нюансы на пути к мастерству.
Даже если вам кажется, что вы знакомы с предметом, всегда найдутся новые подходы и способы осмыслить тему. Обучая других, вам нужно не просто понимать теорию. Вам необходимо так сформулировать основные концепции, чтобы другие поняли и усвоили их. Объяснение концепций другим - отличный способ укрепить и углубить свои знания.
Люди подходят к проблемам с разных сторон. Если вы не отвечаете на вопросы и не решаете проблемы других людей, вы видите предмет только с одной стороны. Часто существует множество способов добиться одного и того же результата. Я обнаружил, что мои ментальные модели и подходы к решению проблем менялись, когда я общался с разработчиками разных уровней опыта.
2. Наставничество улучшает софт скилы
В любой профессии ваш набор навыков можно разделить на две категории: «жёсткие» (hard) и «мягкие» (soft). Жёсткие навыки, как правило, представляют собой «техническую» часть вашей профессии (написание кода, разработка архитектуры, контроль версий и т. д.). Мягкие навыки, такие как общение и командная работа, труднее поддаются количественной оценке. Наставляя других, вы обучаете жёстким навыкам, используя свои мягкие навыки, и у вас обоих есть шанс стать лучше.
Мы уделяем много внимания обучению жёстким навыкам. У нас есть множество курсов, учебных пособий и руководств, рассказывающих о новейших и лучших инструментах и технологиях. Но часто именно ваши мягкие навыки выделяют вас среди других в вашей области.
Хотя это и не строгое правило, вы часто можете слышать, как люди говорят, что они предпочли бы работать с менее технически одарёнными, но более разносторонними товарищами по команде, чем с пресловутой «рок-звездой» без мягких навыков. Время, потраченное на улучшение ваших коммуникативных навыков, командной работы и лидерства путем наставничества других, сделает вас лучше как товарища по команде в вашей профессиональной жизни и не будет потрачено зря.
3. Новые знакомства и построение прочных отношений
Существует не так много способов лучше произвести на кого-то неизгладимое впечатление, чем показать свою готовность помочь человеку и направить его на правильный путь. Наставничество - отличный способ познакомиться с другими людьми из вашей области и расширить круг знакомств.
Ваша профессиональная жизнь - это не только работа, которую вы делаете; это также люди, которых вы встречаете на своем пути. Вы никогда не знаете, кого вы можете встретить, каких друзей и знакомых заведёте. Я до сих пор поддерживаю контакты со многими людьми, которых учил, и даже получил множество запросов на собеседование от компаний, в которых бывший студент рекомендовал меня на должность.
Окончание следует…
Источник: https://stackoverflow.blog/2021/07/07/the-unexpected-benefits-of-mentoring-others/
Автор оригинала - Matt Studdert
👍1