what's a "Story"?
http://en.wikipedia.org/wiki/User_storyBasically it's a task, a piece of work that gives some value, be that adding some functionality or fixing some problem. Tends to be used as a part of
Scrum, the stories often forming the individual cards on the
Kanban board.
It's called a story because the focus is to be on the Who/What/Why and business value, not the technicalities of implementing it. That's an implementation detail and up to the programmers to figure out through the whole team looking into it and getting a rough idea during the bi-weekly iteration planning meeting (If it is felt by the team that a story is too big for whatever reason, it will be broken down into smaller more manageable stories at this point), and then figuring out the specific details as they work on it and undergo the Red-Green-Refactor (a concept in Test-Driven Development: Write failing test (Red), make test pass (Green), Tidy up code (Refactor, the most important step)).
The whole reason behind not designing the implementation up-front is that big design up front sucks. It produces overengineered and poorly conceived software. Much better to evolve the design through taking the time to do constant refactoring to keep it as clean as possible (For example this often involves making sure it follows the
SOLID principles, which are good rules of thumb for clean code).
Since clean code is easier to understand and extend the functionality of (when responsibilities are clearly separated and everything does one thing and has it's one purpose, the place for changes are obvious), this makes the system much easier to update and maintain in the long-term, gaining back that time investment in less bug fixing and less having to hunt around and figure out cumbersome code. This is also where test-driven development is useful, since if all code is tested by a combination of top-level "integration" tests and low level unit tests then you can be a lot more confident you haven't broke something and can code without fear and with instant feedback if something goes wrong.
...I seem to have gone off on a little tangent there, my apologies. I can ramble for awhile about the important of keeping code clean, and breaking down responsibilities. Heck, I'd argue that code should be thought of in terms of responsibilities. I define the inheritance of one class by another (note not interface) as a way for a class to duplicate and extent the responsibilities of another class. Hence why the majority of situations such inheritance is just plain bad and leads to poor code, since you want each class and function to have as few direct responsibilities as possible (namely: one).
...and there I go again xD
Author
Topic: if self.isCoder(): post() #Programming Thread (Read 882142 times)