Ничего не имею против новшества, но было бы справедливо, если бы вместе с изменением лицензионной политики соответствующим образом изменилось отношение к запросам пользователей. Вот например, нас шесть лет убеждают, что нам не нужна эта фича.
После определенного (не очень высокого) возраста механизм роста глазного яблока прекращает свое действие. Поэтому близорукость за счет удлинения глаза очень маловероятна.
Я считаю, что некоторое кол-во лет опыта — необходимое (но не недостаточное) условие того, чтобы быть профессионалом.
По поводу содержания статьи… Вы подняли очень важный вопрос. Мегаважный, и имеющий отношение не только к тестированию, но и к непосредственно разработке, и к менеджменту. Этот вопрос — недостаток квалифицированных кадров. Из-за свитчеров это происходит или нет, в тестировании или другой отрасли — какая, собственно, разница, если профессионализм определяется количеством вложенных в дело умственных и физических усилий?
WSDL файл и SOAP автоматически генерируются на основе кода.
… и на свет появляется очередное го*но-API, состоящее из точащих наружу кишков го*но-приложения.
Извините за резкость, но API — это то, над чем надо очень, очень хорошо думать. И то, что в REST нельзя добавить 100500 разношестных методов на все случаи жизни с кучей побочных эффектов — это очень хорошо для публичных API.
Никто не должен ни перед кем отвечать. Agile — это когда все работают вместе (каждый на своем участке), за факап одного отвечают все, и таким образом все заинтересованы в помощи друг другу.
Это все, конечно, хорошо (почти хорошо, см. выше коммент про сортировку по id), но такими темпами придется очень долго исследовать то, что у Постгресса под капотом…
Ускорение отклоняло бы люльку, чтобы в критический момент ребенок оказывался в вертикальном положении и вектором силы, направленным от груди к спине, как у космонавта.
Глобальные переменные — это пример неявного контракта. Прямая зависомость кода от юзер-функции в другом модуле — это тоже неявный контракт. Так же плохо, как глобальная переменная.
P.S. Чистая функция, пишущая в файл (в вашем исходном примере, с которого все началось)? Вы издеваетесь? :)
Самый лучший вариант — использовать одну коллекцию для хранения всех видов документов. И поскольку для каждого документа схема может быть любой, то можно хранить все имеющиеся у товара характеристики (атрибуты) в одном документе.
Нет, это не лучший вариант. Потому что ограничение в 50 индексов на коллекцию сильно ограничит возможности поиска разнообразных документов (вы же не хотите фуллсканом бегать по данным?) + ущерб производительности за счет большого кол-ва индексов.
Более правильно каждую категорию хранить в своей коллекции. Т.к. в Монге нет DDL, это почти не усложнит приложение.
Хм. Потому что я не хочу перегружать. Я хочу прямо в конструкторе видеть все зависимости класса-потребителя (вы же знаете, чем плохи глобальные переменные? в том числе неявным контрактом того куска кода, где они используются. А если у меня нет доступа к исходникам?); я хочу в рантайме эти зависимости устанавливать на то, что мне нужно в данный момент, включая то, что в один экземпляр класса я передам одну реализацию, а в другой — другую (я не про абстрактное «вдруг мне понадобиться заменить...», а про запуск на проде и в IDE в изоляции, например); я хочу нормальное переиспользование кода за счет SRP; за счет SRP же я хочу простую поддерживаемость в дальнейшем; наконец, я не хочу хитровывертов с перегрузкой, даже если я могу их сделать.
Слушайте, ну поищите уже в интернете, зачем нужны интерфейсы… Пожалуста, не обижайтесь за такой совет, но это азы и об этом написаны просто кучи материалов и книг.
P.S. Было бы интересно узнать, для чего по Вашему мнению нужны классы/объекты (или ООП).
По поводу содержания статьи… Вы подняли очень важный вопрос. Мегаважный, и имеющий отношение не только к тестированию, но и к непосредственно разработке, и к менеджменту. Этот вопрос — недостаток квалифицированных кадров. Из-за свитчеров это происходит или нет, в тестировании или другой отрасли — какая, собственно, разница, если профессионализм определяется количеством вложенных в дело умственных и физических усилий?
… и на свет появляется очередное го*но-API, состоящее из точащих наружу кишков го*но-приложения.
Извините за резкость, но API — это то, над чем надо очень, очень хорошо думать. И то, что в REST нельзя добавить 100500 разношестных методов на все случаи жизни с кучей побочных эффектов — это очень хорошо для публичных API.
О нет. И это хорошо.
Кстати, это в точности то, как работает TDD: назначили действие — проверили, не слишком ли много классу надо знать для этого.
Спасибо за наводку!
Ускорение отклоняло бы люльку, чтобы в критический момент ребенок оказывался в вертикальном положении и вектором силы, направленным от груди к спине, как у космонавта.
Несколько десятков лет этой технологии. Широко применялась в немецкой истребительной авиации.
Самый лучший вопрос — «о чем класс знает?»
Хотя это и дешево.
P.S. Чистая функция, пишущая в файл (в вашем исходном примере, с которого все началось)? Вы издеваетесь? :)
И коллекцию лучше назвать по имени категории, а продукты в ней сделать документами первого уровня.
Нет, это не лучший вариант. Потому что ограничение в 50 индексов на коллекцию сильно ограничит возможности поиска разнообразных документов (вы же не хотите фуллсканом бегать по данным?) + ущерб производительности за счет большого кол-ва индексов.
Более правильно каждую категорию хранить в своей коллекции. Т.к. в Монге нет DDL, это почти не усложнит приложение.
Слушайте, ну поищите уже в интернете, зачем нужны интерфейсы… Пожалуста, не обижайтесь за такой совет, но это азы и об этом написаны просто кучи материалов и книг.
P.S. Было бы интересно узнать, для чего по Вашему мнению нужны классы/объекты (или ООП).