Difference between revisions of "Code as a crime scene"
From CitconWiki
Jump to navigationJump to search| Line 7: | Line 7: | ||
[https://codescene.io/ Codescene.io] | [https://codescene.io/ Codescene.io] | ||
| + | |||
| + | ---- | ||
| + | Other notes: [[User:Robpark]] | ||
| + | |||
| + | * Unfortunately, no one had fully read the book or used the codescene.io app directly, but it was still a very interesting and useful discussion that only makes me want to finally get to reading the book. | ||
| + | * I had worked with a team that did use the app.. it fostered team communication IMO.. got everyone on the team to see the one file each was changing with most commits | ||
| + | ** [https://citconf.com/wiki/index.php?title=Daniel_Wellman Dan Wellman] is the guy to contact IMO | ||
| + | * There was a theme of what are the facts (vs opinions), meaning focusing on facts about your codebase can be a very useful exercise | ||
| + | * We discussed code complexity.. not many felt they found a lot of actionable value .. maybe combining with commit history would be more useful🤔 | ||
| + | * Code coverage — we all seemed to know how it can be used against us ( i.e. can be dangerous) — but what if you’ve been TDDing as much as possible maybe check coverage to see what you missed? | ||
| + | * 100% coverage is dumb... or is it? Most of us preferred a 100% green unit test suite (with 1 reasonable exception), so why not ignore things to keep your coverage “green” (at 100%)? | ||
Latest revision as of 17:19, 27 May 2019
Your Code as a Crime Scene
by Adam Tornhill
Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs
The book at pragmatic programmers
Other notes: User:Robpark
- Unfortunately, no one had fully read the book or used the codescene.io app directly, but it was still a very interesting and useful discussion that only makes me want to finally get to reading the book.
- I had worked with a team that did use the app.. it fostered team communication IMO.. got everyone on the team to see the one file each was changing with most commits
- Dan Wellman is the guy to contact IMO
- There was a theme of what are the facts (vs opinions), meaning focusing on facts about your codebase can be a very useful exercise
- We discussed code complexity.. not many felt they found a lot of actionable value .. maybe combining with commit history would be more useful🤔
- Code coverage — we all seemed to know how it can be used against us ( i.e. can be dangerous) — but what if you’ve been TDDing as much as possible maybe check coverage to see what you missed?
- 100% coverage is dumb... or is it? Most of us preferred a 100% green unit test suite (with 1 reasonable exception), so why not ignore things to keep your coverage “green” (at 100%)?
