Software development / Practices and philosophy
From WhyNotWiki
Closely related to: Software project management, Software development
Software development philosophy edit (Category edit)
Contents |
[edit] General
Source: Heshmati: Software Production Process Using Open Source Software
[edit] Agile development/extreme programming
XProgramming.com - an Agile Software Development Resource by Ronald E Jeffries
http://en.wikipedia.org/wiki/Agile_software_development
http://en.wikipedia.org/wiki/Iterative_development
http://en.wikipedia.org/wiki/Extreme_Programming
http://www.sourcextreme.org/index.php/Main_Page
http://www.martinfowler.com/articles/newMethodology.html
[edit] Planning / Requirements gathering and specification
Source: Heshmati: Software Production Process Using Open Source Software: Requirement Analysis and Specification section
Understanding business objectives is essential. [...] In this phase our engineers identify and document the exact requirement for the system. To establish the requirements clearly and precisely, we use Unified Modeling Language (UML) use cases to document the requirements. [...] This phase produces user manuals and system test plans. Where appropriate, a prototype is also prepared so that the client may verify the functional requirements.
Source: Heshmati: Software Production Process Using Open Source Software: Design and Specification section
Once the requirements for the system have been documented, our engineers design a software system to meet them. We split the design phase into two subphases: Architectural Design and Detailed Design. In the Architectural Design we deal with the overall module organization and structure whereas in the Detailed Design we refine the Architectural Design by designing each module in details. Again we use UML to specify Architectural Design Document (ADD) and Detailed Design Document (DDD).
[edit] Diagrams
Here's my advice for using diagrams well.
First keep in mind what you're drawing the diagrams for. The primary value is communication. Effective communication means selecting important things and neglecting the less important. This selectivity is the key to using the UML well. Don't draw every class - only the important ones. For each class, don't show every attribute and operation - only the important ones. Don't draw sequence diagrams for all use cases and scenarios - only... you get the picture. A common problem with the common use of diagrams is that people try to make them comprehensive. The code is the best source of comprehensive information, as the code is the easiest thing to keep in sync with the code. For diagrams, comprehensiveness is the enemy of comprehensibility.
| “ | The code is the best source of comprehensive information, as the code is the easiest thing to keep in sync with the code. | ” |
[edit] Test-driven development
Source: Heshmati: Software Production Process Using Open Source Software
Our programmers define and implement unit tests for every required feature of the system. These programmer tests, or unit tests, are put together, and every time any programmer release any code to the repository, these unit tests must run correctly. This help our programmers detect any possible side effects right away.
(See Continuous testing/Continuous integration)
Source: Heshmati: Software Production Process Using Open Source Software
All the modules that have been developed before (see section 3.4) and unit tested individually are put together in this phase and tested as a whole system. Tests are performed based on the system test plan produced in the Requirement Analysis phase (refer to section 3.2).
[edit] Story Tests
Error on call to Template:cite web: Parameter url must be specified.
Story tests are specific testable scenarios for a story. Story tests (kinda like acceptance tests) serve to clarify the end result for everyone involved. They can also clarify what will NOT work. During development, developers can use the tests to make sure they're really "done". After development, testers will use the story tests as the start of more formal acceptance testing.Writing story tests when you create the stories pushes the work of acceptance tests up front. Which actually makes sense. Should we decide how to accept this work before it starts or after it's done? Before is a recipe for happy developers and clear requirements. After is a recipe for re-doing work and unhappy customers.
http://industrialxp.org/storyTdd.html
OOPSLA'05—Storytest-Driven Development (http://www.oopsla.org/2005/ShowEvent.do?id=143).
Falling behind on writing your acceptance tests? This is a common problem. Either you don't have the right people to produce acceptance tests and/or you just never seem to have enough time to implement them. The result is a backlog of work and not enough coverage for the features in your system. The solution to this problem is called Storytest-Driven Development (SDD).This practice advocates you define storytests (automated acceptance criteria) for stories prior to implementing them. Writing the storytest aids both developers and customers in aligning their efforts. Storytests are textual descriptions of a test that are easy to read, modify and execute. Subject matter experts, analysts, testers and programmers produce tests collaboratively. Storytests may be automated using a variety of technologies, such as FIT, Ward Cunngingham's excellent Framework for Integrated Test. A key benefit of this practice is the design simplicity that flows out of starting all work with a failing storytest.
[edit] Why they're good: double-checks
http://martinfowler.com/bliki/SpecificationByExample.html :
An important property of TDD tests is that they involve a double-check. [...] Kent has pointed out that this double-check principle is a vital principle, and it's certainly one that humans use all the time. The value of the double check is very much tied into using different methods for each side of the double check. Combining Specification By Example with production code means that you have both things said quite differently, which increases their ability to find errors.
[edit] Zed Shaw
Zed Shaw says (http://www.oreillynet.com/ruby/blog/2006/05/post.html):
Pat Eyler: Recently, you’ve been putting a lot of work (beyond unit tests) into making Mongrels stable and secure. Would you explain your methodology and the tools you’re using to make it work?
Zed: I agree with the OpenBSD group’s assertion that security holes come from defects in general, not from some specific “security hole” that you look for in the source code. This means that I think if I fix all the defects I can find, and try to be proactive about potential errors then I’ll prevent a lot of security holes in the process.
With any of my projects I try desperately to do the following:
- Keep the code as incredibly simple as possible. I call this “The Shibumi School of Software Structure” because I like the letter ‘S’ and because it’s the exact inverse of what most programmers do when they structure software.
- Code reviews of my own code before releasing, constantly trying to find:
- “missed assertions” — Unstated assumptions about inputs and outputs.
- “missed else” — Logical branches that don’t cover all test domains.
- “will it stop” — Looping errors that will cause classic infinite loops or short loops.
- “check that return” — Return values that aren’t dealt with properly (which are really assumptions about other inputs and outputs).
- “unexpected exceptions” — Exceptions are pretty darn evil since they’re rarely documented.
- “simply readable” — Replacing clever code with readable simple code where possible, and documenting complex code so it can be reviewed by others.
- Unit testing as much as possible. [...]
- [...]
- Usability reviews from potential or current users. My motto here is “If I KMU (Know My Users) they won’t have to RTM [Read The Manual].” I really think if a system is easy to use then the security concerns are lower, but I don’t have much evidence to support this claim.
[edit] David Heinemeier Hansson: Frameworks are not designed before the fact
Ruby on Rails: An Interview with David Heinemeier Hansson, 2005-08-30:
ED: One of the things I like about Rails is the differentiation between production and development environments. Those kind of features don't normally come built in with scripting language web tools. Did you consciously set out to provide some "enterprise" features in Rails?
DHH: I set out to serve me. Rails is a very selfish project in that respect. It gained a lot of its focus and appeal because I didn't try to please people who didn't share my problems. Differentiating between production and development was a very real problem for me, so I solved it the best way I knew how.
It's hard enough to solve your own problems with eloquence. Trying to solve other people's problems is damn near impossible—at least to do so to the level of satisfaction that would make me interested in the solution.
That's why we hold the notion that "frameworks are extractions" so very dear in the Rails community. Frameworks are not designed before the fact. They're extracted when you've proved to yourself that an approach works. Whenever we get ahead of ourselves and try to leap over the extraction process, we come back sorely disappointed.
I believe that's why Rails just feels right for so many people—because it's been used by real people for real work before we dished it out for others to reuse.
[edit] You can only take reusability so far!
Small, low-level chunks of code/algorithms can be turned into reusable components.
But once you start getting up into business logic (higher-level logic), you're not going to be able to make that code very reusable (perhaps you could within your organization or whatever, but it's not going to be general enough for the whole world to reuse).
I'm not explaining this very well.
http://www.loudthinking.com/arc/000335.html The recurring misguided desire for components (Loud Thinking):
Neil Weber seems to think that the world of tomorrow will be one where we shop for finished components, sprinkle them with business-specific attributes, and off we go with a done system in no time at all. This future has had industry-wide fascination since the beginning of time. I believe it is a false hope
...
But to think that we can reduce the problem space for information systems in general, to make it fit our existing components, is where I spot the disconnect. When I think back on the systems I've done, I can't come up with many good candidates for classes I could have carried all the way through and merely configured.
At least not on the business level. Rails is a great example of how infrastructure, that which is below our domain models, can and should be standardized. But design decisions can not follow this road.
...
This sums up my vision for Rails as well. The border at which new functionality is accepted or rejected lies at the brink of the business domain. I don't believe that user management, access control, discussion boards, or Bill of Materials classes make for good component candidates.
http://www.loudthinking.com/arc/000407.html The case against high-level components (Loud Thinking):
...
On the surface, the dream of components sounds great and cursory overviews of new projects also appear to be "a perfect fit". But they never are. Reuse is hard. Parameterized reuse is even harder. And in the end, you're left with all the complexity of a swiss army knife that does everything for no one at great cost and pain.
...
