All streams
Search
Write a publication
Pull to refresh
29
0
Bender Bending Rodriguez @bendingunit22

Специалист по всему

Send message
В целом по инверсии зависимостей рекомендую почитать вот этот материал. А вот здесь о DI контейнерах в перле.
Design Patterns (GoF), Patterns of Enterprise Application Architecture (Martin Fowler), Design Patterns Explained (Alan Shalloway), Agile Software Development (Robert C. Martin). В последней книге детально описываются все SOLID принципы, так что она интересна не только в контексте аджайла. Все книги есть на русском.
А разве уже не сбежали?
В 2001 году многие тоже так думали :) Но что-то счастье не приходит.
Именно поэтому наследование в современном ООП используется не так, как раньше, и заменяется агрегацией. Взять к примеру тот же декоратор.
А какая связь между ООП и сложностью приложений? ООП точно так же проповедует принципы слабой связанности, сильного зацепления, единственной обязанности и т.д.
Cucumber — для приемочного тестирования, RSpec – для модульного.
Интересно будет отдельно почитать о результатах рекламы на хабре.
Пять балов! У меня serve_request в пол экрана не влез :)
Можно сократить до «наследвание — зло» :)
Я бы сказал не спорно, а в корне неверно.
Запустить тесты? :)
Имеет ли смысл подписывать сообщения, если не предполагается, что API будет предоставляться пользователями третьим лицам? В этом случае отдельного аккаунта для робота и базовой авторизации по ssl будет достаточно. По крайней мере, так кажется на первый взгляд.
Могу вам напомнить :) В дедлайте этому посвящена, в частности, глава 12.

— Предположим, что команда из десяти человек может разработать за год приложение величиной в тысячу единиц (каких единиц, я пока не знаю, их еще не изобрели, но пусть это будут некие условные единицы). Так вот, если десять человек за год вырабатывают тысячу единиц, то сколько единиц сделает за полгода команда из двадцати человек, предположительно такой же квалификации?
— Меньше, чем тысячу.
— А насколько меньше?
— Намного!
— Намного — это на сколько?
— Очень много.



— Иными словами, «чистая производительность» четырех человек, работающих в одной команде, будет приблизительно на треть меньше, чем «производительная мощность» человека, работающего над проектом в одиночку, помноженная на четыре?
Мистер Томпкинс пожал плечами.
— Разумеется, я не могу говорить с полной уверенностью, но мне кажется, так оно и есть.


ну и дальше в том же духе.
На самом деле причины этого хорошо описаны в книгах «Мифический человеко-месяц» Брукса и «Deadline. Роман об управлении проектами» ДеМарко. Если не знакомы, очень рекомендую к прочтению, особенно последнюю.
Дискуссия с автором комментария в соседнем топике :)
Не делайте допущений :)

Каким образом в реальном коде вы планируете узнать, что метод set отработал без ошибок? Уж явно не будите вызывать get и проверять, что значение установлено :) Вот определитесь с поведением и опишите его в тесте. Не нравится булево значение, смотрите, чтоб не было эксепшена, например.

Information

Rating
Does not participate
Registered
Activity