FINDING TOXIC CODE Experiences and techniques for finding dangerous - - PowerPoint PPT Presentation

finding toxic code
SMART_READER_LITE
LIVE PREVIEW

FINDING TOXIC CODE Experiences and techniques for finding dangerous - - PowerPoint PPT Presentation

FINDING TOXIC CODE Experiences and techniques for finding dangerous code in large multi-language codebases Kornelis (Korny) Sietsma - @kornys on Twitter WHO AM I? 2 WHAT DO I DO NOW? Consulting, Delivery, Agile, Technical excellence And the


slide-1
SLIDE 1

FINDING TOXIC CODE

Experiences and techniques for finding dangerous code in large multi-language codebases Kornelis (Korny) Sietsma - @kornys on Twitter

slide-2
SLIDE 2

WHO AM I?

2

slide-3
SLIDE 3

WHAT DO I DO NOW?

3

Consulting, Delivery, Agile, Technical excellence And the occasional “Help us work out what is going wrong” project.

slide-4
SLIDE 4

A FISHY STORY

This story is true. Only the facts have been changed to protect the innocent.

4

slide-5
SLIDE 5

FISHCORP HAD A PROBLEM

5

Old “FishNet” system – ugly and hard to change. New dev manager – Mr Squid; New system: “SquidNet” – very pretty, but very very buggy, late to ship, and getting later. “Can you help us work out what is going wrong?”

slide-6
SLIDE 6

YOU HAVE TWO WEEKS

6

  • Workshops
  • Whiteboard sessions
  • Process mapping
  • 1 million lines of code!
  • How do we quickly review 1 million lines of code?
  • C++, C#, JS, SQL stored procedures…
slide-7
SLIDE 7

”TOXIC” CODE - ERIK DÖRNENBURG BLOG 2008

7

https://erik.doernenburg.com/2008/11/how-toxic-is-your-code/

slide-8
SLIDE 8

CODECITY

Looks ideal: But…

8

slide-9
SLIDE 9

GRAVEYARD OF TOOLS

CodeCrawler: Panopticode: Moose Technology:

9

slide-10
SLIDE 10

WHAT ABOUT SONARQUBE?

10

slide-11
SLIDE 11

HOW ABOUT REALLY LIGHTWEIGHT TOOLS?

Something quick, simple, cross-language, works with just source code. What about CLOC?

11

slide-12
SLIDE 12

12

slide-13
SLIDE 13

13

slide-14
SLIDE 14

ARCHITECTURE

14

FishNet SquidNet

Batch + Optimisation Fishing DB Web API Data Warehouse Batch Tasks Squid DB UI - AngularJS, CSS, HTML, custom JS UI - HTML, CSS, JS, ASPX, C# Mobile “Business Logic” C# Stored Procedures Data Data Stored Procedures

Component Component Component Component Component Component Component Component

ETL SQL Reporting

slide-15
SLIDE 15

HOW BIG IS TOO BIG?

“Simply stated, an object should be no bigger than the size of my head when pressed up against the monitor – basically a screenful of code.”

  • James Lewis (@boicy)

15

http://bovon.org/archives/350

slide-16
SLIDE 16

Si Simple cross-lan languag age e code

  • de smell

ell 1: To Too m many l lines o

  • f c

code

16

slide-17
SLIDE 17

(LINES OF CODE - BETTER VIEWED IN THE APP!)

17

slide-18
SLIDE 18

CODE-MAAT – SCM-BASED INFORMATION

  • Ownership and Authors
  • Code age
  • (Logical coupling)
  • (Code churn)
  • … and more

18

https://github.com/adamtornhill/code-maat

slide-19
SLIDE 19

Si Simple cross-lan languag age e code

  • de smell

ell 2: To Too f few a authors

19

slide-20
SLIDE 20

AUTHORS – BETTER VIEWED IN THE APP

20

slide-21
SLIDE 21

Si Simple cross-lan languag age e code

  • de smell

ell 3: To Too l little c change

21

slide-22
SLIDE 22

OPINIONS MAY DIFFER!

  • Living code tends to change – people use it, they find

refactorings, they make changes.

  • Static unchanging code might be perfect – or it might contain

lurking undiscovered bugs. Either way, over time, collective knowledge drops to zero.

  • If it is static because it is perfect, it should be extracted out

into a standalone library, with a lot of automated tests.

22

slide-23
SLIDE 23

AGE – BETTER SHOWN IN THE APP

23

slide-24
SLIDE 24

HOW ABOUT IDENTIFYING COMPLEXITY?

24

slide-25
SLIDE 25

Si Simple cross-lan languag age e code

  • de smell

ell 4: Using code indentation as a proxy xy for complexi xity

25

slide-26
SLIDE 26

26

slide-27
SLIDE 27

HOW DO OTHER PROJECTS LOOK?

Verify– microservices in Java, Ruby, Python Linux – large C codebase Kubernetes – mostly Go MongoDB – C++, C, Go, JavaScript VSCode – TypeScript, JavaScript

27

slide-28
SLIDE 28

OTHER AREAS TO EXPLORE

Test quality – “temporal coupling” can detect it, but hard to use reliably. Also bad tests can look better than good tests. Duplication! Can be spotted by hand, but tooling would be nice. Deployment data – e.g. release timings, time between development and production.

28

slide-29
SLIDE 29

RELEASE TIME - DETAILS

29

slide-30
SLIDE 30

RELEASE TIME – LONG TERM TRENDS

30

slide-31
SLIDE 31

WHAT DID WE TELL FISHCORP?

  • Your old code is complex, badly tested, mostly
  • nly understood by 1 or 2 people
  • Your new code is even worse - complex, full of

duplication, badly tested, and still tightly coupled to your old code.

  • You need to move away from giant databases

and ETL jobs

  • You need to build something new.

31

slide-32
SLIDE 32

THANK YOU!

QUESTIONS?

Simple code smell summary:

  • Classes/Files too large
  • Too few authors
  • Too little change
  • Too much complexity (via indentation)

Co Code will (eventu tually) be at t gi github.com/ko kornysietsma Tw Twitter: @ko kornys Em Email: ko korny@thoughtworks.com

slide-33
SLIDE 33

IMAGE CREDITS

Fanfold Paper – Arnold Reinhold (via WikiMedia) HP-85 computer – Wolfgang Stief (via WikiMedia) James Lewis’ Head - @boicy on Twitter Your Code as a Crime Scene cover – Pragmatic Programmers

33