A class plays two roles in an OO program:
- It provides a container for behavior that's shared by many objects.
- It acts as an object factory, manufacturing new instances and ensuring they are initialized correctly.
...when I say encapsulation, I mean "the behavior of an object can only be affected through its API". Or to put it negatively, an object is not well encapsulated when its behavior can be affected without calling its API. Or another way to think about it is that a well encapsulated object draws a solid boundry or wall around itself, and ensures that all the code that changes its behavior is contained within the object itself.
We want to be careful with the distinction between “encapsulation” and “information hiding.” The terms are often used interchangeably but actually refer to two separate, and largely orthogonal, qualities:
Ensures that the behavior of an object can only be affected through its API. It lets us control how much a change to one object will impact other parts of the system by ensuring that there a
There's no general rule you can follow here, because it's always going to depend on context. In my experience the kind of feedback loops you create, and the kind of safety nets you need are defined entirely by the domain, the organization, and the team culture.
Here are a few examples:
Often times, this means doing a handful of 30 minute prototypes until the requirements settle, each of which would have taken me 2 hours if I drove them via TDD. When things finally cool down, I evaluate the complexity and maintainability of the resulting code and either leave it untested, add some acceptance tests, backfill unit tes
"There are a few things I look for that are good predictors of whether a project is in good shape. These are also properties I strive for in my own code.
Pressuring people to work harder, work longer hours, and take on an increased workload is not the way to increase velocity. It’s the way to start a death march. [...]
The way to reveal extra capacity and increase velocity is to relentlessly remove obstacles, eliminate waste and improve continuously. Help the team focus on the product, on quality, and to deliver only the functionality that adds value to the product and generates revenue. Keep the process simple and intuitive so that people don’t have to stop and think what the next step is. And protect peoples’ flow time by preventing interruptions. Help the team avoid creating inventory, i.e. functionality that is complete but cannot generate revenue because it is not deployed to the production environment. Quickly remove obstacles that are identified in the daily standups and minimize dependencies so the team doesn’t have to
Under what conditions (if at all) can Velocity be used as a productivity metric? and if if not, why not?
The "why not" is that velocity should be a tool used to get better at estimation and planning.
So some of the larger swings you see in a teams velocity - especially in a team new to agile - are due to them tweaking the various dials that help them get better at planning an estimating - for example:
(from SOLID Principles with Uncle Bob - Robert C. Martin - http://www.hanselminutes.com/145/solid-principles-with-uncle-bob-robert-c-martin)
Single Responsibility Principle, what does it mean? It means that a software module should have one reason to change, then that's what I call a responsibility, a reason to change.
So for example, take a payroll application, if there's an employee class in that payroll application, you could imagine that it might have methods for calculate pay or perhaps another method for print a report, perhaps another method in the employee object for save me to the database, and what's unfortunate about these three methods existing in the same class is that they have all three completely different reasons to change. The payroll, the calculate pay will change if the accountants decides on a new way of calculating pay. The report generator will change if the people who consume the reports want the format of the reports to change. The save function will change if the DBA's decid