Гибкая разработка и архитектура [закрываются]
На самом деле иногда существуют причины, которым кто-то может извлечь выгоду из статических методов. Они могут использоваться в качестве методов фабрики для классов, которые реализуют интерфейс. Например, это - причина, у нас есть интерфейс Collection и класс Наборов в openjdk теперь. Таким образом, существуют обходные решения, как всегда - предоставляют другому классу частного конструктора, который будет служить "пространством имен" для статических методов.
3 ответа
Agile is often described as "only do what you need to do now, and you can refactor later if more things are needed".
This is rather misleading. It can be read as "bodge something in quickly now, and then work out how to upgrade it to do more things in the future". Which will lead to a world of pain and technical debt.
For any system you need a design. For small/simple systems this design can be in your head, but you still need to think before you start about what the system will do, and how best to do it.
So IMHO the correct way to include design into an Agile approach is to design enough now that you know what the system is ultimately expected to do, and broad strokes describing how it will do it. Come up with a flexible enough design that you don't burn any bridges. But don't waste time writing a formal detailed specification for every nut and bolt. Design down to a level where you know where and how a subsystem will fit in, but it can be treated as a "black box" that in itself can be designed only when you need to implement it.
Agile development shouldn't exclude a formal architecture - it just means that you should only design enough of the formal architecture that all the bits will fit together well when you are finished, and you flesh out the smaller details of that design only as and when they are needed. Sometimes that means you still need a fairly detailed design up front.
Depends on your scope. Could be a given, could be green-field. Just enough architecture, just in time. You need something to be able write your first tests, do continuous integration.
It is a document, so who is going to need it, and to do what?
- your team needs something to describe where to put functionality and where tests;
- when you have to grow your team the new guy might like an introduction;
- marketing might need beautiful pictures;
- someone might have to buy and install hard- and software; ...
Scrum - это, в основном, метод управления проектами, поэтому в нем не упоминается архитектура.
Архитектура определяется по мере возможности постепенно. В этом отношении помогает сквозная реализация, а не слой за слоем: это приводит к реализации части на каждом уровне.
Архитектурные решения может быть трудно отменить, поэтому они должны быть хорошо продуманы и приняты в последний ответственный момент, когда у вас будет больше знаний о системе и потребностях клиентов.
Нет особой необходимости в формальном Спецификация.