2015-04-12 07 Евгений Тюменцев. Зачем программисту нужно...

Зачем программисту надо знать математику?

HWdTech, LLC

Тюменцев Евгений14 лет преподаю ИМИТ, ФКН ОмГУ ИТ-компании Школа программиста10 лет разрабатываю ПО разработчик, архитектор PM, в подчинении до 70 чел.

О себе

О стажировках

2007

О стажировках

60 : 0

О стажировках

Что могут студенты?

Что было 4,5 с – время отклика страницы

70 тыс. ошибок на 1 млн. страниц

30 с - время поиска по тексту объявления

БД более 200 таблиц

Что могут студенты?

Что стало800 мс – время отклика страницы

< 1 ош. на 10 тыс. страниц

Однушка в нефтахМатрешка до 700 т.р.

Подробнее о проекте

http://www.slideshare.net/etyumentcev/7-42045466

SOLID

5 архитектурных принципов

1988 г. Б. Мейер впервые описал

1995-96 г. Р. Мартин популяризировал, ввел термин SOLID

The Open-Closed Principle

Программные объекты должны быть открыты для расширения, но в тоже время закрыты для

модификации.

Принцип подстановки Лисков

Функции, которые используют ссылки на объекты базовых

классов, должны использовать объекты производных классов,

ничего не зная о них.

Нарушают SOLID принципы

enumswitchif – else – ifоператоры приведения типаnew

Что-о-о? switch, new? Ты кто такой?

ВыводимостьПусть L – множество формул, B – формула.Тогда L B⊦ , если ∃ B1, B2, …, Bn , что1.Bn – это B,2.Bi – это либо формула из L, ,либо аксиома , либо общезначимая формула либо формула полученная при помощи правила вывода

Логика Хоара

Об авторе1969 г. An Axiomatic Basis for Computer Programming1971 г. Procedures and Parameters: An Axiomatic Approach

1980 г. премия Тьюринга1990 г. Медаль “Пионер компьютерной техники” 2000 г. рыцарский титул за заслуги в области образования и компьютерной техники, премия Киото

Чарльз Хоар

Тройка Хоара

{pred} statement {post}

Пример: {x == 42} y=x+1; {y == 43 ^ x == 42}

Аксиома пустого оператора

{P} skip {P}

Аксиома присваивания

Пример: {(y+1)*3+w*(y+1+3) ==z} x=y+1;

{ x*3+ w*(x+3)==z}

{P[E/x]} x := E {P}

Аксиомы оператора цикла

{P ^ B} S {P} {P} while B do S done {B’ ^ P} ╞

Аксиомы условного оператора

{B ^ P} S {Q}, {B’ ^P} T {Q} {P} if B then S else T endif {Q}╞

{B ^ P} S {Q} {P} if B then S endif {Q}╞

Аксиомы вывода

P1 → P, {P} S {Q}, Q → Q1 {P1} S {Q1}╞

P1 → P, {P} S {Q} {P1} S {Q}╞{P} S {Q}, Q → Q1 {P} S {Q1}╞

Аксиома вывода согласуется с условным оператором

Пусть L = {{P} f {Q}}, B – предикат.

P^B→P (A3 исчисления высказываний){P^B}f{Q} (аксиома вывода){P}if (B) then f endif {Q} (аксиома условного оператора)

Аксиома композиции

{P} S {Q}, {Q} T {R} {P} S;T {R} ╞

• Предусловия• Постусловия• Инварианты

Контрактное программирование

Модульные тесты

ArrangeAct

Assert

Рефакторинг

Повторное использование кода — методология проектирования компьютерных и других систем, заключающаяся в том, что система (компьютерная программа, программный модуль) частично либо полностью должна составляться из частей, написанных ранее компонентов и/или частей другой системы, и эти компоненты должны применяться более одного раза (если не в рамках одного проекта, то хотя бы разных).

Повторное использование

https://ru.wikipedia.org/wiki/Повторное_использование_кода

А можно ли по-другому?

Выводимость прямо предписывает строить новые тройки из предыдущих!

Когда происходит повторное использование?

Если нужно внести изменение в существующее приложение, то мы пытаемся повторно использовать свой же собственный код, чтобы получить тоже приложение, но с

новой функциональностью.

Чем грозят правки кода?

B1, B2, …, A1

B3, A1, …, A2

B5, A2, …, A3

A2, B6, …, A4

A2, A4, …, A5

Чем грозят правки кода?

B1, B2, …, A1

B3, A1, …, A2

B5, A2, …, A3

A2, B6, …, A4

A2, A4, …, A5

Матрицыclass matrix { int size; double *body; public: matrix(int s): size(s) { body = new double[s*s]; } void transform() { … } double det() const { … }};

Матрицы: добавляем matrix()class matrix { int size; double *body; public: matrix(int s): size(s) { body = new double[s*s]; } void transform() { … } double det() const { … }};

class matrix {public: matrix(): size(0), body(0) { }};

Придется изменять методыclass matrix { int size; double *body; public: matrix(): size(0), body(0) { } matrix(int s): size(s) { body = new double[s*s]; }

void transform() { if(!body) throw exception(); … } double det() const { if(!body) throw exception(); … }};

Что случилосьИнвариант класса matrix: size > 0

Конструктор matrix() нарушил инвариант: size = 0

Предусловия методов изменились с size > 0 на size ≥ 0, но

{size ≥ 0} det {Q} не выводится из {size > 0} det {Q} , Следовательно надо изменять сами методы

Конструкторы по умолчаниюКонструктор должен устанавливать

инвариант классаКонструкторы по умолчанию часто этого не

делают

Стоит несколько раз подумать, прежде чем использовать конструктор по умолчанию

Как избавиться от switch?

Нерассказанные факты об императивном программировании

oopguide.ru

Разработка серверов и серверных приложений

actorsmodel.ru

Мы пишем книги

с/к Разработка серверов и серверных приложений (все желающие)

Студентам 2 курса ИМИТ: выполнение курсовых работ

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

Приглашаю

Наш слоган

Программировать – хорошо, а хорошо программировать – еще лучше. Мы знаем как!

Тюменцев ЕвгенийДиректор HWdTech, LLC

Звоните: +7 913 150 22 04Пишите: etyumentcev@hwdtech.ru

slideshare.com/etyumentcevhwdtech.ru

СпасибоСпасибо