Modifiability

ISAC Lighting Conference #3

Transcript

1. Modifiability Warsaw ~ Kyiv, Apr 2020 Oleg Kovalov Allegro https://olegk.dev
2. - Gopher for ~5 years - Open source contributor - Engineer at allegro.pl core team https://olegk.dev Кто я 2
3. Кто этот Modifiability 3
4. - As a user developer I want… Кто этот Modifiability 4
5. - As a user developer I want… - Менять код и делать это легко Кто этот Modifiability 5
6. - As a user developer I want… - Менять код и делать это легко - Мигрировать на другие компоненты Кто этот Modifiability 6
7. - As a user developer I want… - Менять код и делать это легко - Мигрировать на другие компоненты - Меньше действий - больше улучшений Кто этот Modifiability 7
8. Когда этот Modifiability 8
9. - Во время разработки - новые требования - адаптируемся Когда этот Modifiability 9
10. - Во время разработки - новые требования - адаптируемся - Во время эксплуатации - что-то поняли, когда уже заработало Когда этот Modifiability 10
11. - Во время разработки - новые требования - адаптируемся - Во время эксплуатации - что-то поняли, когда уже заработало - Во время эволюционирования - теперь нужно решить больше проблем Когда этот Modifiability 11
12. - Во время разработки - новые требования - адаптируемся - Во время эксплуатации - что-то поняли, когда уже заработало - Во время эволюционирования - теперь нужно решить больше проблем Если проект жив - нужно Когда этот Modifiability 12
13. Так есть же SOLID! 13
14. - Да, есть Так есть же SOLID! 14
15. - Да, есть - И использовать надо, очень надо Так есть же SOLID! 15
16. - Да, есть - И использовать надо, очень надо - Кстати, а ведь большинство использует - мне вот сложно вспомнить, кто не знал - еще сложнее, кто не использовал Так есть же SOLID! 16
17. - Да, есть - И использовать надо, очень надо - Кстати, а ведь большинство использует - мне вот сложно вспомнить, кто не знал - еще сложнее, кто не использовал - (многие не помнят пункты, факт) Так есть же SOLID! 17
18. - Да, есть - И использовать надо, очень надо - Кстати, а ведь большинство использует - мне вот сложно вспомнить, кто не знал - еще сложнее, кто не использовал - (многие не помнят пункты, факт) - Вопрос только в уровнях и детализации - а здесь вся идея Так есть же SOLID! 18
19. Уровни детализации 19 GopherCon Europe 2019: Egon Elbre - Psychology of Code Readability
20. Уровни детализации 20 GopherCon Europe 2019: Egon Elbre - Psychology of Code Readability Здесь чаще джуны
21. Уровни детализации 21 GopherCon Europe 2019: Egon Elbre - Psychology of Code Readability Здесь чаще джуны а здесь синьеры
22. Давайте примеры на Java и Go 22
23. - Почему эти языки? - я с ними связан, они интересные - на самом деле Java, Kotlin, Groovy, etc Давайте примеры на Java и Go 23
24. - Почему эти языки? - я с ними связан, они интересные - на самом деле Java, Kotlin, Groovy, etc - 1й постарше будет - а значит привычки окаменели - есть класс? - нужен интерфейс! Давайте примеры на Java и Go 24
25. - Почему эти языки? - я с ними связан, они интересные - на самом деле Java, Kotlin, Groovy, etc - 1й постарше будет - а значит привычки окаменели - есть класс? - нужен интерфейс! - 2й помоложе будет - а значит еще не все потеряно - ^^^ selling point Давайте примеры на Java и Go 25
26. - Почему эти языки? - я с ними связан, они интересные - на самом деле Java, Kotlin, Groovy, etc - 1й постарше будет - а значит привычки окаменели - есть класс? - нужен интерфейс! - 2й помоложе будет - а значит еще не все потеряно - ^^^ selling point Люблю оба, но каждый по своему Давайте примеры на Java и Go 26
27. public interface TokenGenerator { String generate(); } Абстрактный реальный пример 27
28. public interface TokenGenerator { String generate(); } class DefaultTokenGenerator implements TokenGenerator { public DefaultTokenGenerator(TokenHasher tokenHasher) { ... } public String generate() { this.th.hash(Rand.newString()); } } Абстрактный реальный пример 28
29. public interface TokenGenerator { String generate(); } class DefaultTokenGenerator implements TokenGenerator { public DefaultTokenGenerator(TokenHasher tokenHasher) { ... } public String generate() { this.th.hash(Rand.newString()); } } public interface TokenHasher { String hash(String s); } Абстрактный реальный пример 29
30. Так что плохого тут? 30
31. - TokenGenerator будет везде - реализация и потребитель должны явно требовать - это хорошо, ведь всё наглядно - это плохо, ведь таких интерфейсов много Так что плохого тут? 31
32. - TokenGenerator будет везде - реализация и потребитель должны явно требовать - это хорошо, ведь всё наглядно - это плохо, ведь таких интерфейсов много - нужен ли нам TokenHasher ? - на самом деле нет - DefaultTokenGenerator справился бы отлично Так что плохого тут? 32
33. - TokenGenerator будет везде - реализация и потребитель должны явно требовать - это хорошо, ведь всё наглядно - это плохо, ведь таких интерфейсов много - нужен ли нам TokenHasher ? - на самом деле нет - DefaultTokenGenerator справился бы отлично - Такого в Java-мире много - оно и работает, и буксует Так что плохого тут? 33
34. type TokenGenerator interface { Generate() string } А пример на Go? 34
35. type TokenGenerator interface { Generate() string } type SHAGenerator struct { ... } func (d *SHAGenerator) Generate() string { ... } // нам не нужно implements ведь в compile-time проверим А пример на Go? 35
36. Так чем Go лучше? 36
37. - Композиция, но не наследование - усложняет наслоение абстракций Так чем Go лучше? 37
38. - Композиция, но не наследование - усложняет наслоение абстракций - А еще duck typing - на самом деле structural typing Так чем Go лучше? 38
39. - Композиция, но не наследование - усложняет наслоение абстракций - А еще duck typing - на самом деле structural typing - compilation time, not run time - реализация удовлетворяет интерфейсу - значит будем использовать Так чем Go лучше? 39
40. Так чем Go лучше? - Композиция, но не наследование - усложняет наслоение абстракций - А еще duck typing - на самом деле structural typing - compilation time, not run time - реализация удовлетворяет интерфейсу - значит будем использовать - Интерфейс определяет потребитель - Be conservative in what you send, - be liberal in what you accept - Postel’s Law / Robustness principle 40
41. Грустная история 41
42. - 2015, делается важный сервис Грустная история 42
43. - 2015, делается важный сервис - Делаем по Java-канонам, с Spring™ - Везде появляются классы фреймворка Грустная история 43
44. - 2015, делается важный сервис - Делаем по Java-канонам, с Spring™ - Везде появляются классы фреймворка - Проходит 4 года и нужно принимать проект - В теории всё круто, все по SOLID - На практике ад и погибель Грустная история 44
45. - 2015, делается важный сервис - Делаем по Java-канонам, с Spring™ - Везде появляются классы фреймворка - Проходит 4 года и нужно принимать проект - В теории всё круто, все по SOLID - На практике ад и погибель - Много прогибов под абстракции Spring - Много вредного ушло в виде клиента Грустная история 45
46. Выводы 46
47. - Modifiability это важно Выводы 47
48. - Modifiability это важно - Абстракции нужны не просто так Выводы 48
49. - Modifiability это важно - Абстракции нужны не просто так - Не измеряется количеством интерфейсов Выводы 49
50. - Modifiability это важно - Абстракции нужны не просто так - Не измеряется количеством интерфейсов - Дело не в языках, а то как их использовать Выводы 50
51. - Modifiability это важно - Абстракции нужны не просто так - Не измеряется количеством интерфейсов - Дело не в языках, а то как их использовать - Абстракции нужно не заимствовать, а создавать Выводы 51
52. Thank you Questions? https://olegk.dev That’s all folks