Качественный код

Разработка бизнес приложений Лекция 8

Зачем нужен качественный код

• Обеспечение работы нескольких программистов– Читабельность, отладка– Совместное владение кодом

(взаимозаменяемость)• Стоимость поддержки– Меньше багов– Замена детальной документации

Инженерные практики

• Стандарты кодирования– Стилистика кода и другие соглашения

• Рефакторинг• Тестирование– Автоматизированное и нет– Нагрузочное и оптимизация производительности

• Совместная разработка– Парное программирование– Code review

• Continuous integration / Source Control

СТАНДАРТЫ КОДИРОВАНИЯ

Общие

• Организация файлов и классов– Один класс – один фаил– Нормальная структура каталогов / пространств

имен (не больше 10 файлов в подкаталоге)• Группировка членов класса– Константы / статические поля– Поля– Конструкторы– Свойства– Методы (публичные, приватные, интерфейсы)

Форматирование• Пробелы, блоки, индентация• Например:

if(showResult==true) { for(int i=0;i<10;i++) { // }} ----------------------------------------------------------------------------------------------------------------------if (showResult == true){ for (int i = 0; i < 10; i++) { // }}

Именование

• PascalCasing / camelCasing (поля, лок. переменные)– HungarianNotation (i_Index) - зло

• ВЕРХНИЙ РЕГИСТР и _• Префиксы, суффиксы, аббревиатуры,

спецклассы (Exception)• Использование русского языка (unicode)

Самодокументируемость!

• GetSomething – метод который вычисляет некое значение и возвращает его:

• GetRowCount – возвращает кол-во строчек• DoSomething, MakeSomething – метод

который просто что-то делает (часто Do можно и нужно опускать):

• DoDelete – удаляет• Delete – тоже удаляет

Самодокументируемость!!

• Delete(User user) – очевидно, удаляет пользователя

• Delete(int userId) – тоже, почти очевидно, удаляет пользователя

• Delete(int i) – НЕ ПОНЯТНО, ЧТО ДЕЛАЕТ. ТАК НЕ НАДО ПИСАТЬ!

Самодокументируемость!!!

• Можно написать так:

• DeleteUser(int id) – вполне понятно что делает.

• Конкретный стиль выбирайте сами, надо помнить, что есть еще название класса. Потому как метод Delete(int id) вполне понятен если он находится в классе User.

Самодокументируемость!!!!

• Старайтесь писать код так, что бы его можно было читать как предложение.

• При прочтении кода вслух, должно создаваться впечатление что человек читает написанный алгоритм.

Сложность кода

• Избегайте слишком больших файлов. Если в файле более 500 строк кода, подумайте о разделении класса на несколько классов, вынесенные в отдельные файлы.

• Избегайте слишком длинных методов – это приводит к дублированию кода.

• Не больше 30 строчек кода в каждом методе• Максимальная вложенная глубина

(if/case/циклы вложенные) – 5.

Закон Деметры

• Метод f класса C должен ограничиваться вызовом методов следующих объектов:– C– объекты, созданные f– объекты – аргументы f– объекты – являющиеся состоянием C

• Позволяет достичь низкой связности кода

Сложность кода

• Код должен быть такой, что бы Вас могли разбудить среди ночи, дать листок с Вашим (а в идеале – чужим) исходником и вы бы четко могли объяснить, что делает каждая строка. Вне зависимости от того, неделю или год назад был этот код написан.

• Поддерживайте качество ООП абстракций (см. ранее)

Обработка ошибок

• Используйте exceptions!• Fail fast: не глотайте то, что не можете

обработать– Имейте общее место обработки фатальных ошибок

– дружественный вывод пользователю и лог• Четко определите контракт и падайте если он

нарушен– Принимайте на вход как можно больше вариантов,

а на выход выдавайте как можно меньше

Понятность имениХорошо: void SavePhoneNumber(string phoneNumber) { // Save the phone number. } Плохо: /// <summary>

/// This method will save the phone number. /// </summary> /// <param name="phoneNumber">Phone number</param>

void SaveData(string phoneNumber) { // Save the phone number. }

Атомарность методовПлохо:void SaveAddressAndSendMail ( string address, string email ) {// Save the address….// Send an email…} Хорошо:void SaveAddress(string address) {} void SendEmail(string address, string email) {}

Вариант

void SaveAddressAndSendMail ( string address, string email ){

SaveAddress(address); SendEmail(address, email);

}

Переменные

• Объявляйте и инициализируйте переменные как можно ближе к месту их использования.

• Делайте время жизни переменной как можно короче.

• Не используйте одну и ту же переменную в разных целях.

Магические константы

Плохо: string veryImportant = "VIP"; int start = 385170

Хорошо:public static readonly string VipString = "VIP";public static readonly string StartIndex = 385170; string veryImportant = VipString ;int start = StartIndex ;

Любые другие договоренности

• К примеру, длинна строк кода (в зависимости от мониторов)

• Использование this• Специфические конструкции языка• Использование автоматизированных утилит

проверки во время билда (CI)– Stylecop, FX Cop, Simian, NDepend и другие

Законченные switchvoid SendMail (string message, string mailType){ switch ( mailType ) { case "Html": // Do something, break; case "PlainText": // Do something break; default: // Do something break; }}------------------------------------------------------------------------------------------------------------ enum MailType { Html, PlainText, Attachment }

void SendMail (string message, MailType mailType) { switch ( mailType ) { case MailType.Html: // Do something break; case MailType.PlainText: // Do something break; default: // Do something break; } }

Сложные логические условияПлохо:if ((document.AtEndOfStream) && (!inputError)) && ((MIN_LINES <= lineCount) && (lineCount <= MAX_LINES)) && (!ErrorProcessing()))// Do something Хорошо:var allDataRead = document.AtEndOfStream && !inputError;

var legalLineCount = MIN_LINES <= lineCount && lineCount <= MAX_LINES;

if (allDataRead && legalLineCount && !ErrorProcessing())// Do something

РЕФАКТОРИНГИ

Двойное отрицание

Вложенные условия

Объединение условий

Поясняющая переменная

Обращение проверки

Разбить сложную проверку

Вынесение повторяющего фрагмента if

Внешний метод

Явная проверка

Убираем переменную

Убираем метод

Вводим константу

Замена ловли исключения проверкой

Замена кода возврата исключением

Замена присваивания инициализацией

Замена магического массива объектом

Замена параметра явным методом

Уберите присваивание параметрам

Передайте весь объект

Разбейте временную переменную

Разбейте цикл

Замените temp методом

Замените static пер-ю параметром

Замена параметра методом

Замена тела метода (в итоге)

Оптимизация производительности

• Только после измерения– Невозможно узнать что тормозит

• Никогда не нужно оптимизировать заранее– Невозможно угадать что тормозит– Хотя бывают редкие очевидные (с опытом)

случаи

Ориентировочные времена• Вызов виртуального метода

– Миллион раз: 4 мс • Создание объекта

– Миллион штук: 9 мс• Случайное заполнение и сортировка List<int> на

миллион элементов– 20 + 80 мс

• Запрос в БД– ~3-30+ мс

• Запрос HTTP– ~~ 30 – 500+ мс

Сложность алгоритмов и структуры данных

• O(n) – это было на матанализе– Кол-во элементарных операций

• O(n2) – начинаем волноваться– Но нужно понимать при каком n - в зависимости от

«элементарности» операции• Нормальная сортировка (quicksort) – O(n*logn)• HashTable: выбор по ключу - O(1), с хорошими хэшами• Есть другие варианты по всяким нюансам – память, те

или иные крайние случаи. Читаем по необходимости.

ОРГАНИЗАЦИОННЫЕ ПРАКТИКИ

Автоматизированное тестирование

• Unit тесты– На конкретные классы

• Integration тесты– На несколько систем вместе, иногда с БД

• Acceptance тесты– Понятные заказчику, в стиле спецификаций,

обычно на полноценно развернутой системе

• UI тесты• Нагрузочные тесты

Скорость выполнения

Ручной QA

Подходы к написанию тестов

• Типы тестов:– Традиционные (black box): вход – действие –

выход.– BDD (white box): вход, конкретная

последовательность действий, выход• Для разделения зависимостей используются

test proxy – fake объекты:– Mock (отслеживают порядок, кол-во вызовов и

прочее). Нужно для BDD.– Stub (все остальное)

Совместная разработка

• Pair programming (см. XP)– Один кодит– Другой выдумывает и сморит за ошибками– Потом меняются (обычно, по 2 часа)– ~15-25% дороже, на 45% быстрее и на 60%

меньше ошибок• CodeReview (постоянный)– И более формальные инспекции кода

Continuous integration

• Что-то должно постоянно билдить код и выполнять все тесты и проверки (каждый checkin)– CI Server (CruiseControl, TeamCity)

• Идеал – релиз в любой момент, причем автоматический

Сорс контрол

• Он нужен (GIT, Mercurial, SVN)• Бранчи – зло. Постарайтесь обойтись одним (trunk) и

все изменения вносить в него• Однако, появляются проблемы (которые, чаще всего,

следствие более глобальных, но)– База данных– Большие рефакторинги– Разные команды– Ручной QA– Официальные релизы– …

И получается

http://www.infoq.com/articles/agile-version-control#q5

С т.ч. релизов

http://www.infoq.com/articles/agile-version-control#q5

Ресурсы

• Совершенный код• Чистый код. Создание, анализ и

рефакторинг• Непрерывное развертывание ПО. Авто

матизация процессов сборки, тестирования и внедрения новых версий программ

• eXtreme Programming• TDD

Темы для докладов

• AOP• Kanban / Lean (Карпов)• SCRUM: Team / ScrumMaster – подробнее про процесс (DS,

Retro, SprintPlan, Demo…) (Большаков)

• NoSql БД• Реализация ООП в Javascript (прототипы)

Объявления

• Лекции 15го декабря не будет, осталось 3 лекции для докладов!

• Кто ничего не делал – на экзамене 5 не получит никак.

• Отчет по лабам

Лабы

• Обработка открытых данных– http://minenergo.gov.ru/activity/statistic/,http://www.fms.gov.ru/about/ofstat/,

http://www.federalspace.ru/main.php?id=10, http://ivan.begtin.name/2011/10/02/gosuslugijson/

• Индивидуальное задание (для тех, у кого уже есть что показать)

• Нужно:– Или наличие БД– Или наличие веб интерфейса– Отчет по лабам

• Стажировка (Тестер / Разработчик)– Нужно знание: C#, MS MVC, MS SQL Server

Использованные материалы

• Никита Филлипов (www.scrumtrek.ru), Сергей Дмитриев (www.agilecoach.ru)– Курс SCPO Msk (31.08.11)

• Бочков Илья (Архитектура корпоративных приложений, МИФИ)

• MIT: electrical-engineering-and-computer-science– http://ocw.mit.edu/courses/#

electrical-engineering-and-computer-science• http://www.refactoring.com (Фаулер)