1 of 40

Refactoring

from developers to developers

Рефакторинг. Процесс с которым периодически сталкиваются большинство разработчиков.

Есть ли в зале те кто никогда не сталкивался с этим процессом?

А кто проводил рефакторинг длительное время: может быть 2 недели, месяц?

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

В основу этого доклада легли работы Мартина Фаулера, Кента Бека, Роберта Мартина.

2 of 40

3+ years Android dev

Темирлан Кунтубаев

t.me/tkuntubaev

3 of 40

Начнем с истории. В античное время были специально обученные люди которые могли читать и писать. Эта была привилегированная группа людей, т.к. этот навык был доступен не всем. В обязанности этих людей входило зачитывание законов населению, создание копий текстов, запись устной речи, улучшение читабельности, а также проверка работ другого писца на наличие ошибок и соответствию определенным требованиям. С тех пор прошло очень много времени, а часть процессов, такие как ревью и рефакторинг была перенята разработчиками.

4 of 40

Количество разработчиков в мире

https://medium.com/@aevy/the-truth-about-the-lack-of-developers-886ddce70b

+15%

5 of 40

3-month moving average for salaries quoted in permanent IT jobs citing Software Developer

https://www.itjobswatch.co.uk/jobs/uk/software%20developer.do

Бизнес чаще всего не заинтересован в понимании технических деталей продукта. Основное на что он фокусирует внимание это качество и скорость поставки продукта на рынок. При этом бизнес готов привлекать все больше и больше новых людей. Платя при этом бОльшую заработную плату. На графике показана средняя заработная плата разработчика в течение более чем 10 лет в Лондоне.

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

6 of 40

Что?

7 of 40

До

После

8 of 40

Зачем?

9 of 40

10 of 40

Когда проверяешь коммит, чтобы увидеть, кто написал shitty код

Программист пишет код, указывающий компьютеру, что необходимо сделать, и тот в ответ делает в точности то, что ему сказано. В таком режиме суть программирования состоит в том, чтобы точно сказать, что требуется от компьютера. Но программа адресована не только компьютеру. Пройдет некоторое время, и кому-нибудь понадобится прочесть ваш код, чтобы внести какие-то изменения. Об этом пользователе кода часто забывают, но он-то и есть главный. Станет ли кто-нибудь волноваться из-за того, что компьютеру для компиляции потребуется несколько дополнительных циклов? Зато важно, что программист может потратить неделю на модификацию кода, которая заняла бы у него лишь час, будь он в состоянии разобраться в коде.

11 of 40

Quality -> Speed

12 of 40

13 of 40

Условное время выполнения задачи

14 of 40

15 of 40

Почему?

16 of 40

17 of 40

18 of 40

19 of 40

Симптомы

20 of 40

21 of 40

22 of 40

Цикломати́ческая сло́жность програ́ммы — мера определяющая сложность компьютерной программы. Мера была разработана Томасом Дж. Маккейбом в 1976 году.

Эта метрика подсчитывает доступные пути выполнения кода во фрагменте программного обеспечения, чтобы определить его сложность. Каждый путь выполнения включает одну условную конструкцию из приведенного ниже списка, так что это их довольно легко обнаружить в существующем исходном коде

Маккейб применял вычисление цикломатической сложности при тестировании. Предложенный им метод заключался в тестировании каждого линейно независимого маршрута через программу, в этом случае число необходимых тестов равно цикломатической сложности программы.

Цикломатическая сложность может быть также вычислена для отдельных функций, модулей, методов или классов в пределах программы.

При вычислении цикломатической сложности используется граф потока управления программы. Узлы графа соответствуют неделимым группам команд программы, они соединены ориентированными рёбрами,

23 of 40

Как?

24 of 40

25 of 40

26 of 40

27 of 40

Риски

28 of 40

Хорошая команда не “продаёт” рефакторинг

29 of 40

https://twitter.com/keithoconor/status/650030257345556481

30 of 40

“Работающий продукт важнее исчерпывающей документации”

Когда не рефакторить?

31 of 40

32 of 40

1

2

3

4

33 of 40

До