Designing Beautiful Software


The Presentation inside:

Slide 0

KEEPING SOFTWARE DEVELOPMENT ECOSYSTEM HEALTHY Dainius Mežanskas © 2015 Software Architect @ Intermedix Corp. www.agileturas.lt/kaunas intermedix.com kaunas-jug.lt [email protected]


Slide 1

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


Slide 2

Software DESIGN DESIGN TEAM T-DEBT DEMO


Slide 3

CODE DESIGN ARCHITECTURE


Slide 4

DESIGN ...is important! why? because of –ilities!


Slide 5

-ilities attributes system quality MAINTAINABILITY TESTABILITY EXTENSIBILITY RELIABILITY SECURITY SCALABILITY USABILITY VULNERABILITY ... and several dozens more


Slide 6

-ilitiesAll? ACCESSIBILITY ACCOUNTABILITY ACCURACY ADAPTABILITY ADMINISTRABILITY AFFORDABILITY AGILITY AUDITABILITY AUTONOMY AVAILABILITY COMPATIBILITY COMPOSABILITY CONFIGURABILITY CORRECTNESS CREDIBILITY CUSTOMIZABILITY DEBUGABILITY DEGRADABILITY DETERMINABILITY DEMONSTRABILITY DEPENDABILITY DEPLOYABILITY DISCOVERABILITY DISTRIBUTABILITY DURABILITY EFFECTIVENESS EFFICIENCY EVOLVABILITY EXTENSIBILITY FAILURE TRANSPARENCY FAULT-­TOLERANCE FIDELITY FLEXIBILITY INSPECTABILITY INSTALLABILITY INTEGRITY INTERCHANGEABILITY INTEROPERABILITY LEARNABILITY MAINTAINABILITY MANAGEABILITY MOBILITY MODIFIABILITY MODULARITY OPERABILITY ORTHOGONALITY PORTABILITY PRECISION PREDICTABILITY PROCESS CAPABILITIES PRODUCIBILITY PROVABILITY RECOVERABILITY RELEVANCE RELIABILITY REPEATABILITY REPRODUCIBILITY RESILIENCE RESPONSIVENESS REUSABILITY ROBUSTNESS SAFETY SCALABILITY SEAMLESSNESS SELF-­SUSTAINABILITY SERVICEABILITY SECURABILITY SIMPLICITY STABILITY STANDARDS COMPLIANCE SURVIVABILITY SUSTAINABILITY TAILORABILITY TESTABILITY TIMELINESS TRACEABILITY UBIQUITY UNDERSTANDABILITY UPGRADABILITY USABILITY https://en.wikipedia.org/wiki/List_of_system_quality_attributes


Slide 7

CONTINUOUS  ATTENTION  TO   TECHNICAL  EXCELLENCE  AND  GOOD   DESIGN ENHANCES  AGILITY


Slide 8

Especially for... WHEN § § § § § ? DESIGN IS IMPORTANT LARGE CODE BASE LONG LIVING PRODUCTS DISTRIBUTED | BIG TEAMS HIGH PRICE OF FAILURE HIGH THROUGHPUT


Slide 9

DESIGN to applies § PRODUCTION CODE § TESTS § BUILDS | DEPLOYMENT | AUTOMATION § TOOLS § UX § PROCESSES


Slide 10

WHO FOR IS RESPONSIBLE DESIGN and quality ?


Slide 11

DESIGN TEAM IS A RESPONSIBILITY ...and every member should be responsible


Slide 12

DEFINE IMPROVE FOLLOW REVIEW


Slide 13

TEAM IMPROVEMENT ü TECHNICAL VIDEOS ü SELF-IMPROVEMENT SESSIONS ü CROSS-TEAM COMMUNICATIONS ü OFFICE LIBRARY


Slide 14

PAIRING üSTART WITH PAIRING ...and define guidelines üRETURN TO PAIRING ...if there are new ideas or challenges üREVIEW RESULTS IN PAIR ...in case task were complex


Slide 15

GITFLOW WORKFLOW PULL REQUESTSPAIRING OFFLINE ...it is like 2 MEMBERS TO APPROVE TWO HEADS ARE BETTER THAN ONE ...are four even better?


Slide 16

WORKING CODE CHUNKS ...fully of partially functional … in separate repo DESIGN PROTOTYPE POC ...discuss with team a.k.a. proof of concept


Slide 17

EXAMPLARS PRODUCTION READY ARTIFACTS ...reusable examples CREATED FROM SCRATCH ... or pre-generated


Slide 18

STATIC CODE ANALYSIS CODING RULES ARCHITECTURE DUPLICATIONS & DESIGN POTENTIAL BUGS COMPLEXITY COMMENTS


Slide 19

sonarqube § MULTIPLE LANGUAGES § CROSS-TEAM RULES § TIME MACHINE § CODE COVERAGE § IDE PLUGIN § 60+ PLUGINS


Slide 20


Slide 21

sonarqube INFORMATION RADIATOR


Slide 22

TECHNICAL DEBT


Slide 23

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.


Slide 24

TECHNICAL DEBT REASONS LACK OF ✓ BUSINESS PRESSURE ✗ ✗ ✗ ✗ PROCESS, KNOWLEDGE or COLLABORATION ALIGNMENT TO STANDARDS TEST SUITE, DOCUMENTATION LOOSELY COUPLED COMPONENTS ✓ PARALLEL DEVELOPMENT ✓ DELAYED REFACTORING


Slide 25

TNECHAICL § § § § § SMYTOPMS POSTPONED RELEASES CONSTANT HOT FIXES BEING SCARED ON CHANGING ANYTHING LOW CODE COVERAGE UNREDABLE CODE, EVIL HACKS ... what are your TD symptoms?


Slide 26

REMOVING TECHNICAL DEBT § CLEAN CONSTANTLY (10%+) § ATTACK NEXT T.D. of P 1 § DEFINE OUTCOMES § EVALUATE CHANGES § CLEANUP RELEASES


Slide 27

INJECTION PROPERTY vs. CONSTRUCTOR INJECTION


Slide 28


Slide 29


Slide 30

CONSTRUCTOR DI § BETTER TESTABILITY § ALL DEPENDENCIES VISIBLE IN ONE PLACE § ENCAPSULATION IS PRESERVED § TOO MANY DEPENDENCIES - SRP IS BROKEN?


Slide 31

LAST ...but not least 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 “ “ “ “


Slide 32

Q&A THANK YOU Dainius Mežanskas © 2015 Software Architect @ Intermedix Corp. www.agileturas.lt/kaunas intermedix.com kaunas-jug.lt [email protected]


Slide 33


×

HTML:





Ссылка: