Software Archaeology For Beginners – Code, Community and Culture



Software Archaeology For Beginners – Code, Community and Culture

0 1


software-architecture

Software Archaeology for Beginners

On Github jamtur01 / software-architecture

Software Archaeology For Beginners

Code, Community and Culture

James Turnbull

@kartar

who

  • engineer and operations chap
  • open source chap
  • funny accent
(photo by Jennie Rainsford)

other matters

authorhttp://www.jamesturnbull.net

hack-n-slash developerhttps://github.com/jamtur01

pontificationhttp://www.kartar.net

The LogStash Book

www.logstashbook.com

The Docker Book

www.dockerbook.com

Who are you?

Why?

Three themes

A bit of culture

Some things about community

Quite a lot about code, documentation and tests

But I thought this talk was just technical?

Or ... Why do I give a crap about culture and community?

Culture

What's culture?

Why is culture important?

Read & Listen

Patience is a virtue

Community

Communication

Use the mechanisms the project use

Ask questions

Over-share

Be polite, be upbeat

Collaboration

Earn trust through little steps

But it's broken!

You catch more flies with honey

Code, Documentation and Tests

What is Software Archaeology?

The fine art of software dumpster diving

Documentation

Visualization

Testing & Truth

Design & Style

Performance

Explain I am going to use Puppet and Docker as examples

Read all the documentation

Run all the documentation

(Re-)Write documentation

Tell the story of starting with Puppet and emailing Luke every 10 minutes

Is there a design?

Draw pictures and write down the story

Build a development environment

And yes document it.

Run the tests

Fix the broken tests

You fixed the tests?

What do the tests cover?

# go test -cover
PASS
coverage: 9.7% of statements
ok    github.com/dotcloud/docker  0.444s

Wow do we suck

Write new tests

Tests as documentation

Run Metrics

Style violations help complete the picture of the inherited code. Many developers argue that static code audits should be run first, and this is true from a new project perspective. However, when inheriting massive amounts of code, running metrics first usually gives more object health-based information. Once the health of the object design is determined and can point to various areas of the code that need significant work, the audits can further refine that knowledge.

Metrics reveal

Code smells

Troubled subsystems

All good places to start coding

Style & Linting

# go tool vet .
commands.go:567: arg s for printf verb %d of wrong type: os.Signal
engine/streams_test.go:168: arg expectedOutput for printf verb %d of wrong type: []string
engine/streams_test.go:228: possible formatting directive in Fatal call
graphdriver/aufs/aufs_test.go:389: arg change.Kind for printf verb %s of wrong type: github.com/dotcloud/docker/archive.ChangeType
graphdriver/aufs/aufs_test.go:429: arg change.Kind for printf verb %s of wrong type: github.com/dotcloud/docker/archive.ChangeType
graphdriver/devmapper/deviceset.go:35: struct field tag `json:devices` not compatible with reflect.StructTag.Get

Profiling

# go tool pprof api api.prof
Welcome to pprof!  For help, type 'help'.
(pprof) top10
Total: 2525 samples
298  11.8%  11.8%      345  13.7% runtime.mapaccess1_fast64
268  10.6%  22.4%     2124  84.1% main.FindLoops
251   9.9%  32.4%      451  17.9% scanblock
178   7.0%  39.4%      351  13.9% hash_insert
. . .

Performance problems are often tied to code smells

So what have we learnt?

Understand all of culture, community and code

Little things can have big impacts

Leave things better than you found them.

Questions?

references