Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Hallo everybody
Recently I've been reading the book:
"Agile software development, Principles, Patterns and Practices" by Bob Martin
The following (S.O.L.I.D) agile-design-principles are listed within the book:
Single Responsibility Principle
Open Closed Principle Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
Because of the fact that this book quite old(2003), I have a question:
Are there any other newly developed principles besides the SOLID methods?? If yes, is there any book/site covering these new emerging principles with practical code examples that you could recommend to me??
Of course I can google for some of these.
However, in stackoverflow read and write many profis, so I would like to hear their opinion too :D
You may want to look at books such as Code Complete and Pragmatic Programmer as they also talk about some excellent development principles.
I like the Domain Driven Design approach from Eric Evans:
http://domaindrivendesign.org/
http://domaindrivendesign.org/books#DDD
As the SOLID approach you describe, DDD is mostly sound and clean Object Orientation guidelines. DDD focus especially on creating a design which match as much as possible with the business to be implemented in the system, rather than having it guided by the technology and/or the frameworks you use. This lead to great testable design, easy to refactor.
In support to DDD, I like the Hexagonal Architecture of Alistair Cockburn. It gives you great ideas about general design of Object Oriented systems:
http://alistair.cockburn.us/Hexagonal+architecture
A more advanced and innovative approach I am currently exploring is the theory of centers, but this is not yet really documented. A presentation about it:
http://www.dreamsongs.com/Files/NatureOfOrder.pdf
UncleBob's book is a SOLID start ;) I'd add his Clean Code to your reading list too. For actual code construction it is a great tome.
Kindness,
Dan
You can find further design principles at http://www.objectmentor.com, the author's / Object Mentor's homepage. They were written around the same time as SOLID, you can find most of them at http://www.objectmentor.com/resources/publishedArticles.html.
This list is not for design principles only, but also an explanation of OOP, Agile architecture, design and practices, it is based on patterns of mistakes and a regular pain from my real projects, including both books and online articles:
Software Developer / Architect Recommended Reading
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 12 months ago.
Improve this question
UML has come into many projects with object-oriented programming and is widely taught in colleges. However, today many software projects use a more or less agile approach, avoiding up-front in-depth analysis and leading to many changes ("welcome change"). In contrast, creating correct and readable UML (class) diagrams is still time-consuming; hence the value of documenting the model is in practice often considered time waste, as it changes often.
Even autogenerated (from source code) diagrams are not solving the problem, as they cannot correctly resolve class relationships often have insufficient graph layouts and distracting extensions.
Can UML be used in an agile context in a way that avoids the overhead of frequent manual updates? Or are other lighter alternatives to UML more suitable in such a context?
UML can be used in a light way in an agile context. The key is simply to be clear about its purpose and what you expect from modeling in your project.
Class diagrams and sequence diagrams are proven to be good candidates for helping teams to discuss points of concerns. It can express clearly ideas that are not obvious in the code (or scattered across many source files).
Scott Ambler for example wrote a lot on agile modeling, based on UML. Of course, you will not use it for producing an exhaustive model with all classes and all properties. But you'd sketch the core with some relevant classes, and only a few properties that matter in the discussion (Ambler says "Just barely enough" modeling).
However, for architectural modeling (deployment diagrams and the like), UML requires a degree of precision that is not always possible in early stages. Here C4 models has established as a convenient and flexible alternative. But C4 relies on UML for the OOP design discussion. There is simply no alternative that allows to easily show classes and interaction between them, and that would be sufficiently widely known.
Conclusion: In an agile context, don't get misguided thinking that UML would require an exhaustive up-front design. Don't use it as for visual programming either, slavishly replicating details of the code. But use it as a communication tool to highlight key ideas and allow everyone to grasp the design and contribute productively.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Almost every one of my programming classes has made use of UML, but none have really explained when or where it might be used in a professional setting. Is it done for every single file in a project, or is there some rule of thumb of when you might want to use it? Also, is it more commonly done by hand (which I've always dreaded) or using some sort of generator?
This question is very good example of opinion-based and very broad question with no real problem to solve behind it and no one correct possible answer
Certainly in the amount of millions of software developers there are some who learned to use UML and do use it. And there are some who either did not learn to use UML or just don't use it for whatever reason
I recall that in the pre-agile era it was believed that no "big" software can be realized without thorough analysis and modeling phase and no "big" software contract can be signed if the business documents don't include some UML-style pictures
And in some countries it is still true and government-owned agencies declare what kind of documentation software contractor must provide, and for some of the requirements an UML picture is the good form
See also:
Wikipedia: Rational Unified Process (RUP)
Wikipedia: Software requirements specification
Programmers: Writing a Software Requirement Specification
So there are UML believers, UML skeptics and even UML haters, it depends on ... things.
I'm UML believer
and so is for example Mr. Kenji Hiranabe from Change Vision, Inc the company behind Astah UML modeling tool and he says
...Is modeling obsolete? Is UML dead? I don't think so. In this article...
as foreword to article Modeling in the Agile Age: What to keep next to Code to Scale Agile Teams
my favorite guideline is what The Guru said in an interview with Mark Collins-Cope for the Objective View magazine on Sep 12, 2014
Grady Booch, creator of the Unified Modelling Language (UML):
"The UML should be used to reason about alternatives. Put up some diagrams. Throw some use cases against it. Throw away those diagrams then write some code against you best decision. Repeat (and refactor)"
How you finally evaluate "..UML...commonly...real world.." depends on what you want to see and which software development best practices you adopt in your own work
It depends on your role, in most developer roles you will rarely, if ever, have to use it. I can see it being useful if you are designing something though, like a new database structure, or architecting a new system or application.
It can be useful for lead developers, architects, or IT managers in the design stages of the application for communicating ideas to the business folks as well as passing on a plan for the development team that will be building it out.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have a copy of Head First Design Patterns and I read through a few of the patterns in there. Now is Domain driven design a substitute to the traditional design patterns or does it build upon it? If its the latter, do I need to be a Design patterns expert before I attempt to learn domain driven design? What is the recommended path to DDD?
I read the blue book [Evans], the red book [Vernon] and occasionally pop into this tag on StackOverflow.
The book by Evans is very high level in some aspects and covers more than just code. The book by Vernon covers the building blocks of DDD an item at a time, using examples from a fictitious software product as an example:
Domain-driven Design: Tackling Complexity in the Heart of Software
Implementing Domain-Driven Design
There's also the video:
Eric Evans: What I've learned about DDD since the book
As for design patterns, the DDD material refers to lots of design patterns. Some existing design patterns work very well with DDD. You can pick these up as you encounter them, you wont necessarily need to know them in advance. One thing to avoid when learning design patterns, is to not try and force their use, they have their uses but you see a lot of developers trying to force the use of newly learnt design patterns in places where they aren't required.
Just do it. Don't let any preconceived condition prevents you from starting to practice it.
This is a bit late answer, but i want to say that patterns are not some set-in-stone follow-to-the-letter ultimate solutions. They are generic approaches to generic problems, guidelines if you want.
In DDD you provide specific solution to specific problems. If you can recognize patterns in your implementation you will gain a bit deeper and more structured understanding. If you can see problems calling for some patterns, you will have possible approaches for solving it. But beware, looking at the problem solely through patterns might lead to suboptimal solutions.
Knowing and understanding patterns will help you convey knowledge about implementation details to other developer in more efficient manner.
Like "this is Unit of Work" instead of "this object holds references to objects we act upon in this transaction and tracks their state so we can commit all changes at once".
Other than that, it is more important that you understand and follow SOLID and DDD principles to build successful domain models.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I want to start Agile practices in a team. I'm assuming the information is available for free online about how to specifically carry it out.
Online I can locate the manifesto, the alliances and corporations involved but where is the actual central guide or root instruction set about how to do it? (Maybe the practices themselves are more ethereal or subjective than I expect and it's found in multiple places?)
Edit to summarize solutions:
Agile is a concept so that's what's to be found online about it. However specific processes or methods of Agile development have been created like Scrum and Extreme programming to provide concrete solutions to teams who want to adopt Agile and reap its proposed benefits. Find the shoe (or method) that fits best. Maybe create it.
If looking for solutions online to implement Agile development in your organization or for your project, seek out the specific methods too and decide among them.
There are numerous Agile methods.
Not one. And nothing definitive on something like "Agile". That's like a definitive guide to "Honesty".
Read this for one Agile method that some folks like: http://www.controlchaos.com/old-site/Scrumo.htm
Alos, there are numerous non-Agile methods. They'll all have a form similar to this: http://en.wikipedia.org/wiki/Waterfall_model
I agree with S.Lott. There are lots of Agile methods, not the one Agile method per se. Likewise I wouldn't know any central guide which covers All You Ever Wanted to Know About Agile.
I would actually recommend a book here. The one I found gave a pretty good introduction into how to go agile was O'Reilly's "The Art of Agile Development". Mind you, yeah, it is a book and therefore costs money, but not so much that it wouldn't be worth it if you really want to learn something.
There's nothing like specifically carrying out Agile. It's a bunch of methods and ways that you can adapt (or choose not to adapt). Some of them are more important than others, specific methods (like Scrum) define a couple of must-follow rules, whereas you can just as well pick what you think works best for you and see how it turns out.
I would actually recommend starting at one point with a good definition of Agile (the one at Wikipedia seems fine, along with a list of Agile methods and practices) and reading up on all the methods and practices from there. There will be googling involved.
Here is a good resource to learn about Extreme Programming which is another agile methodology.
Here's a downloadable book by Henrik Kniberg on Scrum and XP from the Trenches which describes in detail how his team did Scrum. When we implemented Scrum it was useful to have an in-depth look at what another team had found effective.
There is no definitive resource for all agile methods - as there is so much diversity in the methods.
The people that came up with the word "agile" didn't actually have that much in common - so it's not as though there's an "international headquarters of agile"... ;-)
It depends which one you want to know about: Scrum or XP or Crystal or one of the other methods... some of them are quite different from each other...
For Extreme Programming - the original XP material (and many of the experts) wrote it up at http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap
Scrum: The Scrum Alliance is pretty much the definitive place for Scrum http://www.scrumalliance.org/
Crystal is by Alistair Cockburn so look for stuff by him. I don't know much about how to do crystal, but Google likes this: http://alistair.cockburn.us/Crystal+methodologies+main+foyer
Don't start out by reading a bunch of different methods you haven't tried out and mixing together the bits you like - a mistake that's far too common. That results in random chaos.
Best way to start:
Look at some agile methods
Pick the one you think is most practical to adopt in your circumstances.
Try doing it by the book for a while - say for at least a month.
After you've been doing it for a while, you can get the team together to run a retrospective to decide what to improve - or what to try instead.
Recommendation (assuming you don't have experienced help on hand)
Scrum is pretty easy to get going. You can set it up in about 2 days if you're familiar with the basics.
Maybe after you've done scrum for a while you can start phasing in more of the XP practices. In any case, scrum doesn't have anything to say about technical things like the code, testing or refactoring - so once you've got the scrum basics down, you could start rolling in some XP practices. I think Test-Driven Development is the first one to start with.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
So I find myself working for a few weeks in a small team of four, including me. Quite a change from my last job at a 300+ developer shop where I'd been part of the adoption of an agile methodology.
I've been sneakily introducing useful tools like a continuous integration server and am surreptitiously starting test-driven development.
What other agile project management and development practices are appropriate for the smaller shop?
Well, to me, your actual configuration is much more appropriated for Agile than a 300+ developer shop (not really sure how Agile was implemented there, I'd love to hear more about that as scaling to that size requires a very high level of maturity on Agile IMO).
So, my answer would actually be: starting with 4 people, all values and practices are appropriate and valuable. Actually, what Agile methodology did you adopt previously? What practices did you implement? What makes you think they wouldn't be appropriate?
PS: If I may, try to see beyond engineering practices, Agile is not (just) about that (this is especially true for Scrum). Practices such as Test Driven Development, Continuous Integration, etc are nice but they are just a mean, not an end. They won't suffice for a successful Agile implementation. Agile is a business oriented organizational pattern. In other words, technical stuff is not really the best starting point when implementing Scrum, you should start with organizational things.
IMHO all of the development practices are appropriate. In fact, for a long time an agile team was expected to be a small teams (5-9 people). There is an artile of infoq about it.
Also, because you have a small team both communication and collaboration will become easier, so the practices would work even better.
Focus on introducing practices that add the most value to the team.
As the team is small impact of the change will be highly visible, if you work with the team and show improvements then you can go back and add another one - again the one that add the most value to the team.
One of the most important thing is that the projects are approached with an agile mindset, adding tools & techniques in the context of long projects that can't adapt to change & are not highly tuned with the customer won't have the ultimate result that you should be aiming for.
Communal code-review whether or not everyone is on the same site
I think you may want to flip the question around; what agile methods would not be suitable because you are a small team. I am no expert in agile practices, but I can't really think of any that would not be appropriate because of your team size.