Modifiability

ISAC Lighting Conference #3

Transcript

1. Modifiability
   Warsaw ~ Kyiv, Apr 2020
   Oleg Kovalov
   Allegro
   https://olegk.dev
   

   View Slide

2. - Gopher for ~5 years
   - Open source contributor
   - Engineer at allegro.pl core team
   https://olegk.dev
   Кто я
   2
   

   View Slide

3. Кто этот Modifiability
   3
   

   View Slide

4. - As a user developer I want…
   Кто этот Modifiability
   4
   

   View Slide

5. - As a user developer I want…
   - Менять код и делать это легко
   Кто этот Modifiability
   5
   

   View Slide

6. - As a user developer I want…
   - Менять код и делать это легко
   - Мигрировать на другие компоненты
   Кто этот Modifiability
   6
   

   View Slide

7. - As a user developer I want…
   - Менять код и делать это легко
   - Мигрировать на другие компоненты
   - Меньше действий - больше улучшений
   Кто этот Modifiability
   7
   

   View Slide

8. Когда этот Modifiability
   8
   

   View Slide

9. - Во время разработки
   - новые требования - адаптируемся
   Когда этот Modifiability
   9
   

   View Slide

10. - Во время разработки
    - новые требования - адаптируемся
    - Во время эксплуатации
    - что-то поняли, когда уже заработало
    Когда этот Modifiability
    10
    

    View Slide

11. - Во время разработки
    - новые требования - адаптируемся
    - Во время эксплуатации
    - что-то поняли, когда уже заработало
    - Во время эволюционирования
    - теперь нужно решить больше проблем
    Когда этот Modifiability
    11
    

    View Slide

12. - Во время разработки
    - новые требования - адаптируемся
    - Во время эксплуатации
    - что-то поняли, когда уже заработало
    - Во время эволюционирования
    - теперь нужно решить больше проблем
    Если проект жив - нужно
    Когда этот Modifiability
    12
    

    View Slide

13. Так есть же SOLID!
    13
    

    View Slide

14. - Да, есть
    Так есть же SOLID!
    14
    

    View Slide

15. - Да, есть
    - И использовать надо, очень надо
    Так есть же SOLID!
    15
    

    View Slide

16. - Да, есть
    - И использовать надо, очень надо
    - Кстати, а ведь большинство использует
    - мне вот сложно вспомнить, кто не знал
    - еще сложнее, кто не использовал
    Так есть же SOLID!
    16
    

    View Slide

17. - Да, есть
    - И использовать надо, очень надо
    - Кстати, а ведь большинство использует
    - мне вот сложно вспомнить, кто не знал
    - еще сложнее, кто не использовал
    - (многие не помнят пункты, факт)
    Так есть же SOLID!
    17
    

    View Slide

18. - Да, есть
    - И использовать надо, очень надо
    - Кстати, а ведь большинство использует
    - мне вот сложно вспомнить, кто не знал
    - еще сложнее, кто не использовал
    - (многие не помнят пункты, факт)
    - Вопрос только в уровнях и детализации
    - а здесь вся идея
    Так есть же SOLID!
    18
    

    View Slide

19. Уровни детализации
    19
    GopherCon Europe 2019: Egon Elbre - Psychology of Code Readability
    

    View Slide

20. Уровни детализации
    20
    GopherCon Europe 2019: Egon Elbre - Psychology of Code Readability
    Здесь чаще джуны
    

    View Slide

21. Уровни детализации
    21
    GopherCon Europe 2019: Egon Elbre - Psychology of Code Readability
    Здесь чаще джуны
    а здесь синьеры
    

    View Slide

22. Давайте примеры на Java и Go
    22
    

    View Slide

23. - Почему эти языки?
    - я с ними связан, они интересные
    - на самом деле Java, Kotlin, Groovy, etc
    Давайте примеры на Java и Go
    23
    

    View Slide

24. - Почему эти языки?
    - я с ними связан, они интересные
    - на самом деле Java, Kotlin, Groovy, etc
    - 1й постарше будет
    - а значит привычки окаменели
    - есть класс? - нужен интерфейс!
    Давайте примеры на Java и Go
    24
    

    View Slide

25. - Почему эти языки?
    - я с ними связан, они интересные
    - на самом деле Java, Kotlin, Groovy, etc
    - 1й постарше будет
    - а значит привычки окаменели
    - есть класс? - нужен интерфейс!
    - 2й помоложе будет
    - а значит еще не все потеряно
    - ^^^ selling point
    Давайте примеры на Java и Go
    25
    

    View Slide

