На сайте таможни (по ссылке выше) не написано чьи это слова! Так что это ещё одна отписка за которую никто не отвечает.
Предложенный комплекс мероприятий, в конце, вызывает недоумение. Автор серьезно думает, что поможет? Или что-нибудь из списка не пытались сделать в последние 20 лет?
Поддерживаю автора в том, что такие вещи нужно пытаться написать. Продолжайте, это хорошая тренировка.
И не поддерживаю конкретно в этой затее.
Т. к. создание объекта в «управляемой памяти» фактически инкремент специального указателя (или нескольких указателей, в случае нескольких потоков), то ускориться в этом месте нельзя.
А вот если объекты «долго создаются», т.е. имеется разбазаривание времени в конструкторе, то этот момент нужно найти и победить.
А насчет пулов…
В одной системе я выкинул чей-то пул коннектов, и добился не только повышения ясности кода и повышения надежности (ради чего и выкидывал), но и увеличения производительности.
В другой системе мне удалось заменить пул одним коннектом к БД — тоже настала нирвана.
Для классного кода нужна политическая воля.
Постоянно случаются ситуации, когда менеджеры, писавшие код еще в студенчестве и на бейсике,
не дают
— провести рефакторинг неудачного решения
— переписать плохой фрагмент кода
— обложить тестами важную часть системы
А у разработчиков с дипломатией и политикой очень плохо. Вот и приходится, либо писать дерьмовый код, либо увольняться (и тогда недописаный код — становится унаследованным дерьмовым кодом).
Я с первого взгляда ее не понял.
А как только начнется какое-нибудь отклонение от сферического коня в вакууме, с таким тестом начнется проблема.
Вдруг появятся значения свойств «по умолчанию» и предложенная система потребует переосмысления и доработки. И отладки. А может быть написать модульные тесты для проверки работы системы модульного тестирования?
Нет. Тесты не то место, где нужно делать что-то сложное.
Не потерять бы за этим всем самое главное качество юнит-тестов: Скорость их выполнения! ;)
Если тесты выполняются слишком долго — нужно выяснить причину и исправить.
Чтобы 15 тысячами методов озадачить обычный комп, нужно очень плохо их написать.
Я бы советовал не добиваться сокращения тестового кода путем усложнения. Пусть будет
class SomeClassTests extends TestCase {
public void testSetOne() {
SomeClass x = new SomeClass();
x.setOne(1);
assertEquasl(1, x.getOne());
}
public void testSetTwo() {
SomeClass x = new SomeClass();
x.setTwo(2);
assertEquasl(2, x.getTwo());
}
...
}
Много строк, много методов, зато когда упадет любой из тестов, вам нужно будет понять всего 3 элементарных строчки, а не алгоритм системы автоматической проверки. Который, кстати, может оказаться непригодным для каких-то условий!
Не пугайтесь, если на систему из 30 тыс строк, у вас 15 тысяч тестовых методов (т.е. 50 тыс строк тестов). Главное, чтобы все они были простыми.
Меня вымораживают такие тесты. Как это прочитать? Что здесь имеется ввиду?
"С помощью УтвержденияИзменяемогоСвойства удостовериться, что ЗапросСвойства типа int, вида sut.Year, взятый у отражения DateViewModel..." всё! Или, что УтверждениеИзменяемогоСвойства удостоверилось без возражений в.…
И что будет в сообщении об ошибке когда тест не пройдет? «ЗапросСвойства типа int вида sut.Year не соответствует ожидаемому поведению из УтвержденияИзменяемогоСвойства»? WTF? Конкретнее!
Зачем нужно было отказываться от этого:
var sut = new DateViewModel();
sut.Year = 2010;
Assert.Equal(2010, sut.Year);
Именно так должны выглядеть тесты. Императивно, последовательно, линейно.
Читаем:
1. Взять для теста новый экземпляр DateViewModel созданный конструктором без параметров
2. Установить ему в Year значение 2010
3. Проверить, чтобы из Year вернулось значение 2010
Во-первых, ни один программист не прочтет это по другому. Во-вторых, любое падение этого теста будет банальным и прямолинейным. «Не удалось создать объект для теста, по такой-то причине»,
«Не удалось установить значение 2010 свойству Year, по такой-то причине»,
«Из Year получено значение 10, тогда как ожидалось 2010».
Спасибо за наводку. Очень интересно.
Не уверен, что хочу что-то изобрести. На мой взгляд Git должен (и, уверен, будет) справляться с репозиториями больших размеров.
* Если много мелких файлов — гит упакует их в пак.
* Большая глубина вложенности — не проблема (листинг одного каталога в отдельном файле со ссылками на листинги вложенных).
* Огромное количество правок одного файла — гит запишет последний вариант целиком, а предыдущие может сократить и заменить «дельтами».
Потенциально проблемное место — файлы более 2G. Их git не будет разбивать на несколько. Т.е. положить такой репозиторий на файловую систему не поддерживающую большие файлы не удастся. Или клонировать через древний http сервер, тоже могут быть проблемы. Однако более-менее современные системы без труда обслуживают такие файлы.
И еще одно место с потенциалом неоптимального функционирования — это дельты. Git хранит последнюю версию файла, а предыдущие, если есть резон упаковывает в дельты (при упаковке).
Т.е.
Добавим файл в 1000 строк и закомитим. (в репозитории лежит файл в 1000 строк)
Изменим 1 строчку и закомитим. (в репозитории лежат 2 файла по 1000 строк!)
Выполним git gc. (В репозитории 1 пак 1001 стока и 1 индек 2 строки — примерно)
Изменим еще одну строчку и закомитим. (в репозитории 1 индек 2 строки, 1 пак 1001 строка, 1 файл 1000 строк).
Опять git gc. И вот тут Git-у во-первых приходится переделывать все паки в которых есть версии файлов изменившихся с последней упаковки. А во-вторых ранее существовавшие паки оказывается устаревшим.
Ах, вот, что вы имеете ввиду!
Нет, не соглашусь. Здесь всё ванильно!
Git в значительной степени лично Торвальдс сделал, а Sitaram Chamarty, основной разработчик gitolite, как минимум с Торвальдсом переписывался.
Да, в Git приходится тянуть всю историю, но тянуть можно с соседней машины, или из bundle (см. git help bundle).
В svn тянуть нужно только последний снимок, но только с сервера.
Мне показалось, что его «архитектура» вполне пригодна для больших репозиториев. За год-другой он дозреет. Ему бы «более поточный» алгоритм поиска «дельт», и отказаться от проецирования файлов в память в пользу файлов с произвольным доступом.
Предложенный комплекс мероприятий, в конце, вызывает недоумение. Автор серьезно думает, что поможет? Или что-нибудь из списка не пытались сделать в последние 20 лет?
/Сообщение приводится в переводе. Путь перевода: Мой разговорный -> исключение ненормативных выражений -> исключение личных оскорблений -> исключение пожеланий вредных для здоровья -> исключение призывов к трансцендентным силам с просьбой вмешаться -> исключение упоминания парнокопытных животных/
И не поддерживаю конкретно в этой затее.
Т. к. создание объекта в «управляемой памяти» фактически инкремент специального указателя (или нескольких указателей, в случае нескольких потоков), то ускориться в этом месте нельзя.
А вот если объекты «долго создаются», т.е. имеется разбазаривание времени в конструкторе, то этот момент нужно найти и победить.
А насчет пулов…
В одной системе я выкинул чей-то пул коннектов, и добился не только повышения ясности кода и повышения надежности (ради чего и выкидывал), но и увеличения производительности.
В другой системе мне удалось заменить пул одним коннектом к БД — тоже настала нирвана.
Постоянно случаются ситуации, когда менеджеры, писавшие код еще в студенчестве и на бейсике,
не дают
— провести рефакторинг неудачного решения
— переписать плохой фрагмент кода
— обложить тестами важную часть системы
А у разработчиков с дипломатией и политикой очень плохо. Вот и приходится, либо писать дерьмовый код, либо увольняться (и тогда недописаный код — становится унаследованным дерьмовым кодом).
Вот строчка
Я с первого взгляда ее не понял.
А как только начнется какое-нибудь отклонение от сферического коня в вакууме, с таким тестом начнется проблема.
Вдруг появятся значения свойств «по умолчанию» и предложенная система потребует переосмысления и доработки. И отладки. А может быть написать модульные тесты для проверки работы системы модульного тестирования?
Нет. Тесты не то место, где нужно делать что-то сложное.
Если тесты выполняются слишком долго — нужно выяснить причину и исправить.
Чтобы 15 тысячами методов озадачить обычный комп, нужно очень плохо их написать.
Много строк, много методов, зато когда упадет любой из тестов, вам нужно будет понять всего 3 элементарных строчки, а не алгоритм системы автоматической проверки. Который, кстати, может оказаться непригодным для каких-то условий!
Не пугайтесь, если на систему из 30 тыс строк, у вас 15 тысяч тестовых методов (т.е. 50 тыс строк тестов). Главное, чтобы все они были простыми.
Меня вымораживают такие тесты. Как это прочитать? Что здесь имеется ввиду?
"С помощью УтвержденияИзменяемогоСвойства удостовериться, что ЗапросСвойства типа int, вида sut.Year, взятый у отражения DateViewModel..." всё! Или, что УтверждениеИзменяемогоСвойства удостоверилось без возражений в.…
И что будет в сообщении об ошибке когда тест не пройдет? «ЗапросСвойства типа int вида sut.Year не соответствует ожидаемому поведению из УтвержденияИзменяемогоСвойства»? WTF? Конкретнее!
Зачем нужно было отказываться от этого:
Именно так должны выглядеть тесты. Императивно, последовательно, линейно.
Читаем:
1. Взять для теста новый экземпляр DateViewModel созданный конструктором без параметров
2. Установить ему в Year значение 2010
3. Проверить, чтобы из Year вернулось значение 2010
Во-первых, ни один программист не прочтет это по другому. Во-вторых, любое падение этого теста будет банальным и прямолинейным.
«Не удалось создать объект для теста, по такой-то причине»,
«Не удалось установить значение 2010 свойству Year, по такой-то причине»,
«Из Year получено значение 10, тогда как ожидалось 2010».
Не уверен, что хочу что-то изобрести. На мой взгляд Git должен (и, уверен, будет) справляться с репозиториями больших размеров.
* Если много мелких файлов — гит упакует их в пак.
* Большая глубина вложенности — не проблема (листинг одного каталога в отдельном файле со ссылками на листинги вложенных).
* Огромное количество правок одного файла — гит запишет последний вариант целиком, а предыдущие может сократить и заменить «дельтами».
Потенциально проблемное место — файлы более 2G. Их git не будет разбивать на несколько. Т.е. положить такой репозиторий на файловую систему не поддерживающую большие файлы не удастся. Или клонировать через древний http сервер, тоже могут быть проблемы. Однако более-менее современные системы без труда обслуживают такие файлы.
И еще одно место с потенциалом неоптимального функционирования — это дельты. Git хранит последнюю версию файла, а предыдущие, если есть резон упаковывает в дельты (при упаковке).
Т.е.
Добавим файл в 1000 строк и закомитим. (в репозитории лежит файл в 1000 строк)
Изменим 1 строчку и закомитим. (в репозитории лежат 2 файла по 1000 строк!)
Выполним git gc. (В репозитории 1 пак 1001 стока и 1 индек 2 строки — примерно)
Изменим еще одну строчку и закомитим. (в репозитории 1 индек 2 строки, 1 пак 1001 строка, 1 файл 1000 строк).
Опять git gc. И вот тут Git-у во-первых приходится переделывать все паки в которых есть версии файлов изменившихся с последней упаковки. А во-вторых ранее существовавшие паки оказывается устаревшим.
Нет, не соглашусь. Здесь всё ванильно!
Git в значительной степени лично Торвальдс сделал, а Sitaram Chamarty, основной разработчик gitolite, как минимум с Торвальдсом переписывался.
В svn тянуть нужно только последний снимок, но только с сервера.