Date post: | 06-Jan-2017 |
Category: |
Leadership & Management |
Upload: | agile-lietuva |
View: | 282 times |
Download: | 0 times |
HEALTHY
KEEPING
SOFTWAREDEVELOPMENT
ECOSYSTEM
Dainius Mežanskas © 2015Software Architect @ Intermedix Corp.
[email protected] www.agileturas.lt/kaunas intermedix.com kaunas-jug.lt
DAINIUS MEŽANSKAS
§ Telecommunications, E-commerce, Health Care,Insurance, E-learning (17+ years)
§ Developer, Architect, Team Lead, IT Trainer
§ Software Architect at Intermedix Corp.§ Co-Founder and Leader of Kaunas JUG
DESIGNSoftware
TEAMT-DEBT
DEMO
DESIGN
CODE
DESIGN
ARCHITECTURE
because of –ilities!
DESIGN...is important!why?
MAINTAINABILITY SECURITYTESTABILITY SCALABILITYEXTENSIBILITY USABILITYRELIABILITY VULNERABILITY
-ilities
... and several dozens more
system quality attributes
-ilitiesACCESSIBILITY ACCOUNTABILITY ACCURACY ADAPTABILITYADMINISTRABILITY AFFORDABILITY AGILITY AUDITABILITY AUTONOMYAVAILABILITY COMPATIBILITY COMPOSABILITY CONFIGURABILITYCORRECTNESS CREDIBILITY CUSTOMIZABILITY DEBUGABILITYDEGRADABILITY DETERMINABILITY DEMONSTRABILITY DEPENDABILITYDEPLOYABILITY DISCOVERABILITY DISTRIBUTABILITY DURABILITYEFFECTIVENESS EFFICIENCY EVOLVABILITY EXTENSIBILITY FAILURETRANSPARENCY FAULT-TOLERANCE FIDELITY FLEXIBILITY INSPECTABILITYINSTALLABILITY INTEGRITY INTERCHANGEABILITY INTEROPERABILITYLEARNABILITY MAINTAINABILITY MANAGEABILITY MOBILITY MODIFIABILITYMODULARITY OPERABILITY ORTHOGONALITY PORTABILITY PRECISIONPREDICTABILITY PROCESS CAPABILITIES PRODUCIBILITY PROVABILITYRECOVERABILITY RELEVANCE RELIABILITY REPEATABILITY REPRODUCIBILITYRESILIENCE RESPONSIVENESS REUSABILITY ROBUSTNESS SAFETYSCALABILITY SEAMLESSNESS SELF-SUSTAINABILITY SERVICEABILITYSECURABILITY SIMPLICITY STABILITY STANDARDS COMPLIANCESURVIVABILITY SUSTAINABILITY TAILORABILITY TESTABILITY TIMELINESSTRACEABILITY UBIQUITY UNDERSTANDABILITY UPGRADABILITY USABILITY
All?
https://en.wikipedia.org/wiki/List_of_system_quality_attributes
CONTINUOUS ATTENTION TO
TECHNICAL EXCELLENCE AND GOOD DESIGN ENHANCES AGILITY
WHEN
§ LARGE CODE BASE
§ LONG LIVING PRODUCTS
§ DISTRIBUTED | BIG TEAMS
§ HIGH PRICE OF FAILURE
§ HIGH THROUGHPUT
DESIGNIS IMPORTANT?
Espe
cially
for..
.
§ PRODUCTION CODE
§ TESTS
§ BUILDS | DEPLOYMENT | AUTOMATION
§ TOOLS
§ UX
§ PROCESSES
DESIGNapplies to
WHOISRESPONSIBLE
FOR DESIGN?and quality
IS
RESPONSIBILITYTEAM
DESIGN
...and every member should be responsible
A
DEFINE
FOLLOW
REVIEW
IMPROVE
TEAM
ü TECHNICAL VIDEOS
ü SELF-IMPROVEMENT SESSIONS
ü CROSS-TEAM COMMUNICATIONS
ü OFFICE LIBRARY
IMPROVEMENT
PAIRINGüSTART WITH PAIRING
...and define guidelines
üREVIEW RESULTS IN PAIR...in case task were complex
üRETURN TO PAIRING...if there are new ideas or challenges
GITFLOW
2 MEMBERS TO APPROVE
WORKFLOW
OFFLINE PAIRINGPULL REQUESTS
TWO HEADS ARE BETTER THAN ONE
...it is like
...are four even better?
POC
WORKING CODE CHUNKS
… in separate repo ...fully of partially functional
...discuss with teamDESIGN PROTOTYPE
a.k.a. proof of concept
EXAMPLARSPRODUCTION
READY ARTIFACTS
CREATED FROM SCRATCH
...reusable examples
... or pre-generated
ARCHITECTURE
& DESIGN
POTENTIAL BUGS
COMPLEXITY
DUPLICATIONS
CODING RULES
COMMENTS
STATICCODE ANALYSIS
§ MULTIPLE LANGUAGES
§ RULE SETS INHERITANCE
§ CROSS-TEAM RULES
§ TIME MACHINE
§ CODE COVERAGE
§ IDE PLUGIN
§ 60+ PLUGINS
son
arqu
be
INFORMATION RADIATORsonarqube
DEBTTECHNICAL
TECHNICAL DEBT IS A METAPHOR
THAT REFLECTS THE EXTRA
DEVELOPMENT WORK THAT ARISES
WHEN THINGS ARE DONE QUICKLY
AND DIRTY.
The term was coined by Ward Cunningham in 1992.
REASONS✓ BUSINESS PRESSURE
LACK
OF ✗ PROCESS, KNOWLEDGE or COLLABORATION
✗ ALIGNMENT TO STANDARDS
✗ TEST SUITE, DOCUMENTATION
✗ LOOSELY COUPLED COMPONENTS
✓ PARALLEL DEVELOPMENT✓ DELAYED REFACTORING
TECHNICAL DEBT
§ POSTPONED RELEASES
§ CONSTANT HOT FIXES
§ BEING SCARED ON CHANGING ANYTHING
§ LOW CODE COVERAGE
§ UNREDABLE CODE, EVIL HACKS
... what are your TD symptoms?
SMYTOPMSTNECHAICL
§ CLEAN CONSTANTLY (10%+)
§ ATTACK NEXT T.D.
§ DEFINE OUTCOMES
§ EVALUATE CHANGES
§ CLEANUP RELEASES
REMOVINGTECHNICAL DEBT
of P 1
PROPERTY
vs.INJECTION
CONSTRUCTORINJECTION
Property Injection
Constructor Injection
§ BETTER TESTABILITY
§ ALL DEPENDENCIES VISIBLE IN ONE PLACE
§ ENCAPSULATION IS PRESERVED
§ TOO MANY DEPENDENCIES - SRP IS BROKEN?
CONSTRUCTOR DI
“
Prediction is very difficult, especially if it's about the future.— Niels Bohr “
Great software is not built, it is grown.— Bill de hÓra“
There is nothing noble in being superior to your fellow man; true nobility is being superior to your former self.
— Ernest Hemingway
“
Stay clean, stay agile. Encourage others.— Internet wisdom
LAST...but not least
THANK YOU
Q&ADainius Mežanskas © 2015
Software Architect @ Intermedix Corp.
[email protected] www.agileturas.lt/kaunas intermedix.com kaunas-jug.lt
REFERENCES
• http://www.agilemanifesto.org/principles.html• https://en.wikipedia.org/wiki/List_of_system_quality_attributes• https://en.wikipedia.org/wiki/Technical_debt
• http://www.slideshare.net/lemiorhan/technical-debt-do-not-underestimate-the-danger?related=1• http://www.slideshare.net/zazworka/identifying-and-managing-technical-debt