Оверинжениринг это плохо. Но и недоинжениринг это тоже плохо. Когда надо двигаться вперёд а у тебя в коде макароны и нет тестов, то скорость катастрофически падает.
А чтобы понять, где золотая середина нужно общаться с бизнесом. Не ждите от него точных прогнозов, бизнес тоже ошибается, но явно более осведомлён чем программисты.
Есть ли в проекте ревью и какого размера обычно изменения? У меня линтеры настроенны в прекоммит хуках, и к тому моменту, когда они запускаются, я ещё не успел много накодить.
У меня все работы спокойные, есть время подумать и сделать нормально.
В личных проектах вообще линтеры закручены по максимуму, порой проходится с ними побороться. Это даёт очень неплохой опыт, как можно бороться со сложностью.
Это система которая давно в проде, и атрибутов сильно больше чем 42. Кстати самому бизнесу очень зашло, так как когда надо добавить подтип объекта со своими атрибутами это можно сделать без изменения базы. В комплекте с тем, что можно было написать свой плагин и загрузить его, новые фичи для бизнеса можно сделать реально за часы и даже не нужно перезагружать сервер.
Важно не запутаться в этих ифах и не накосячить. Полиморфизм через интерфейсы и посетитель помогают в этом. Тесты тоже. Из статьи мне показалось, что автор отвергает все эти способы борьбы со сложностью.
В которое есть проверка на уровне компилятора, что все кейсы по свитчу на энум обрабатываются. То есть добавив новый кейс вы не забудете поправить все свитчи. Вот такой свитч я люблю. Остальные не защищают от ошибок.
Станьте другим. Когда вы выбираете использовать ли полиморфизм, писать ли тесты на основе текущего контекста, а не потому что кто-то в интернете сказал, что есть только один путь.
Код должен подстраиваться под тесты в плане архитектуры. А вот бизнес логика нет. То есть добавить новый публичный метод только для теста плохо, а разделение на компоненты или инъекцию зависимостей норм. Если писать код без расчёта на тесты, то тестировать его будет очень сложно и дорого.
Например есть функция которая делает запрос по сети, парсит JSON и делает что-то с результатом. Тестировать такое сложно. Если обработку результата вынести в отдельную чистую функцию, то она тривиально тестируется, а на тестирования веб клиента можно вообще забить.
Если юнит тесты сложно писать, то скорее всего они не юнит.
Чем больше связанности между компонентами, тем больше тестов отваливается. Решение на что и как писать тесты, должно приниматься на уровне архитектора системы.
Мы об одном и том-же. В коде считаются ветвления и на основе этого делаются выводы о потенциальных ошибках. Конечно некоторые случаи выбиваются из этого правила, но в целом корреляция между сложность и ошибками работает.
Не до конца разделяю вашу уверенность в том, что вы пишете понятный код. Поймите меня правильно, если программист пишет код который не понятен ему самому, это клиника. Слишком часто я видел код про который автор говорил, что там всё просто.
Нужно было поддерживать неограниченное количество атрибутов, не известное заранее, а так же быть консистентными с другими таблицами, например пользователи.
Джойны в транзакциях это всё про не про nosql. Другого решения этой проблемы пока не придумали. Цена поддержки этого очень высока, с этим очень неудобно работать, и приходится следить за многим прямо в коде. Миграции базы это вообще ужас.
Но свою задачу решает. Сотни миллионов атрибутов MySQL ворочал достаточно шустро.
Если смотреть с определённого ракурса, у Камаза будет видно только 3 колеса :)
Возможно проблема не в шаблонах, а в чём то другом. А случай яркий и запоминающийся.
Появились ли после этого тесты?
Неиспользуемых? Так удалите и дело с концом.
По моему опыту выпиливать не так уж и сложно.
У вас кстати ревью на проекте есть? Или тоже потеря времени?
Так про полиморфизм был разговор в рамках другой задачи.
К опечаткам обычно не предираюсь, сам горазд, но вы там про имена целый абзац наказали, так что минус вам за Findvoice
Про приватные переменные и геттеры сеттеры очень жирно троллите.
Например? На ифы это распространяется?
Один из врагов читаемости кода - это производительность. И это проект где производительность действительно важна.
Оверинжениринг это плохо. Но и недоинжениринг это тоже плохо. Когда надо двигаться вперёд а у тебя в коде макароны и нет тестов, то скорость катастрофически падает.
А чтобы понять, где золотая середина нужно общаться с бизнесом. Не ждите от него точных прогнозов, бизнес тоже ошибается, но явно более осведомлён чем программисты.
А куда 40000 ifов денутся?
В вашем решении есть очень большой косяк, вы решаете новую задачу, которую только-что придумали.
Есть ли в проекте ревью и какого размера обычно изменения? У меня линтеры настроенны в прекоммит хуках, и к тому моменту, когда они запускаются, я ещё не успел много накодить.
У меня все работы спокойные, есть время подумать и сделать нормально.
В личных проектах вообще линтеры закручены по максимуму, порой проходится с ними побороться. Это даёт очень неплохой опыт, как можно бороться со сложностью.
Это система которая давно в проде, и атрибутов сильно больше чем 42. Кстати самому бизнесу очень зашло, так как когда надо добавить подтип объекта со своими атрибутами это можно сделать без изменения базы. В комплекте с тем, что можно было написать свой плагин и загрузить его, новые фичи для бизнеса можно сделать реально за часы и даже не нужно перезагружать сервер.
Важно не запутаться в этих ифах и не накосячить. Полиморфизм через интерфейсы и посетитель помогают в этом. Тесты тоже. Из статьи мне показалось, что автор отвергает все эти способы борьбы со сложностью.
В которое есть проверка на уровне компилятора, что все кейсы по свитчу на энум обрабатываются. То есть добавив новый кейс вы не забудете поправить все свитчи. Вот такой свитч я люблю. Остальные не защищают от ошибок.
Согласен, сначала делать просто, потом рефакторить. Главное не пропустить момент.
Если ещё заложить риски, что клиент чудак, а исполнители криворуки, то такое не порадует клиентов.
Станьте другим. Когда вы выбираете использовать ли полиморфизм, писать ли тесты на основе текущего контекста, а не потому что кто-то в интернете сказал, что есть только один путь.
Код должен подстраиваться под тесты в плане архитектуры. А вот бизнес логика нет. То есть добавить новый публичный метод только для теста плохо, а разделение на компоненты или инъекцию зависимостей норм. Если писать код без расчёта на тесты, то тестировать его будет очень сложно и дорого.
Например есть функция которая делает запрос по сети, парсит JSON и делает что-то с результатом. Тестировать такое сложно. Если обработку результата вынести в отдельную чистую функцию, то она тривиально тестируется, а на тестирования веб клиента можно вообще забить.
По статья я не понял, что вы тоже это чевствуете.
Если юнит тесты сложно писать, то скорее всего они не юнит.
Чем больше связанности между компонентами, тем больше тестов отваливается. Решение на что и как писать тесты, должно приниматься на уровне архитектора системы.
Мы об одном и том-же. В коде считаются ветвления и на основе этого делаются выводы о потенциальных ошибках. Конечно некоторые случаи выбиваются из этого правила, но в целом корреляция между сложность и ошибками работает.
Не до конца разделяю вашу уверенность в том, что вы пишете понятный код. Поймите меня правильно, если программист пишет код который не понятен ему самому, это клиника. Слишком часто я видел код про который автор говорил, что там всё просто.
Нужно было поддерживать неограниченное количество атрибутов, не известное заранее, а так же быть консистентными с другими таблицами, например пользователи.
Джойны в транзакциях это всё про не про nosql. Другого решения этой проблемы пока не придумали. Цена поддержки этого очень высока, с этим очень неудобно работать, и приходится следить за многим прямо в коде. Миграции базы это вообще ужас.
Но свою задачу решает. Сотни миллионов атрибутов MySQL ворочал достаточно шустро.