да понятно все… так и делаем… конкретно на рефакторинг просто времени особо нет… а еще там есть ряд тестов, которые тупо в цикле бегут по базе и проверяют интерпретируемые сценарии — сложность там квадратичная, и тормоза из-за интерпретатора, и один такой тест легко минуту занимает, и как его оптимизировать, не совсем ясно… так что только деление на медленные и быстрые тесты, да…
Обычно имеет смысл писать тест, который проверяет базовую функциональность вновь добавляемой фичи — чтобы просто не поднимать весь сервер и не проверять ручками через браузер.
А далее, при поддержке и развитии, основное правило — каждый обнаруженый баг должен быть покрыт новым тестом (по возможности).
Поддержка самих тестов не отнимает много времени — они редко ломаются, и если ломаются, то по делу. Вот запуск всех тестов — это да… у нас уже минут 20 занимает полный прогон. Но их, собственно, должен билд-сервер автоматом гонять время от времени.
Присоединяюсь — я подключился к Evernote и не стал использовать из-за отсутствия планировщика. То есть, понятно, что есть специализированные инструменты, и Evernote задумывался для другого. Но как-то сразу такой фичи не хватает…
Я на днях пробовал играться с Kotlin (JVM-based язык), и был неприятно удивлени отсутствием старого доброго for-a. Поигравшись немного, понял, почему они его убрали.
В Kotlin проход по индексам осуществляется выражением
for( val index: array.indices )
таким образом, нет типовых ошибок с «i < a.size()» vs. «i <= a.size()»
Это к тому, что старый добрый for, возможно, устарел :-)
Функции-члены того же класса могут вызывать конструктор копирования и оператор присваивания, даже если те объявлены private. И «друзья» класса (friend) тоже могут.
Обычный паттерн — это как в бусте — объявить простой trait класс NonCopyable и от него наследоваться.
В таком случае никакие френды или функции в классах наследниках не смогут скопировать класс.
На самом деле еще лучше иметь два класса — NonCopyable и NonAssignable (запрещает только присваивание)… и до кучи NonInheritable (но этот уже использует несколько спорный трюк, и его не все платформы поддерживают, AFAIK).
Это от платформы зависит… так что они верно пишут про неопределенное поведение. Так что мьютексы могут получиться как рекурсивными, так и нет.
Если разработка под заранее известные платформы, как это обычно бывает, то не страшно — можно заранее определиться с поведением, и защитить юнит тестами.
И для кросс-платформенной разработки неопределенное поведение не есть гут — источник багов и будущих проблем.
А далее, при поддержке и развитии, основное правило — каждый обнаруженый баг должен быть покрыт новым тестом (по возможности).
Поддержка самих тестов не отнимает много времени — они редко ломаются, и если ломаются, то по делу. Вот запуск всех тестов — это да… у нас уже минут 20 занимает полный прогон. Но их, собственно, должен билд-сервер автоматом гонять время от времени.
Если-б сидел на Винде, то Outlook бы пользовал.
А для оставшихся случаев есть while.
for( val index: array.indices.reverse )
Но я глубоко не вникал, так по верхушкам посмотрел…
В Kotlin проход по индексам осуществляется выражением
for( val index: array.indices )
таким образом, нет типовых ошибок с «i < a.size()» vs. «i <= a.size()»
Это к тому, что старый добрый for, возможно, устарел :-)
C++0x forever!
Обычный паттерн — это как в бусте — объявить простой trait класс NonCopyable и от него наследоваться.
В таком случае никакие френды или функции в классах наследниках не смогут скопировать класс.
На самом деле еще лучше иметь два класса — NonCopyable и NonAssignable (запрещает только присваивание)… и до кучи NonInheritable (но этот уже использует несколько спорный трюк, и его не все платформы поддерживают, AFAIK).
Если разработка под заранее известные платформы, как это обычно бывает, то не страшно — можно заранее определиться с поведением, и защитить юнит тестами.
И для кросс-платформенной разработки неопределенное поведение не есть гут — источник багов и будущих проблем.
Стоит упомянуть code.google.com/apis/chart/interactive/docs/gallery/motionchart.html мне кажется — тоже отличный пример визуализации