• Advertisement
Sign in to follow this  

refactor and team development

This topic is 4338 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Some one that a project manager ever in big software company tell me a fact: requirement and document (that include almost everything: every function logic in pseudo-code and local variables)is approximately confirmed and can not be changed in the future. because if you refactor some class, it will influence other in a team. it will make development impossible. but I heard of the requirement and design can not be settled down. it is the reason that make code bad smell. Could the requirment and design be confirmed first and then the coder will "translate" document to code without alter the design and code?

Share this post


Link to post
Share on other sites
Advertisement
"Refactoring" means improving the code without changing the external behavior of it. Also, in my opinion, planning everything out before coding is a bad idea.

Share this post


Link to post
Share on other sites
>Also, in my opinion, planning everything out before coding is a bad idea.
I wonder what my house would look like, if the architect of it
would have said the same...

Share this post


Link to post
Share on other sites
Refactoring changes the implementation, without changing the behaviour. This can be applied to any part of code and is nothing bad.

Agile development includes refactoring, but applies it to entire project, removing the need for upfront design document. It relies on unit testing or test driven design as primary method of development.

Specifications in agile development are user stories. Specifications in waterfall (or similar) approach is the requirements and design documentation.

Each of these has advantages and disadvantages, and is not suitable for everything. There are areas and industries where one or another is preferred.

Share this post


Link to post
Share on other sites
Quote:
Original post by Antheus
Refactoring changes the implementation, without changing the behaviour. This can be applied to any part of code and is nothing bad.

Agile development includes refactoring, but applies it to entire project, removing the need for upfront design document. It relies on unit testing or test driven design as primary method of development.

Specifications in agile development are user stories. Specifications in waterfall (or similar) approach is the requirements and design documentation.

Each of these has advantages and disadvantages, and is not suitable for everything. There are areas and industries where one or another is preferred.


Can test driven design substitute the upfront design document?

Share this post


Link to post
Share on other sites
Quote:
Original post by Kitt3n
>Also, in my opinion, planning everything out before coding is a bad idea.
I wonder what my house would look like, if the architect of it
would have said the same...


Coding is very different from that. Also, you will note that I did not say that you should not do any planning. I said that I don't believe you should plan everything out. I usually just get a general idea of what I want to do (usually just in my head), then start coding. I often work bottom-up and top-down.

Share this post


Link to post
Share on other sites
First of all, an essential url on refactoring

http://www.refactoring.com/

From the author Martin Fowler a guru on software engineering

About requirements, the tradicional approach, the waterfall cycle, has failed precisely because tries to confirm the requirements before coding. Requirements appear all over the develompment process (no matter what you do, they appear). That's why iterative methods are becoming more and more popular.

If some of you can read spanish let me suggest this document about requirements.

http://www.lsi.us.es/~amador/publicaciones/tesis.pdf.zip

Share this post


Link to post
Share on other sites
Quote:
Original post by Juan Diego
First of all, an essential url on refactoring

http://www.refactoring.com/

From the author Martin Fowler a guru on software engineering

About requirements, the tradicional approach, the waterfall cycle, has failed precisely because tries to confirm the requirements before coding. Requirements appear all over the develompment process (no matter what you do, they appear). That's why iterative methods are becoming more and more popular.

If some of you can read spanish let me suggest this document about requirements.

http://www.lsi.us.es/~amador/publicaciones/tesis.pdf.zip


but I heard of some big manager said: if you can not confirm most requirement,
it is impossible to develope a big project based a team cooperation.

Share this post


Link to post
Share on other sites
Well, talking about requirements in an iterative cycle.

The main idea is that you can't wait untill you get ALL requirements because that's, in practice, mostly imposible. Requirements capture is an iterative activity too.

Using some technique (joins, interview, brainstorming etc..) you must start requirements capture. Once you have collected them you must vericate, validate and priorize them with the customer. Once you have done that previous work, you can start to code but having in mind that in requirement revision and validations new requirements will appear, even in develompment phases they appear. If is that the case new requirement cycle must start (elicitation-verificatios-validation). To that point requirement, design and coding can be parallel activities

If you don't understand my english tell me , i'll try to rewrite the post

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement