На своем проекте заметил странное явление, в коде встречалось несколько перечислений примерно такого вида:
enum MyEnum
{
Value1,
NotValue1
}
Я думаю идея понятна. Есть два взаимоисключающих значения. Для этих значений заводится перечисление. Возникает закономерный вопрос: "Зачем?". Кроме лишнего кода этот шедевр больше ничего не привносит в проект. Каждый раз, когда нужно проверить какое-то условие, приходится код примерно такого вида:
if (myValue == MyEnum.Value1)
И так постоянно. Налицо дублирование кода, хоть и в мелких маштабах. От того, что это дублирование мелкое, легче не становится.
Мое мнение, что данное перечисление лучше (и логичнее) было бы заменить на булевое значение. Например сделать что-то наподибие такого:
bool IsValue1
Теперь мы имеем все то же, что было и раньше и при этом избавлены от дублирующегося кода.
Кто будет пойман с поличным (при написании очередного такого перечисления) или случайно (проблем посмотреть, кто этот файл создал в системе контроля версий нет) будет выставлен на публичное осмеяние =))
Зачем нужен enum из двух объектов, если есть булевский тип?
Привязка к производителю
В экономике, привязка к производителю, также известная как имущественная привязка, делает клиента зависимым от поставщика на продуктов и услуг, не давая возможности использовать другой поставщика без существенных издержек переключения. Расходы на привязку, которые создают барьеры для выхода на рынок может привести к недоверию против монополии.
Грибное управление
Грибной управление является аллюзией к компании, где с сотрудниками обращаются, как грибам: держут в темне, удобряют, а когда выросли достаточно большим консервируют. В смысл заключается в том, что руководство принимает решение без консультации с персоналом, которые будут подвежены этим решеням - и, возможно, даже не информируя сотрудников еще долго после того, как решение принято.
Этот феномен является анти-паттерном, который чаще всего можно найти в организациях, которые имеют строгую иерархию и барьеры для межорганизационных связей (особенно с дымоходные организации), но их также можно найти в любой организации.
Моральный риск
Моральный риск вытекает из того, что одна из сторон, огражденая от рисков, может вести себя иначе, по сравнению с тем, как бы она себя вела, если бы в полной мере была подвержена этому риску. В страховании, моральный урон, который происходит без сознательных или вредоносные действий, называется моральным ущербом.
Моральная опасность связана с асимметрией информации, ситуацией, в который одна из сторон в сделке имеет больше информации, чем другая. Сторона, которая изолирована от риска, как правило, имеет больше информации о своих действиях и намерениях, чем сторона, расплачивающаяся за негативные последствия риска. В более широком смысле, моральный риск возникает, когда сторона, имеющая более подробную информацию о своих действиях или намерениях имеет тенденцию или стимул вести себя неправильно с точки зрения менее информированной стороны.
Моральная опасность возникает из-за того, что отдельное лицо или учреждение не несет полную ответственность за последствия своих действий, и, следовательно, имеет тенденцию действовать менее осторожно, чем если бы она несла полную ответственность, заставляя другую сторону нести определенную ответственность за последствия за эти действия. Например, лицо, страхование от кражи автомобиля может меньше волноваться по поводу закрытия автомобиля, потому что негативные последствия от угона транспортного средства являются (частично) ответственностью страховой компании.
Моральная опасность возникает также в проблеме приципал-агент, где одна сторона, называемая агентом действует от имени другого лица, называемого принципалом. Агент, как правило, имеет больше информации о его или ее действиях или намерениях, по сравнению с принципалом, потому что принципал обычно не может полностью контролировать агента. Агент может иметь стимул действовать ненадлежащим образом (с точки зрения принципала), если интересы агента и приципала не совпадают.
Прячьте приведение типов внутрь метода!
В коде была найдена довольно неприятная проблема. Вот пример проблемного кода
GetSelectedObject() as Order
После того, как класс ордер перестал использоваться и стал использоваться другой класс, по всему коду стали возникать ошибки. Т.к. исключение не происходит, но в то же время и работает все неправильно. Проблема оказалась в том, что неправильное приведение типа превращалось в null значение переменной, которое вызывало проблемы (или необычное певедение) в других частях системы. Чтобы потом не выискивать все такие места рекомендую сделать слеющий рефаторинг:
Order GetSelectedOrder()
{
return (Order)GetSelectedObject();
}
Метод получение выделенного ордера использовать повсеместно. Если тип объекта поменяется сразу возникает исключение и исправлять придется в одном месте.
Примечания:
Оператор AS является довольно опасным. Т.к. может прятать настоящие ошибки и порождать совсем другие. Чаще всего NullReferenceException в других местах приложения, где их быть не должно. Я уже вижу возражения, что он быстрее чем оператор приведения типа (Cast). Так вот, хочу вас расстроить, последние версии .NET Framework хорошо улучшили скорость работы оператора приведения типов. Особого выигрыша от использования операбота AS вы не почувствуете.
Дальнейшим развитием идееи может служить добавление строго типизированного метода добавление элементров в коллекцию:
AddOrder(Order order)
{
AddObject(order)
}
При таком подходе будет трудно добавить объект неправильного типа в коллекцию.
Бог-громовержец
Управление богом-громовержцем является шведским выражением для описания финского подхода в руководстве, которое, по мнению его сторонников, принимает решаение быстрее и оперативнее, по сравнению с длительным обсуждением и анализом всех возможных подходов и точек зрения, прежде чем ничего не предпринять. Это особенно контрастирует с шведским принятием решений на основе консенсуса, когда менеджер должен убедиться в том, чтобы все участники обсуждения были заслушаны до принятия решения.
Название происходит от известного финского ругательства perkele (бог-громовержец), и это ссылка на неоднократные повторения этого слова со стороны топ-менеджеров.
В отличие от своего первоначального значения, выражение также иногда используются при описании авторитарного стиля руководства старой финской армии (которое не оставляет возможности для несогласия или расхождения во мнениях и требует слепого повиновения). Это означает, что какие-либо особые мнения устраняются посредством угрозы силой со стороны руководства. Обратной стороной этого подхода является то, что она создает атмосферу эффективности и прямолинейности; каждый знает, что он или она должны делать. Задачи и цели могут быть достигнуты более оперативно и эффективно по сравнению с неавторитарной атмосферой, к тому же любые проблемные ситуации могут быть решены без обсуждения.
В этом смысле "управление громовержцем" подразумевает неизбирательное применение армейских методов в гражданской жизни - экспорт практик, которые следовало бы использовать для одной конкретной сфере, в другую, где они могут иметь неоднозначные результаты. Финские вооруженные силы имеют прусские традиции дисциплины: когда ожидается подчинение без каких либо вопросов.
К сожалению, традиции прусский дедовщины, - которые были устранены в последнее время в армии - продолжают сущестовать. Старая "армейская философия" основана на вселении страха и неуверенности в подчиненных. Она также может рассматриваться как организационная издевательств на рабочем месте. В экспертных организация, в которых присутсвует запугивание могут прекратиться положительных результаты, потому как сотрудники будут слишком запуганы чтобы высказывать альтернативные идеи. Это также отстранению исключению индивидуумов от командной работы, так как страх перед коллегами приводит к общению только с теми, кому можно доверять.
По сравнению с другими странами или групп населения, как Финляндия и Швеция являются крайне индивидуалистической культурами, так что это не следует рассматривать как заявление о том, что Финляндия имеет культуру "послушания"
Эскалация обязательств
Эскалация обязательств впервые была описана Барри М. Стов в своем документе, 1976, "По колено в большой мути: Исследование эскалации обязательств в соответствии выбранным планом действий". В последнее время термин невозвратные расходы ошибочно был использован для описания этого явления, когда люди оправдывают увеличение инвестици в решение, основываясь на величину прежних совокупных инвестиции, несмотря на новые доказательства того, что это решение было, вероятно, неправильно. Такие инвестиции могут включать в себя деньги, время, или - в случае военной стратегии - человеческие жизни.
Этот термин используется также для описания плохих решений в бизнесе, государственных, информационных системах в целом, программном обеспечении управления проектами, в частности, политике, а также азартных игра. Этот термин используется для описания участия Соединенных Штатов в военных конфликтах, в том числе Вьетнаме в 1960-х - 1970-х годах и в Ираке в 2000, когда США тратили деньги и жизни для оправдания продолжение участия.
С другой стороны, нерациональная эскалация (иногда называемся нерациоальной эскалацией обязательств) представляет собой термин, часто используемых в психологии, философии, экономике и теории игр для обозначения ситуации, при которых человек может сделать иррациональных решения, основанные на рациональных решения в прошлом, или для оправдания уже принятых мер. Примеры этого часто можно увидеть, на примере сторон участвующют в торговых войнах. Участники торгов могут в конечном итоге могут потратить гораздо больше, чем стоит объект торгов на самом деле для оправдания первоначальных затрат, связанных с торгами.
Обо мне
Теги
- .NET (1)
- Anti-Patterns (16)
- ASP.NET (3)
- Bug fixes (1)
- C# (5)
- Code Review (4)
- Fun (1)
- Naming (1)
- Refactoring (20)
- Team rules (2)
- Web (2)
Архив
-
▼
2009
(18)
-
▼
Май
(18)
- Зачем нужен enum из двух объектов, если есть булев...
- Привязка к производителю
- Грибное управление
- Моральный риск
- Прячьте приведение типов внутрь метода!
- Бог-громовержец
- Эскалация обязательств
- Коллективное проектирование
- Дойная корова
- Паралич от анализа
- Методологические aнти-паттерны
- Анти-паттерны программирования
- Объектно-ориентированные анти-паттерны
- Анти-паттерны проектирования программного обеспече...
- Анти-паттерны анализа
- Анти-паттерны управления
- Организационные анти-паттерны
- Введение в анти-паттерны
-
▼
Май
(18)
-
►
2008
(10)
-
►
Июль
(9)
- Custom configuration section
- Dont' use RAR archives for files
- What is the difference between Server.Transfer and...
- Notify your team when yor are going to leave the o...
- Use "Is" prefix for methods with boolean return va...
- Use Path class instead of string manipulations
- Remove old unused code
- What should you do to become good prorammer?
- IE 7.0 cookie problem
-
►
Июль
(9)