26. - Почему эти языки?
    - я с ними связан, они интересные
    - на самом деле Java, Kotlin, Groovy, etc
    - 1й постарше будет
    - а значит привычки окаменели
    - есть класс? - нужен интерфейс!
    - 2й помоложе будет
    - а значит еще не все потеряно
    - ^^^ selling point
    Люблю оба, но каждый по своему
    Давайте примеры на Java и Go
    26
    

    View Slide

27. public interface TokenGenerator {
    String generate();
    }
    Абстрактный реальный пример
    27
    

    View Slide

28. public interface TokenGenerator {
    String generate();
    }
    class DefaultTokenGenerator implements TokenGenerator {
    public DefaultTokenGenerator(TokenHasher tokenHasher) { ... }
    public String generate() { this.th.hash(Rand.newString()); }
    }
    Абстрактный реальный пример
    28
    

    View Slide

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
    

    View Slide

30. Так что плохого тут?
    30
    

    View Slide

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

    View Slide

32. - TokenGenerator будет везде
    - реализация и потребитель должны явно требовать
    - это хорошо, ведь всё наглядно
    - это плохо, ведь таких интерфейсов много
    - нужен ли нам TokenHasher ?
    - на самом деле нет
    - DefaultTokenGenerator справился бы отлично
    Так что плохого тут?
    32
    

    View Slide

33. - TokenGenerator будет везде
    - реализация и потребитель должны явно требовать
    - это хорошо, ведь всё наглядно
    - это плохо, ведь таких интерфейсов много
    - нужен ли нам TokenHasher ?
    - на самом деле нет
    - DefaultTokenGenerator справился бы отлично
    - Такого в Java-мире много
    - оно и работает, и буксует
    Так что плохого тут?
    33
    

    View Slide

34. type TokenGenerator interface {
    Generate() string
    }
    А пример на Go?
    34
    

    View Slide

35. type TokenGenerator interface {
    Generate() string
    }
    type SHAGenerator struct { ... }
    func (d *SHAGenerator) Generate() string { ... }
    // нам не нужно implements ведь в compile-time проверим
    А пример на Go?
    35
    

    View Slide

36. Так чем Go лучше?
    36
    

    View Slide

37. - Композиция, но не наследование
    - усложняет наслоение абстракций
    Так чем Go лучше?
    37
    

    View Slide

38. - Композиция, но не наследование
    - усложняет наслоение абстракций
    - А еще duck typing
    - на самом деле structural typing
    Так чем Go лучше?
    38
    

    View Slide

39. - Композиция, но не наследование
    - усложняет наслоение абстракций
    - А еще duck typing
    - на самом деле structural typing
    - compilation time, not run time
    - реализация удовлетворяет интерфейсу
    - значит будем использовать
    Так чем Go лучше?
    39
    

    View Slide

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
    

    View Slide

41. Грустная история
    41
    

    View Slide

42. - 2015, делается важный сервис
    Грустная история
    42
    

    View Slide

43. - 2015, делается важный сервис
    - Делаем по Java-канонам, с Spring™
    - Везде появляются классы фреймворка
    Грустная история
    43
    

    View Slide

44. - 2015, делается важный сервис
    - Делаем по Java-канонам, с Spring™
    - Везде появляются классы фреймворка
    - Проходит 4 года и нужно принимать проект
    - В теории всё круто, все по SOLID
    - На практике ад и погибель
    Грустная история
    44
    

    View Slide

45. - 2015, делается важный сервис
    - Делаем по Java-канонам, с Spring™
    - Везде появляются классы фреймворка
    - Проходит 4 года и нужно принимать проект
    - В теории всё круто, все по SOLID
    - На практике ад и погибель
    - Много прогибов под абстракции Spring
    - Много вредного ушло в виде клиента
    Грустная история
    45
    

    View Slide

46. Выводы
    46
    

    View Slide

47. - Modifiability это важно
    Выводы
    47
    

    View Slide

48. - Modifiability это важно
    - Абстракции нужны не просто так
    Выводы
    48
    

    View Slide

49. - Modifiability это важно
    - Абстракции нужны не просто так
    - Не измеряется количеством интерфейсов
    Выводы
    49
    

    View Slide

50. - Modifiability это важно
    - Абстракции нужны не просто так
    - Не измеряется количеством интерфейсов
    - Дело не в языках, а то как их использовать
    Выводы
    50
    

    View Slide

51. - Modifiability это важно
    - Абстракции нужны не просто так
    - Не измеряется количеством интерфейсов
    - Дело не в языках, а то как их использовать
    - Абстракции нужно не заимствовать, а создавать
    Выводы
    51
    

    View Slide

52. Thank you
    Questions?
    https://olegk.dev
    That’s all folks
    

    View Slide