Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Modifiability

 Modifiability

ISAC Lighting Conference #3

Oleg Kovalov

April 23, 2020
Tweet

More Decks by Oleg Kovalov

Other Decks in Programming

Transcript

  1. - Gopher for ~5 years - Open source contributor -

    Engineer at allegro.pl core team https://olegk.dev Кто я 2
  2. - As a user developer I want… - Менять код

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

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

    и делать это легко - Мигрировать на другие компоненты - Меньше действий - больше улучшений Кто этот Modifiability 7
  5. - Во время разработки - новые требования - адаптируемся -

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

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

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

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

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

    Кстати, а ведь большинство использует - мне вот сложно вспомнить, кто не знал - еще сложнее, кто не использовал - (многие не помнят пункты, факт) - Вопрос только в уровнях и детализации - а здесь вся идея Так есть же SOLID! 18
  11. Уровни детализации 21 GopherCon Europe 2019: Egon Elbre - Psychology

    of Code Readability Здесь чаще джуны а здесь синьеры
  12. - Почему эти языки? - я с ними связан, они

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

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

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

    интересные - на самом деле Java, Kotlin, Groovy, etc - 1й постарше будет - а значит привычки окаменели - есть класс? - нужен интерфейс! - 2й помоложе будет - а значит еще не все потеряно - ^^^ selling point Люблю оба, но каждый по своему Давайте примеры на Java и Go 26
  16. public interface TokenGenerator { String generate(); } class DefaultTokenGenerator implements

    TokenGenerator { public DefaultTokenGenerator(TokenHasher tokenHasher) { ... } public String generate() { this.th.hash(Rand.newString()); } } Абстрактный реальный пример 28
  17. 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
  18. - TokenGenerator будет везде - реализация и потребитель должны явно

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

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

    требовать - это хорошо, ведь всё наглядно - это плохо, ведь таких интерфейсов много - нужен ли нам TokenHasher ? - на самом деле нет - DefaultTokenGenerator справился бы отлично - Такого в Java-мире много - оно и работает, и буксует Так что плохого тут? 33
  21. type TokenGenerator interface { Generate() string } type SHAGenerator struct

    { ... } func (d *SHAGenerator) Generate() string { ... } // нам не нужно implements ведь в compile-time проверим А пример на Go? 35
  22. - Композиция, но не наследование - усложняет наслоение абстракций -

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

    А еще duck typing - на самом деле structural typing - compilation time, not run time - реализация удовлетворяет интерфейсу - значит будем использовать Так чем Go лучше? 39
  24. Так чем 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
  25. - 2015, делается важный сервис - Делаем по Java-канонам, с

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

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

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

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

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

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