Примеры того, что может случиться… 1
• Ноябрь 1999 года. Дилер облокотился на клавиатуру и случайно продал 16 тыс. акций компании Premier Oil общей стоимостью более 1, 8 млн фунтов
В какой валюте? • Ноябрь 2002 года. Клерк брокерской фирмы, выставляющий котировки компании Ryanair, перепутал цену акций в евро и фунтах. Эта ошибка мгновенно подняла индекс Лондонской фондовой биржи на 61% с 404, 5 до 653, 7 пункта.
Промахнулись… • Декабрь 2005 года. Рекордную ошибку допустил трейдер японской компании Mizuho Securities. Брокер получил заказ на продажу одной акции рекрутинговой компании J-Com. Это случилось в первый же день торгов J-Com: накануне компания разместила акции по цене 610 тыс. иен (5 тыс. долларов). Брокер по ошибке ввел в компьютер заказ на продажу 610 тыс. акций по цене одна иена. Ошибку заметили сразу же, но на запросы об отмене заказа компьютерная система биржи не отреагировала. По оценке газеты "Ведомости", ущерб Mizuho Securities составил более 40 млрд иен (341 млн долларов). Притом, что всего у компании было 14 тыс. акций, размещение заказа вызвало хаос на рынке, основной рыночной индекса Nikkei 225 обвалился на 301 пункт. Спустя две недели после случившегося в отставку ушло руководство Токийской биржи. Тогда же были введены новые правила, требующие, чтобы брокерские компании проверяли на предмет возможных ошибок все заказы на покупку или продажу более 5% акций компании.
Точка, запятая – какая разница? ? ? • Неудача при запуске первого американского спутника к Венере случилась из-за ошибки в программе – вместо требуемой в операторе запятой программист поставил точку. Вот как был записан этот оператор: DO 50 I = 12. 525 На самом же деле он должен был выглядеть следующим образом: DO 50 I = 12, 525 В программе на Фортране IV требовался цикл, а программист поставил точку, а в результате получилось присваивание значения 12, 525 неявной переменной DO 50 I (пробелы в Фортране игнорируются)
Да и вообще что такое знак припинания? • Потерянный дефис НАСА Ущерб: $80 миллионов Дефис – далеко не самый важный знак препинания, однако в 1962 году его отсутствие в коде бортового компьютера стоило НАСА 80 миллионов долларов. Речь идёт о запуске направлявшегося к Венере космического аппарата «Маринер-1» , который вследствие маленькой ошибки потерял управление и был уничтожен на 293 секунде после старта.
Еще один пример знака пунктуации (самая дорогая запятая в истории) • • Август 2006 года, дело о «самой дорогой запятой в истории Канады» . Речь идет о конфликте канадских компаний Rogers Communications Inc. и Aliant Inc. Суд обязал крупнейшего канадского провайдера услуг беспроводной передачи данных Rogers Communications Inc. выплатить дополнительные 2, 13 миллионов долларов Aliant Inc. после расторжения договора между ними. В 2002 году между компаниями был заключен договор, содержавший пункт о том, что он «вступает в силу в день подписания и остается в силе в течение пяти лет со дня подписания, а затем может быть продлен на пятилетние периоды, если только не будет расторгнут любой из сторон, подавшей о том письменное уведомление не позднее, чем за год до расторжения» . Таким образом Rogers считала, что до 2007 года договор является нерасторжимым, а в 2006 году станет ясно, будет ли он автоматически продлен еще на пять лет. Однако в 2005 году Aliant присылает уведомление о расторжении договора. Камнем преткновения стала злосчастная запятая, из-за которой данный пункт соглашения сторонами интерпретировался (в английском написании) по-разному: представители Rogers утверждали, что условия относятся только к дополнительному сроку, а представители Aliant, основываясь на пунктуационную норму английского языка, – как к дополнительному, так и к основному. Решение было вынесено в пользу компании Aliant, которая получила право разорвать контракт в 2006 году. Это позволило ей значительно повысить плату за свои услуги (с $9. 60 за каждую используемую вышку до $28. 05), из-за чего Rogers потеряло более двух миллионов долларов – такова стоимость одной запятой.
Опечатка • Ошибка бухгалтерии Министерства образования штата Нью-Йорк привела к тому, что сумма, предназначенная на развитие городского школьного транспорта, увеличилась в два раза. Оказалось, что в одном из слов по невнимательности бухгалтера появилась лишняя буква, и бухгалтерская программа не смогла распознать его. Эта ошибка была обнаружена в ходе аудиторской проверки в июне 2006 года, она привела к тому, что на транспорт было потрачено 2, 8 миллионов долларов вместо запланированных 1, 4 миллионов. Городским властям пришлось возместить разницу.
ФБР, конец проекта "Трилогия" (2005) • Потери: 105 млн долларов. Катастрофа. Компьютерная система, обеспечивавшая работу проекта Trilogy для ФБР, сломалась во время попытки модернизации и капитального ремонта после четырех лет успешной работы. Огромный виртуальный проект Trilogy представлял собой интегрированный программно-технический комплекс, при помощи которого многочисленные агенты ФБР имели возможность делиться материалами дел и прочей информацией друг с другом. Причина. Нерациональное планирование и попытка построить долгосрочный проект на технологиях, которые устарели прежде, чем проект был завершен, в результате система получилась чересчур сложной и непригодной для использования.
Британские паспорта (1999) • Потери: 12, 6 миллионов фунтов стерлингов, огромные неудобства для многих граждан. Катастрофа. Агентство Великобритании по выдаче паспортов внедрило новую компьютерную систему Siemens, которая вместо ускорения столь важной для каждого государства процедуры, не смогла своевременно обеспечить выдачу новых паспортов для полутора миллионов граждан Королевства. Агентство было вынуждено выплатить миллионы фунтов стерлингов в качестве компенсации, сотрудники работали сверхурочно, для людей, находившихся в очереди ожидания паспорта под дождем, даже раздавали бесплатные зонтики. Причина. Паспортное агентство приняло в эксплуатацию новую компьютерную систему без адекватного тестирования или обучения своих сотрудников. В это же время в Великобритании вышел новый закон, требующий обязательной замены паспортов для всех детей в возрасте до 16 лет, выезжающих за рубеж, в результате чего за новыми паспортами выстроились огромные очереди. К несчастью, новую компьютерную систему очень быстро удалось перегрузить.
Прогноз погоды • В 1983 году произошло наводнение в югозападной части США. Причина заключалась в том, что в компьютер были введены неверные данные о погоде, в результате чего он дал ошибочный сигнал шлюзам, перекрывающим реку Колорадо
Современные самолеты - компы • 2007 год - Из-за ошибки определения времени при смене часовых поясов 12 истребителей F-22 остались без автопилота, навигации и связи. Вернуться им помогло только чудо.
Доставили • Склад-автомат в ближайшем Подмосковье, принадлежащий логистической фирме, арендуется кучей компаний для ответственного хранения продукции. Вдоль высоченных многоэтажных стеллажей с десятками тысяч паллет бодро носятся по направляющим каретки автоматических погрузчиков, хватают заказанную продукцию и доставляют её в нужное место. Одна маленькая, но очень гордая каретка из-за ошибки в коде позиционирования, не сбавляя скорости, доходит до края стеллажа, слетает с направляющих и срезает несущую балку. Весь склад с дорогостоящей техникой и продукцией на миллионы долларов складывается за несколько минут, как карточный домик. 13
Обрушение стадиона Хартфорд Колизей (1978) • Потери: 70 млн долларов плюс 20 млн долларов ущерба местной экономике. Катастрофа. 18 января 1978 года, в начале пятого ночи, всего через несколько часов после того как тысячи фанатов покинули арену стадиона Хартфорд Колизей (Hartford Coliseum), стальная решетчатая крыша сооружения рухнула под тяжестью мокрого снега. Причина. Программист САПР (Системы автоматизированного проектирования), используемой при разработке проекта стадиона Колизей в городе Хартфорде, ошибочно предположил, что опоры, которые поддерживают стальную крышу гигантского сооружения, работают только на чистое сжатие. Но когда одна из опор неожиданно прогнулась под воздействием снега, это вызвало цепную реакцию, которая сложила всю конструкцию вместе с другими участками крыши, как костяшки домино 14
Медицинское оборудование убивает • Потери: три человека погибли, трое тяжело раненых Катастрофа. Из-за неисправности аппарата лучевой терапии Therac-25 несколько пациентов получили смертельные дозы облучения во время медицинского обследования в Канаде. Причина. Из-за специфической ошибки, которая называется "Состояние гонки" (race condition), допущенной при проектирования аппарата, существовала возможность случайной настройки Therac-25 на режим генерирования мощного пучка электронных частиц без надлежащего экранирования и защиты пациента. Состояние гонки - это ошибка проектирования системы, при которой ее работа зависит от того, в каком порядке выполняются части программного кода. Ошибка проявляется, как правило, в случайные моменты времени и "прячется" при попытке ее локализовать. 15
Взрыв ракеты Ariane (1996) • Потери: 500 млн долларов. Катастрофа. Новейшая европейская беспилотная ракета Ariane-5 была уничтожена через 36, 7 секунды после старта с космодрома Куру во Французской Гвиане. Вместе с ракетой-носителем погиб груз из четырех научных спутников, которые ракете предстояло вывести на орбиту для изучения того, как магнитное поле Земли взаимодействует с солнечным ветром. Причина. Сбой произошел, когда компьютер системы управления ракетой попытался конвертировать числовое значение скорости ракеты из 64 разрядного в 16 -разрядный формат. Число было слишком большим и вызвало ошибку переполнения. После отказа основной системы управления контроль над ракетой был передан резервному модулю, которому также не удалось выполнить аналогичную операцию по в общем-то несложному преобразованию, так как он использовал тот же алгоритм и такое же программное обеспечение. На создание ракеты Ariane-5 Европейским Космическим Агентством было потрачено десять лет и семь миллиардов долларов. К сожалению, Ariane-5 оказалась немножко быстрее своей предшественницы Ariane-4, а внести соответствующие корректировки в программное обеспечение почему-то забыли. 16
Mars Climate Crasher (1998) • Потери: 125 млн долларов. Катастрофа. После 286 -дневного путешествия от Земли до красной планеты, космический зонд Mars Climate Orbiter включил свои двигатели для выхода на орбиту вокруг Марса. Двигатели запустились, но космический аппарат, вследствие чересчур резвого старта, слишком глубоко вошел в атмосферу планеты (он достиг высоты в 60 км над поверхностью, на сто километров ниже планируемой орбиты и на 25 км ниже высоты, на которой еще можно было исправить ситуацию), а через некоторое время его обломки, скорее всего, таки достигли поверхности Марса. Такая же участь постигла космический аппарат Mars Polar Lander. А ведь эти зонды должны были заняться изучением марсианской погоды и климата, анализом содержания в атмосфере планеты различных газов. Причина. В программном обеспечении, контролирующем двигатели Орбитера и Ландера использовались имперские единицы силы (фунты), а не метрические (ньютоны), как впоследствии признались эксперты комиссии НАСА. 17
• Airbus A 380 и совместимость программного обеспечения Потери: дополнительный год проектных работ. Катастрофа. Проблема, возникшая перед авиационным гигантом Airbus в 2006 году знакома многим компаниям, которые имеют дело с программным обеспечением: это часто происходит, когда одна программа не может взаимодействовать с другой. В этом случае проблема была вызвана двумя версиями одной программы, программного обеспечения CATIA, которое используется для проектирования и сборки одного из крупнейших самолетов в мире, Airbus A 380. Обнаружилась проблема во взаимодействии между двумя организациями в группе: французской Dassault Aviation и заводом в Гамбурге. Причина. Оказалось, что немецкая система использовала не обновленную версию CATIA, а французская - самую последнюю версию, хотя обе стороны работали над проектом одного самолета. Поэтому, когда Airbus на завершающей стадии проектирования была предпринята попытка объединения двух половинок одного самолета, столь небольшое различие в программном обеспечении обернулось тем, что параметры монтажа одной половины проекта не соответствовали и не совпадали с проводкой в другом. Кабели не могли соединяться без существенных изменений и доработок в обоих частях проекта. Проблема была в конечном счете решена, на это потребовались деньги и время, работа над проектом растянулась еще на год. Своей вины за случившееся не хотели признать ни проектировщики, ни программисты. 18
Антипаттерны • анти-паттерны — шаблоны ошибок, которые совершаются при решении различных задач. • Частью практик хорошего программирования является именно избегание анти-паттернов. 19
Про что будет обзор? • Количество проблем, которые могут возникнуть – бесконечно. • Естественно разбираем IT • Причин проблем – тоже может быть очень большое множество • Мы сконцентрируемся на проблемах кода и того, что близко к коду
Классификация антипаттернов IT • С точки зрения разработчика выделяют: – Антипаттерны программирования • Проблемы реализации – Антипаттерны проектирования • Проблемы структуры системы – Антипаттерны управления • Проблемы управления проектом 21
Основные источники проблем ЛЮДИ программисты менеджеры заказчики 22
Назначение антипаттернов • Позволяют идентифицировать проблему прежде, чем она перерастет в угрозу для проекта или организации • Обеспечивают классификацию проблемных ситуаций и способов их решения • Упрощают поиск решения проблемы • Позволяют реализовать единый подход к решению организационных проблем и эффективное использование ресурсов 23
Антипаттерн проектирования- Паралич от анализа (Analysis Paralysis) Проблема: Много времени потрачено на анализ Доведение до мнимого «совершенства» Идея-фикс – найти все проблемы до начала кодирования 24
Предложения для решения проблемы?
Решение: Придерживаться итеративной разработки
А какие были у вас примеры?
Антипаттерн проектирования - Забивать гвозди микроскопом (All you have is a hammer) Проблема: • Решение всех задач одним способом 28
Предложения для решения проблемы?
Решение: • Будьте открыты для всего нового 30
Что будет, если не обращать много раз на мелкие проблемы? • Антипаттерн проектирования – большой комок грязи • Пример – все тестовое задание на C# в виде одной БОЛЬШОЙ функции (или двух) – на след. слайде 31
Две функции • • using System; using System. IO; using System. Collections. Generic; using System. Text; • • • namespace Txt. To. Html { class Txt. To. HTMLConverter { private int Max. Output. File. Lines; // Максимальное количество строк в выходном файле • • private File. Stream Text. File. Stream; // Поток для чтения файла с текстом private Stream. Reader Text. File. Reader; // • • private File. Stream Dictionary. Stream; // Поток для чтения файла словаря private Stream. Reader Dictionary. Reader; // • • private string current. Word = ""; // Текущее слово private char current. Symbol = ' '; // Текущий символ • • private string in. Line; // Прочитанная из файла строка private string out. Line; // Строка результат • • private int Out. Line. Count; // Число строк в выходном файле (текущее) private int Out. File. Number; // Номер выходного файла • • private File. Stream Output. Stream; // Поток для записи в выходной файл private Stream. Writer Output. Writer; // • private Dictionary
« 7 смертных грехов программирования» 1. Поспешность 2. Пассивность 3. Ограниченность 4. Лень 5. Алчность 6. Некомпетентность 7. Гордость
1. Поспешность (Haste) • “Just “clean up” the code. We ship tomorrow” • Поспешные и необдуманные решения (особенно в условиях сжатых сроков) могут привести к: – Постановке недостижимых целей; – Отказу от преимуществ долгосрочных архитектурных решений в пользу экономической выгоды; – Отказу от полноценного тестирования; – Снижению качества программного продукта; 34
2. Пассивность (Apathy) • “Reuse? Reuse!! Who’s every gonna reuse this crappy code? NO ONE!” • Проблема проявляется в том, что разработчики не уделяют должного внимания решению хорошо известных и изученных проблем, считая это рутинной работой • Последствия: – Введение непредусмотренных зависимостей – Снижение стабильности системы – Усложнение модификации и расширения системы 35
3. Ограниченность (Narrow-Mindedness) • “I don’t need to know… and I don’t care to know” • Ограниченность проявляется в нежелании или невозможности разработчиков использовать решения, эффективность которых подтверждена практикой и широко известна • Проблемы: – Увеличение затрат времени и средств на разработку проекта – Ограничение функциональности продукта – Снижение управляемости изменений 36
4. Лень (Sloth) • “Sloth usually ends with sudden clarity” • Лень заставляет разработчиков выбирать решения, исходя из простоты реализации и минимизации локальных усилий, а не повышения эффективности системы в целом • Последствия принятия “ленивых” решений: – Частые изменения интерфейса – Значительная часть времени тратится на изучение поведения очередной версии системы – Документация быстро теряет актуальность – Повторное использование типа “белый ящик” 37
5. "Алчность" (Avarice) • “It certainly is complicated! I’m sure our clients will be very, very impressed!” • В процессе проектирования нередко возникает желание “улучшить” систему путем увеличения ее сложности • Проблемы: – – – Введение избыточной сложности Увеличение стоимости проекта и его рисков Увеличение времени разработки Усложнение разработки и сопровождения Повышение требований к квалификации разработчиков Итогом часто является выпуск продукта низкого качества и даже провал проекта 38
6. Некомпетентность (Ignorance) • “I don’t really have time to read this…” • Возникает в ситуации, когда разработчики не хотят или не имеют возможности изучать документацию системы • Последствия: – Появление непредусмотренных зависимостей – Снижение стабильности системы – Снижение качества продукта 39
7. "Гордость" (Pride) • “Attention! New Company Motto: ZERO DEFETCS” • Гордость проявляется в отказе от использования готовых решений и разработке собственных, но полученных в результате обратного проектирования существующего программного кода • Проблемы: – Увеличение сроков разработки – Появление новых рисков 40
Как надо писать код • Надо писать код так просто, что бы любой человек смог в нем разобраться. • Надо писать код так, что бы никто в нем не мог разобраться и побоялся его трогать • И все это еще с тестами для спокойствия
Антипаттерны • Программы пишутся человеком. Для машины. Но сопровождать их будет человек, поэтому и для человека тоже. • Таинственный код (Cryptic code): Использование аббревиатур вместо мнемоничных имён. 42
Класс Form 1 Отвечает за выполнение входа и перехода на окно регистрации В системе взаимодействует с Form 2, Form 3 Класс Form 2 Отвечает за регистрацию Взаимодействует с Form 1, взаимодействует с БД Класс Form 3 Отвечает за выполнение входа в программу по логину и паролю Взаимодействует с Form 1, Form 4 Класс Form 4 Отвечает за предоставление выбора пользователю между каталогом приложения и загрузкой своих изображений Взаимодействует с Form 6, Form 5 Класс Form 5 Отвечает за загрузку пользовательских изображений взаимодействует с Form 4 Класс Form 6 Отвечает за выбор стиля одежды перед тем, как перейти в каталог Взаимодействует с View Класс View Отвечает за просмотр одежды каталога, примерки и просмотра её на манекене Взаимодействует с БД, с Form 8, Zoom. Form Класс Form 8 Отвечает за содержание корзины и удаление оттуда одежды Взаимодействует с Form 9, с БД Класс Zoom. Form Отвечает за увеличение изображения для удобства просмотра Взаимодействует с View Класс Form 9 Отвечает за выбор цвета одежды и количества Взаимодействует с БД, Form 7 Класс Form 7 Отвечает за формирование отчетов Взаимодействует с Send_Mail Класс Send_Mail Отвечает за отправку на почту клиента информации о заказе Взаимодействует с Form 10 Класс Form 10 Отвечает за выход из программы или возвращение в начало приложения Взаимодействует с Form 1 43
Что улучшить • Дать нормальные имена переменным 44
• • • • • • • for (int i = 0; i < text. Box 7. Text. Length; i++) { if ((int)text. Box 7. Text[i] < 48 || (int)text. Box 7. Text[i] > 57) { Message. Box. Show("Номер телефона не корректен!"); text. Box 7. Text = ""; } if (text. Box 1. Text != string. Empty && text. Box 2. Text != string. Empty && text. Box 3. Text != string. Empty && text. Box 4. Text != string. Empty && text. Box 5. Text != string. Empty && text. Box 7. Text != string. Empty & combo. Box 2. Text != string. Empty) { //Random id = new Random(); //int id_client = id. Next(0, 10000); string login = text. Box 1. Text; string password = text. Box 2. Text; string fio = text. Box 3. Text; string sex = text. Box 4. Text; // int size = 42; //Convert. To. Int 32( f. text. Box 5. Text); string phone_number = text. Box 5. Text; string e_mail = text. Box 7. Text; string address =combo. Box 2. Text; int size = Convert. To. Int 32(combo. Box 1. Text); Uprav. Class u = new Uprav. Class(); Form 1. id_size = Convert. To. Int 32(combo. Box 1. Text); u. ADD_client( /*id_client, */login, password, fio, sex, phone_number, e_mail, address, size); 45
Предложения для решения проблемы?
Методики по исправлению антипаттенов (возможно добавить примеров) • Для исправление всех антипаттернов, кроме кодирования – методология кайдзен • Для исправления антипаттернов в существующем коде – рефакторинги • Для обнаружения антипаттернов – метрики, легкость тестируемости, знание антипаттернов
Что улучшить • Можно уменьшить цикломатическую сложность кода • Можно переменных объявить до проверки и тогда проверка хоть будет более читаемой • Программисты – люди и все от психологии им близко. Средний программист может держать в памяти 3 -7 объектов. 48
Из опыта Возможные названия сортировок • • • Sorting Quick. Sortirovka Sortir Tree. Sort
Антипаттерн • Преждевременная оптимизация (Premature optimization): Оптимизация на ранних стадиях в ущерб хорошему дизайну, сопроводимости и иногда даже реальной эффективности системы. 50
Пример • Есть Sync Framework, которая позволяет синхронизировать изменения в данных таблиц • На МАРСЕ начальство поставило задачу это реализовать. • После реализации выяснилось, что между отделать по соображениям безопасности нет связи вообще и задача могла быть решена просто добавлением атрибута создания записи. По бизнес-логике получилось, что два подразделения не могут одновременно работать над одним и тем же проектом 51
Предложения для решения проблемы?
Что улучшить • Любая задача пишется для заказчика, который платит деньги. • Он думает, что знает все. На самом деле часто это не технический специалист, поэтому надо потратиться на выяснение того, что реально ему надо и частоте использования функций 53
Антипаттерн • Вызов предка (Call super): Для реализации прикладной функциональности методу класса-потомка требуется в обязательном порядке вызывать те же методы классапредка. • Пример из автоматических действий в проекте на след. слайде 54
Пример public abstract class Base. Subroutine : ISubroutine { public Date. Time Last. Run { get; set; } public virtual Time. Span Run. Interval {…} public virtual void Run() { Last. Run = get. Now; } } namespace Auto. Actions { public class Delete. User : Base. Subroutine { public override Time. Span Run. Interval {…} public override void Run() { using(var db = new Sila. Db. Context()) { var users. For. Deleting = db. user. Where(u =>u. Is. Blocked). To. Array() foreach (var del. User in users. For. Deleting) { …. } db. Save. Changes(); } base. Run(); } } 55
Предложения для решения проблемы?
Что плохо и надо изменить • Абстрактный класс без абстрактного метода • При перегрузке метода необходимо не забыть вызвать метод базового класса для установки времени последнего вызова • Что надо – добавить абстрактный метод, который вызывать в базовом 57
Что изменить? public abstract class Base. Subroutine : ISubroutine { public Date. Time Last. Run { get; set; } public virtual Time. Span Run. Interval {…} public abstract void Action(); public void Run() { Action(); Last. Run = get. Now; } } namespace Auto. Actions { public class Delete. User : Base. Subroutine { public override Time. Span Run. Interval {…} public override void Action() { using(var db = new Sila. Db. Context()) { var users. For. Deleting = db. user. Where(u =>u. Is. Blocked). To. Array() foreach (var del. User in users. For. Deleting) { …. } db. Save. Changes(); } } 58
Программирование методом копирования-вставки (Copy and paste programming). Общая характеристика • Общая характеристика – Боязнь рефакторинга чужого кода, который не покрыт тестами – Не знание основ ООП – Нет абстрагирования – Кривые руки 59
Характерные признаки • Похожий код • Программист используется Ctrl+C, Ctrl+V, Ctrl+Insert, Shift+Insert 60
Пример • • • • • • • • public View(Image. List Up, Image. List Down, Image. List Full) { Initialize. Component(); up = Up; down = Down; full = Full; picture. Box 1. Mouse. Down += picture. Box 1_Mouse. Down; picture. Box 2. Allow. Drop = true; picture. Box 2. Drag. Enter += picture. Box 2_Drag. Enter; picture. Box 2. Drag. Drop += picture. Box 2_Drag. Drop; back. Ground = new Picture. Box(); back. Ground. Image = picture. Box 2. Image; if (up. Images. Count != 0) { picture. Box 1. Image = up. Images[0]; } if (full. Images. Count != 0) { full_pic. Image = full. Images[0]; } if (down. Images. Count != 0) { down_pic. Image = down. Images[0]; } public View() { } public View(Image. List Up, Image. List Down, Image. List Full, Dictionary
Предложения для решения проблемы?
Решение • Заставить прочитать книгу по рефакторингам • Использовать тесты, что бы было не страшно исправлять чужой код 63
Затычка на ввод данных (Input kludge): Отсутствие корректной обработки возможного неверного ввода. • Общая характеристика: – В коде нет обработки неверного ввода или глушение ошибок 64
Характерные признаки: • Нет валидации входных данных • Все обрамлено глобальным try catch 65
Пример • Кто в тестовом задании рассматривал возможность наличия текста • жирный • который после обработки должен остаться таким же, а не преобразоваться в html тэги 66
Предложения для решения проблемы?
Что делать • Почитать, как тестировать, что такое эквивалентные множества, крайние значения и т. д. 68
Затычка на ввод данных (Input kludge): Отсутствие корректной обработки возможного неверного ввода. • Загрузка из csv файла – экранирование запятых • Тестовое задание – отсутствие проверки наличия html тегов • Примеры из дорогих ошибок – не было проверки, что такое количество акций у фирмы вообще есть. 69
Предложения для решения проблемы?
Из опыта • Была Оля в проекте. Ей сказали отверстать страницу. Она сказала, что сможет. Продемонстрировала на своем экране отверстанную страницу… было нормально • Потом она ушла • Потом открыли её творение… – Выравнивание по центру было сделано смещением от левого края на нужный размер, который был вычислен от фиксированного размера карточки товара Переписали все, что она сделала. Причем это еще было в CSS, и наверно там остался мусор
Глушение ошибок Error Hiding • Антипаттерн: – Error Hiding • Причины появления: – Лень – Некомпетентность 72
Общая характеристика • Отслеживание возникающих в системе сбоев очень сложно, а зачастую невозможно • Ошибки уходят в никуда 73
Характерные признаки • Система работает не так, как положено, но логи безоблачно чисты • Система выводит пользователю красивые «Извините, но. . . » , а логи безоблачно чисты • Пользователи жалуются, что ничего не работает, но логи с production безоблачно чисты 74
Наглядный пример try { Input. Stream is = new // do smth. . . File. Input. Stream("hello. txt"); } catch (IOException ex) { throw new User. Visible. Message. Exception(“EEVIL!”); } 75
Предложения для решения проблемы?
Решение • Передача изначального исключения наверх • Если необходимо вызвать специальное исключение, то исходное нужно зафиксировать в логах • Внутренние исключения • Не допускать сокрытия ошибок в дальнейшем 77
Магическая (волшебная) кнопка (Magic pushbutton): Написание бизнеслогики в коде пользовательского интерфейса (например в обработчике события нажатия на кнопку). • Пример – samplessrc 78
Предложения для решения проблемы?
Один из вариантов обнаружения проблем - метрики кода
В VS есть возможность вычисления Code metrics • Maintainability Index – комплексный показатель качества кода. Чем больше – тем лучше • Cyclomatic Complexity – показывает структурную сложность кода, т. е. количество различных ветвей в коде. Чем больше этот показатель, тем хуже. • Depth of Inheritance – глубина наследования. • Class Coupling – степень зависимости классов друг с другом. Чем больше, тем сложнее в дальнейшем переиспользовать этот класс, а также поддерживать, т. к. существует очень много зависимостей. • Lines of Code – показывает количество строк кода (основан на IL -коде) Большое количество строк в методе/классе может показывать на ошибки в проектировании и на то, что этот код можно разделить на несколько частей.
Maintainability Index • комплексный показатель качества кода. Рассчитывается метрика по следующей формуле: MI = MAX(0, (171 — 5. 2 * ln(HV) — 0. 23 * CC — 16. 2 * ln(Lo. C)) * 100 / 171) – HV – Halstead Volume, вычислительная сложность. Чем больше операторов, тем больше значение этой метрики; – CC – Cyclomatic Complexity. – Lo. C – количество строк кода. Эта метрика может принимать значения от 0 до 100 и показывает относительную сложность поддержки кода. Чем больше значение этой метрики, тем легче поддерживать код. Теория - Visual Studio помечает методы/классы зеленым цветом, если значение метрики находится в пределах от 20 до 100, желтым цветом, если значение находится в пределах от 10 до 20, и красным цветом, когда значение меньше 10.
Практика – оценка 28 для кода
11 й уровень вложенности… public override void Action() { int investment. Order. Lifetime = Configuration. Get
Вывод из практики • В районе 60 – нормально, можно понять. Ниже - проблемы
Cyclomatic Complexity • показывает структурную сложность кода, т. е. количество различных ветвей в коде. Чем больше этот показатель, тем больше тестов должно быть написано, для полного покрытия кода.
Depth of Inheritance • глубина наследования. Эта метрика показывает для каждого класса, какой он по счету в цепочке наследования. • A – 1 • B – 2 • C - 3
Class Coupling • показывает степень зависимости классов друг с другом. В расчет берутся уникальные классы из параметров, локальных переменных, возвращаемого типа, базового класса, атрибутов и т. д. Хороший дизайн программного обеспечения предполагает небольшое количество связанных классов. Чем их больше, тем сложнее в дальнейшем переиспользовать этот класс, а также поддерживать, т. к. существует очень много зависимостей.
Lines of Code • показывает количество строк кода. Этот показатель показывает не точное количество строк в вашем файле, подсчет основан на IL-коде. • Большое количество строк в методе/классе может показывать на ошибки в проектировании и на то, что этот код можно разделить на несколько частей.
Вопросы для аудитории • Какие вынужденные отклонения от идеального состояния приходилось делать? • Было ли это одноразовым или многоразовым? • Какие самые плохие случаи в проектах помните и какие были их причины?
Кайдзен • Суть концепции кайдзен – улучшение или совершенствование. Слово “кайдзен” состоит из двух иероглифов – «изменения» и «хорошо» . Изменяй к лучшему, изменяйся к лучшему. Причем изменяться надо немедленно, и маленькое небольшое изменение лучше чем отложенное совершенствование
Принципы кайдзен (1/2) • • • Придерживайся концепции “ориентация на рынок” (Клиент прежде всего. Тот кто выполняет следующую технологическую операцию — твой потребитель. Если ты сторонник концепции “поскорее сбыть” то название нашей компании вскоре исчезнет даже из телефоной книги) Всегда будь внимателен к возникающим проблемам (Там где нет проблем — совершенствование невозможно) Управлять — значит начать с планирования и сравнить план с результатом. (Давайте вертеть колесо PDCA и менять свой подход к работе) Горы сокровищ высятся на каждом шагу (Хронические проблемы могут научить тебя большему чем те, которые возникают внезапно) Управляй процессом по результатам (Исправление и подгонка — проблемы, возникающие изза упущений руководства. Решение этих проблем уже не менеджмент, а манипуляции) Анализируй происходящее на предприятии и действуй на основе фактов (Делай выводы, опираясь на достоверные факты. Не полагайся на интуицию или внутренний голос)
Принципы кайдзен (2/2) • • Будь внимателен к отступлениям от стандарта (Важнее установить отклонения, чем повысить средние показатели) Разделяй объекты наблюдения на группы перед наблюдением (Классификация помогает лучшему пониманию) Совершенствование начинай с себя (Приучи себя определять вопросы, за которые отвечаешь ты лично, в отличии от тех, за которые отвечают другие и начинай с собственных задач) Устраняй основную причину и предотвращай рецидивы (Не путай причину проблемы с ее проявлениями) Встраивай качество в процесс как можно раньше (Качество должно встраиваться в процесс, проверка не создает качества) Никогда не забывай о стандартизации (Нам нужны методы, позволяющие закрепить достигнутый результат) Всегда помни о развертывании по горизонтали (Личный опыт должен становиться достоянием всей компании) Внедрение TQC касается всех (Приятная и осмысленная работа в цехе начинается с активного “кружка качества”, который способствует взаимному обучению и саморазвитию)
Часть методологии Кайдзен которая применима к кодированию • Непрерывные изменения — есть, непрерывные малые изменения во всех сферах организации • Открытое признание проблем — все проблемы открыто выносятся на обсуждение • Развитие по горизонтали. (Личный опыт должен становиться достоянием всей компании) • Развитие самодисциплины — умение контролировать себя и уважать как самого себя, так и других работников и организацию в целом • Устранение основной причины и предотвращение рецидивов • Ни один день не должен пройти без того, чтобы какоенибудь улучшение не было сделано где-то в компании.
Выводы • Ошибаться – нормально, главное – не повторять ошибок. • Лучше если знать список стандартных ошибок дру • Сегодня озвучили некоторые проблемы, но антипаттернов на самом деле большое количество • Антипаттерны имеют множество причин и если хотите добиться повышения эффективности работ команды придется заниматься не только антипаттернами кодирования.