Итак, я уже писал свою критику разрабов, которые любят делать проксирующие интеракторы и теперь хочу обсудить, пожаловаться на проблему, которая стоит очень рядом.
Я свою карьеру начинал как backend разработчик на java. Первой моей работой была небольшая Томская конторка, которая делает медиакомплексы для общественного транспорта. Для управления этой системой был целый бэк с довольно симпатичным UI.
Вся система разрабатывалась на фреймворке spring. И вот в таких системах в коде есть одна практика, призраки которой мы можем видеть сейчас в Android разработке. Там каждому классу с логикой создавался интерфейс, а внутри уже клался класс с реализацией логики: PizdosService и внутри PizdosServiceImpl.
И вот когда я был новичком, я даже не задавался вопросом, а нафига мы так делаем. К тому времени я уже начитался статей про Solid и т.д и понимал, что мы это делаем, чтобы если вдруг нужно поменять реализацию, могли это сделать быстро. Знаете сколько раз приходилось менять реализацию? 0 раз.
Даже в текущем проекте когда я на код ревью задаю вопрос про интерфейсы в интеракторах, мне отвечают привычное: "А вдруг там нужно будет реализацию подменить" – ядрена мать!
Речь не только про интерфейсы, а про то, что все разработчики пытаются предсказать будущее и заложиться заранее. Однако будем честны, выходит у всех паршиво. И не дай бог из 100 таких интерфейсов разработчику посчастливится в одном заменить реализацию, все он уже потерян. Теперь когда он сэкономил целые 15 минут работы, убежденность на собственном опыте не даст ему рационально посмотреть на эту вещь.
В эту тему мне очень нравится доклад Кирилла Мокевкина, ментальное программирование. В докладе он рассказывал, что они (Хекслет) долго сидели на одном сервере и масштабировались исключительно покупкой более мощного железа. Они понимали, что они стартап, и если будут делать это вначале, пытаясь предсказать будущее, они просто профакапятся и закроются через месяц. И когда они уже стали успешным бизнесом, только тогда, они начали разъезжаться по серверам и сделали это сразу грамотно. Потому как уже знали что именно нужно делать.
Еще один пример Авито. Дико успешный продукт, знаете сколько у них было инстансов БД на 2018 год, когда проекту уже был почти 10 лет? Один! Один сервер всего, ну и еще одна реплика естественно. Они тоже понимали, что если начнут шардирование раньше времени, то проебутся. Через 10 лет проекта они уже точно знали как именно им нужно растаскивать данные по разным БД.
Разумеется если вы уже крутой архитектор, долго сидите на проекте и прям точно уверены, что понадобиться в будущем, то ок. Однако в остальных случаях не нужно пытаться предсказать будущее и заложится заранее. Если вы можете не принимать архитектурное решение сейчас, не принимайте. Не уверены точно, что понадобится вторая реализация, не нужен вам интерфейс. Когда появится необходимость, добавите, IDE это умеют делать сами.
Если понадобится переехать на другую базу, то возьмете и переедите, появится вторая аналитика, засучите рукава и добавите. Когда у вас четко будет стоять задача, вам будет это сделать в 100 раз проще, чем предугадать туманное будущее.
Итак, я уже писал свою критику разрабов, которые любят делать проксирующие интеракторы и теперь хочу обсудить, пожаловаться на проблему, которая стоит очень рядом.
Я свою карьеру начинал как backend разработчик на java. Первой моей работой была небольшая Томская конторка, которая делает медиакомплексы для общественного транспорта. Для управления этой системой был целый бэк с довольно симпатичным UI.
Вся система разрабатывалась на фреймворке spring. И вот в таких системах в коде есть одна практика, призраки которой мы можем видеть сейчас в Android разработке. Там каждому классу с логикой создавался интерфейс, а внутри уже клался класс с реализацией логики: PizdosService и внутри PizdosServiceImpl.
И вот когда я был новичком, я даже не задавался вопросом, а нафига мы так делаем. К тому времени я уже начитался статей про Solid и т.д и понимал, что мы это делаем, чтобы если вдруг нужно поменять реализацию, могли это сделать быстро. Знаете сколько раз приходилось менять реализацию? 0 раз.
Даже в текущем проекте когда я на код ревью задаю вопрос про интерфейсы в интеракторах, мне отвечают привычное: "А вдруг там нужно будет реализацию подменить" – ядрена мать!
Речь не только про интерфейсы, а про то, что все разработчики пытаются предсказать будущее и заложиться заранее. Однако будем честны, выходит у всех паршиво. И не дай бог из 100 таких интерфейсов разработчику посчастливится в одном заменить реализацию, все он уже потерян. Теперь когда он сэкономил целые 15 минут работы, убежденность на собственном опыте не даст ему рационально посмотреть на эту вещь.
В эту тему мне очень нравится доклад Кирилла Мокевкина, ментальное программирование. В докладе он рассказывал, что они (Хекслет) долго сидели на одном сервере и масштабировались исключительно покупкой более мощного железа. Они понимали, что они стартап, и если будут делать это вначале, пытаясь предсказать будущее, они просто профакапятся и закроются через месяц. И когда они уже стали успешным бизнесом, только тогда, они начали разъезжаться по серверам и сделали это сразу грамотно. Потому как уже знали что именно нужно делать.
Еще один пример Авито. Дико успешный продукт, знаете сколько у них было инстансов БД на 2018 год, когда проекту уже был почти 10 лет? Один! Один сервер всего, ну и еще одна реплика естественно. Они тоже понимали, что если начнут шардирование раньше времени, то проебутся. Через 10 лет проекта они уже точно знали как именно им нужно растаскивать данные по разным БД.
Разумеется если вы уже крутой архитектор, долго сидите на проекте и прям точно уверены, что понадобиться в будущем, то ок. Однако в остальных случаях не нужно пытаться предсказать будущее и заложится заранее. Если вы можете не принимать архитектурное решение сейчас, не принимайте. Не уверены точно, что понадобится вторая реализация, не нужен вам интерфейс. Когда появится необходимость, добавите, IDE это умеют делать сами.
Если понадобится переехать на другую базу, то возьмете и переедите, появится вторая аналитика, засучите рукава и добавите. Когда у вас четко будет стоять задача, вам будет это сделать в 100 раз проще, чем предугадать туманное будущее.
Choose quality over quantity. Remember that one high-quality post is better than five short publications of questionable value. A Hong Kong protester with a petrol bomb. File photo: Dylan Hollingsworth/HKFP. 5Telegram Channel avatar size/dimensions Co-founder of NFT renting protocol Rentable World emiliano.eth shared the group Tuesday morning on Twitter, calling out the "degenerate" community, or crypto obsessives that engage in high-risk trading. The best encrypted messaging apps
from us
