Я в последнее время все больше думаю что бардак в разработке это хорошо, если это правильно организованный бардак. А всякие скрамы и аджайлы это чистый маркетинг.
Эх, не люблю я термин Рефакторинг (наверно детская травма), но в последнее время в него намешали всякого, да и обычно менеджмент не любит таких слов.
А какой интересно процент обнаружения (распределения по источникам) ошибок у JetBrains? Сколько ошибок находятся при помощи unit-тестов?
А кто у вас пишет функциональные тесты? Обычные разработчики? Какое покрытие? Много ли у вас тестов приходится поддерживать при изменениях (например архитектуры)?
Спасибо за введение, я думаю что начинающим это пригодится. Тем более приведены очень простые примеры, благодаря которым можно понять механизм работы кэширования вызовов.
Кстати, я нечто подобное уже заимплементил в своем проекте (на базе: аннотаций + интерцепторов). И пришел к выводу, что это чрезвычайно полезная штука для сложных вычислений. К примеру, у меня есть код который считает финансовый план, при этом данные берутся из 10-20 разных источников, причем есть граф вызовов методов. Без кэширования расчет занимал порядка часа, а при кэшировании расчет проходил за 2-3 минуты.
Конечно можно было оптимизировать все на уровне запросов к БД, но это бы сильно усложнило код, да и запросы понять было бы намного сложнее. А так получилось все намного проще и лучше. К тому же модульность не пострадала.
Немного слов о кэшировании. К сожалению кэшировать данные иногда не лучший выбор, но иногда можно выделить неизменный контекст. Например описанный мной ранее пример кэширует данные на уровне транзакции пользователя. И для запросов на чтение и расчет это довольно неплохо работает.
Также стоит отметить что готовых решений из коробки нет, практически все предлагают допиливание решений под себя, что немного грустно (потому что не всегда адекватно и понятно работает). Возможно мир еще не готов к данному подходу. Хотя говорят у сапа есть что-то подобное, но тут нужен ихний специалист :)
Видимо я плохо объяснял, тесты это не панацея. Это что-то помогающее писать текущий код (строительные леса). А для проверки архитектуры, особенно которую периодически рефакторят, это только лишний вес :)
Спорный вопрос, что использование уже написанных кем-то классов в проекте это хорошо. А вдруг владелец кода не посоветовавшись внесет значимые изменения? Но опять же это палка о двух концах. Тут нужна сплоченная команда или злобный тимлид смотрящий в код :)
ок, я немного не понял вашу мысль :) Но если по существу, то стоимость поддержки таких скриптов непонятна (сколько на это времени надобно?).
И не стоит забывать что разработчик должен все сам уметь настраивать, автоматические средства это всего лишь средство, которое надо понимать.
Не люблю я автоматические штуки. Затраты на их поддержание большие. Разве что кнопка спасет мир, но не всегда. Вот например структура БД изменилась и что? Автоматика иногда дает сбой.
Кстати промежуточный сервер полезная штука, особенно если там данные в БД адекватные :)
В целом конечно ты прав, но есть ряд ограничений :)
Во первых, человек должен уже иметь опыт развертывания одного проекта. От этапа проектирования до этапа поддержки. Он должен понять что такое компромис и как порой грустно бывает, что приходиться на него идти. Ты же пишешь, что он не знает всех тех трудностей что ему предстоят.
Во вторых, человек должен хоть немного владеть будущими технологиями, а он до этого использовал php и mysql. Как он может сосредоточиться на создании многофункциональной системы, если он должен научится новым технологиям?
Кстати ты знаешь яркий пример человека который спроектировал вторую систему, это наш общий знакомый зануда-дистанционщик :)
Эх, не люблю я термин Рефакторинг (наверно детская травма), но в последнее время в него намешали всякого, да и обычно менеджмент не любит таких слов.
А какой интересно процент обнаружения (распределения по источникам) ошибок у JetBrains? Сколько ошибок находятся при помощи unit-тестов?
А кто у вас пишет функциональные тесты? Обычные разработчики? Какое покрытие? Много ли у вас тестов приходится поддерживать при изменениях (например архитектуры)?
Кстати, я нечто подобное уже заимплементил в своем проекте (на базе: аннотаций + интерцепторов). И пришел к выводу, что это чрезвычайно полезная штука для сложных вычислений. К примеру, у меня есть код который считает финансовый план, при этом данные берутся из 10-20 разных источников, причем есть граф вызовов методов. Без кэширования расчет занимал порядка часа, а при кэшировании расчет проходил за 2-3 минуты.
Конечно можно было оптимизировать все на уровне запросов к БД, но это бы сильно усложнило код, да и запросы понять было бы намного сложнее. А так получилось все намного проще и лучше. К тому же модульность не пострадала.
Немного слов о кэшировании. К сожалению кэшировать данные иногда не лучший выбор, но иногда можно выделить неизменный контекст. Например описанный мной ранее пример кэширует данные на уровне транзакции пользователя. И для запросов на чтение и расчет это довольно неплохо работает.
Также стоит отметить что готовых решений из коробки нет, практически все предлагают допиливание решений под себя, что немного грустно (потому что не всегда адекватно и понятно работает). Возможно мир еще не готов к данному подходу. Хотя говорят у сапа есть что-то подобное, но тут нужен ихний специалист :)
10 мегабит безлимита для физического лица 2 700 рублей.
10 мегабит безлимита для юридического лица 51 300 рублей (без НДС).
И не стоит забывать что разработчик должен все сам уметь настраивать, автоматические средства это всего лишь средство, которое надо понимать.
Кстати промежуточный сервер полезная штука, особенно если там данные в БД адекватные :)
Во первых, человек должен уже иметь опыт развертывания одного проекта. От этапа проектирования до этапа поддержки. Он должен понять что такое компромис и как порой грустно бывает, что приходиться на него идти. Ты же пишешь, что он не знает всех тех трудностей что ему предстоят.
Во вторых, человек должен хоть немного владеть будущими технологиями, а он до этого использовал php и mysql. Как он может сосредоточиться на создании многофункциональной системы, если он должен научится новым технологиям?
Кстати ты знаешь яркий пример человека который спроектировал вторую систему, это наш общий знакомый зануда-дистанционщик :)