Showing posts with label coding standards. Show all posts
Showing posts with label coding standards. Show all posts

Tuesday, May 13, 2014

Agile in a Flash 40

Agile in a Flash by Jeff Langr and Tim Ottinger (card #40)

> Continuous integration (CI)
> Test-Driven Development (TDD)
> Constant design improvement
> Coding standard
> Collective code ownership
> Simple design
> System metaphor
> Pair programming

--

Agile programmers use these eight practices that derive from Extreme Programming (see Extreme Programming Explained, First Edition) to improve their software development practice. The practices can work individually but have a profound synergy when used together.

A coding standard (see Card 35, Coding Standards) is foundational for working as a team that collectively owns the code. Continuous integration ensures the system is always in working order. You know the system works because it has been built by pairs of programmers reviewing the other person’s work and using TDD (plus automated acceptance tests) to verify that it works. You know the system has a quality design, because the programmers use TDD to continually improve the design (refactor) using simple design concepts.

You communicate these system ideas with your whole team—which includes the business and other nontechnical folks—through use of a metaphor. A metaphor is a shared system vision and language that simplifies decision making and reduces the need for deep-code spelunking. The shopping cart is a common metaphor; you talk about “carts, items, and checkout.” You might end up with what’s
known as the naïve metaphor: “This is a purchasing system, with orders, inventory items, and submissions.” Boring but effective enough!


"Don't practice until you get it right. Practice until you can't get it wrong.” - Unknown

Friday, May 2, 2014

Agile in a Flash 34

Agile in a Flash by Jeff Langr and Tim Ottinger (card #34)

> Anyone can modify any code at any time
> The team adheres to a single style guide
> Original authorship is immaterial
> Abundant automated tests create confidence
> Version control provides insurance
--

Anyone can modify any code at any time. You may improve any section of the code without wasting time seeking permission. You’re not a cubed individual piling up a code fiefdom, but part of a team collaborating on a deeply connected system.
The team adheres to a single style guide. The points in Card 35, Coding Standards, reduce the wasteful friction of learning a new standard when working elsewhere in the system. A common style guide lets you spend time solving problems that matter. Your IDE might be able to help here.
Original authorship is immaterial. Personal attachment to “your” code provides no additional value when your team all strives toward the same goal of high quality code. Lose the pride over code you just created, substituting enthusiasm for figuring out how to make it even better.
Abundant automated tests create confidence. TDD provides abundant tests that both declare and protect the original programmer’s intent, giving you the freedom to refactor with impunity.

Version control provides insurance. The use of a good version control system means you can return to a previous (working, tested) version of the system, making code experiments affordable.