sofware craftsmanship code complete
Post on 15-Dec-2014
1.247 Views
Preview:
DESCRIPTION
TRANSCRIPT
NEW PERSPECTIVE
Asher Barak
PART ONEne principle to rule them all
1920 - 2012
one of the founders of the cognitive psychology field
GEORGE A.
MILLER
THE
MAGICAL
NUMBER
±27
1930 - 2002
Dutch computer scientist
Edsger W.
Dijkstra
Go To Statement Considered Harmful
MANAGING
COMPLEXITY
Your #1 goal should be
ARISTOTLE
Geek philosopher
384 – 322 BCE
Essential
Accidental
vs
SOFTWARE COMPLEXITY
• Computers speak a binary language
• Computers are batch machines
• There is a wide gap between coding
and running software
• Computers are terrible with
concurrency
• Computers have physical limitations
• Computer software model a complex
world
Accid
entalEssential
ONE THING AT A TIME
CARE ABOUT LESS
• Do as little as possible
• Divide (& conquer)
• Hide the details - Work with layered abstractions
• Reduce the noise
LANGUAGE
FUNDAMENTALS
Class
Method
Procedural Code
Layer
Module
Class
USE INTERFACES• Do as little as possible
• Divide (And Conquer)
• Hide the details - Work with layered abstractions
• Reduce the noise
CODING PRACTICE
S
THINK OF YOUR AUDIENCE
(It’s not the compiler)
Always
NAME STUFF•With the right name
• In a standard way
•Methods – For what they do
• Functions – For what they return
• Classes – For what they represent
•Modules – For what they pack
USE CONVENTIONS
Any convention is better than no convention
Every convention is one less thing to think about
USE CONVENTIONS• Naming Conventions
•Method parameters conventions
• Resources placing conventions
• Documenting conventions
• Code layout conventions
•Meeting conventions
• Everything conventions
USE CONVENTIONS
Interface
Event Args
Constant Class
Local Variable Static Property
Instance Property
Exception
Istance
Class Variable
USE DESIGN PATTERNS• They represent a higher
abstraction over coding details
• They simplify communications in the team
• They are conceptual standard reusable units
TDD• Promotes better divisions
• Promotes better abstractions
• Promotes better documentation
• Promotes better personal character
• Restrains complexity
DESIGN BEST
PRACTICES
• Do as little as possible
• Divide (And Conquer)
• Hide the details - Work with layered abstractions
• Reduce the noise
• Do as little as possible
• Divide (And Conquer)
• Hide the details - Work with layered abstractions
• Reduce the noise
• Do as little as possible
• Divide (And Conquer)
• Hide the details - Work with layered abstractions
• Reduce the noise
• Do as little as possible
• Divide (And Conquer)
• Hide the details - Work with layered abstractions
• Reduce the noise
• Do as little as possible
• Divide (And Conquer)
• Hide the details - Work with layered abstractions
• Reduce the noise
• Do as little as possible
• Divide (And Conquer)
• Hide the details - Work with layered abstractions
• Reduce the noise
• Do as little as possible
• Divide (And Conquer)
• Hide the details - Work with layered abstractions
• Reduce the noise
• Do as little as possible
• Divide (And Conquer)
• Hide the details - Work with layered abstractions
• Reduce the noise
• Do as little as possible
• Divide (And Conquer)
• Hide the details - Work with layered abstractions
• Reduce the noise
• Do as little as possible
• Divide (And Conquer)
• Hide the details - Work with layered abstractions
• Reduce the noise
• Do as little as possible
• Divide (And Conquer)
• Hide the details - Work with layered abstractions
• Reduce the noise
• Do as little as possible
• Divide (And Conquer)
• Hide the details - Work with layered abstractions
• Reduce the noise
PART TWOMake it your own
PROGRAMMING IS DONE SOLO
Creating a culture requires communication
FACE THE TRUTH
Some people program
for the wrong reasons
ACTIVELY ENCOURAGE SOCIALIZINGPreferably of people who like
their job
TALK ABOUT THE
PROCESS
BE OPENLY EXCITED ABOUT
GOOD CRAFTSMANSHIP(With tears if
possible)
TALK ABOUT READABILITYIs it good for readability or is it bad?
TALK ABOUT ABSTRACTIONS
Try splitting discussion the way code is split
ACTIVELY ENCOURAGE MORE DESIGNThis is hardly ever a problem
ACTIVELY ENCOURAGE
DESIGN CONSULTING
Everyone ends up smarter
PUT PERFORMANCE &
EFFICIENCY SECOND
Maintainability first
PUT PERFORMANCE &
EFFICIENCY SECOND
•We are not good at anticipating resources issues
•We are not good at anticipating performance issues
• KISS until otherwise proven
HAVE EXPECTATIONS• Read (and understand) error messages
• Read (and understand) compiler warning
• Document and read documentation
• Know (and avoid) code smells (Keep a document)
TALK ABOUT CONVENTIONS• Keep a document
•Make newbie's read the document
• Discuss conventions with your team
•Make any code feel at home to everyone in the company
TALK ABOUT CODE• Code reviews
• Code analysis sessions
• Talk about code when you give advice
• Talk about code when you take a break – be creative
TALK ABOUT CODE• Talk about your experience
with the code
• This made me expect that…
• From this I understood right away that…
• This was misleading/ did not follow the standard/ was too long / short
DON’TTALK ABOUT
CODEWhen you cannot understand it
USE TOOLING• To measure (size, relations complexity etc.) – do not count lines
• To enforce quality standards and conventions
• To boost productivity
• To avoid human errors
MAKE SURE
EVERYONE READS CODE COMPLETE
PART THREETrade secrets
CULTURE CLASH
SW Business and SW craftsmanship
are not the same
THINGS ARE IMPROVING• Human factor weighs in
• AGILE – development as a partnership
• Costs and benefits of quality are better understood
• SW management is more experienced
STILL, THIS
Is sometimes applicable to the quality of your code
USE YOUR BRAIN• Say what you think
• Stick to your estimates
• Accept lower qualityas a legitimate business decision
• Pick your battles
• Keep doing what you lovein acceptable conditions
KEEP CALM !!!
THANK YOU,
972-54-8003775
Asher . Barak @ gmail . com
CONNECT WITH ME
GET THE SLIDEShttp://goo.gl/AWWUKf
If you want to reuse the slides for your talk, Please contact me first.
top related