Clean application development tutorial

Adam Culp @adamculp
https://joind.in/14892
Clean Application Development

2
Clean Application Development – About me
● About me
●
PHP 5.3 Certified
●
Consultant at Zend Technologies
●
Organizer of SoFloPHP (South Florida)
●
Organizer of SunshinePHP (Miami)
●
Long distance (ultramarathon) runner
●
Judo black belt instructor

3
● HUGE fan of iteration
●
Skills require iteration to do well:
●
Learning to walk.
●
Training to run.
●
Evading project managers.
●
Writing clean code.
●
Refactoring.
●
Testing.
Clean Application Development – Iteration

4
● Clean application development cannot be taught quickly.
●
Practice, Practice, Practice.
●
Leave the code better than you found it.
●
Always watch for new techniques.
●
Want to do better.
●
No “silver bullet“.
●
Oh, and practice.
Clean Application Development – Learning

5
● Parts of clean application development.
●
Communication
●
Documentation
●
Source Control
●
Workflow
●
Time Estimation
●
Requirements Gathering
●
Issue Tracking
●
Time Management
●
Dev Tools
●
Databases
●
Code
●
Refactoring
●
Testing
●
Continuous Integration
Clean Application Development – Parts

6
Clean Application Development – Communication
Communication

7
● Team Commication Policy:
●
Should be agreed upon by team.
●
Should be clear.
●
Should be expected.
●
Should be enforced.
Clean Application Development – Comm. Policy

8
● Communication Levels
●
Instant (5 minutes to 1 hour)
●
Instant Messages (Skype, AOL)
●
Chat (IRC)
●
Intermediate (2 to 4 hours)
●
Phone Call, text message
●
Voicemail
●
Slow (6 to 8 hours)
●
Email
●
Issue Tracking
●
Casual (days)
●
Forum
●
Meeting
Clean Application Development – Comm. Levels

9
● Desired behaviour
●
Openly discuss problems.
●
Alert early.
●
Share information.
●
Be on time for meetings.
●
Attention!
●
Bad behaviour
●
Hiding.
●
Hoarding info.
●
Bringing attitude to meetings.
●
Interrupting others.
Clean Application Development – Behavior

10
Clean Application Development – Documentation
Documentation

11
● Document EVERYTHING!
●
Write down everything.
●
You WILL want it later.
●
Meeting notes.
●
Architecture decisions.
●
Changes in design.
●
Business logic.
●
Everything!
Clean Application Development – Doc. Practices

12
● How to document.
●
Meeting notes, architecture decisions, design changes, business logic.
●
Keep a notebook. Never throw pages away again.
●
Composition Book.
●
Evernote/Google keep.
●
In code.
●
Class Docblocks: business logic description.
●
Wiki.
●
Ticket System.
●
Source control comments.
●
PHP Documentor.
●
White papers.
●
Everywhere!
Clean Application Development – Doc. How

13
Clean Application Development – Requirements
Requirements

14
● What are requirements:
●
End-user dreams.
●
Business owners vision.
●
Expected behaviour of application.
●
Application reaction to business logic.
●
Specific needs.
Clean Application Development – What are they

15
● User story format works well.
●
Create roles of potential users.
●
Create persona of target user.
●
Create goals of what is desired.
●
Create benefit that goals help obtain.
●
Now create a story to make it real.
●
Insist on specificity!
Clean Application Development – How to create

16
● Key things about requirements:
●
Do not start coding without them.
●
Hold their hand to get them started.
●
Even if the project is your own.
●
Use a tool to organize them.
●
Reqharbor.com
●
Get sign-off from stakeholder.
●
No sign-off = scope creep later
Clean Application Development – Req. = Important

17
Clean Application Development – Time Estimating
Time Estimating

18
● Guessing, then multiplying by 2 or 3 is WRONG!
●
Sometimes accurate, but still a guess.
●
What if guess is wrong?
Clean Application Development – Wrong way!

19
● Guessing is wrong because:
●
Still a guess.
●
Lacks requirements.
●
If requirements are completed, why guess?
●
Welcomes scope creep.
●
Application lacks design.
●
Causes bad practices:
●
Shortcut tests.
●
Increases code smells.
●
Prevents honest answers later.
●
How's it going????
Clean Application Development – Why is it wrong?

20
● A better way:
●
Gather requirements.
●
Plan application.
●
How many controllers * average hours per.
●
How many actions in each * average hours per.
●
How many models/entities * average hours per.
●
Include meetings.
●
15 minutes per day (daily scrum)
●
2 hours per sprint for planning.
●
1 hour per sprint for show.
●
Plan resources/developers and QA/QC testers, and tests for each action.
●
Include time for DBA, graphic designer.
●
Include time for estimating each sprint.
Clean Application Development – Now thats better!

21
● Freelancers, ensure you get paid for the estimate!
●
It's hard work to plan an application.
●
It takes time: (time == money)
●
Interview > 5 hours.
●
Gathering requirements > 40 hours.
●
Wireframes, images > 40 hours.
●
Creating an accurate estimate.
●
Documenting technologies.
●
Etc.
Clean Application Development – Get paid!

22
Clean Application Development – Issue Tracking
Issue Tracking

23
● Why track issues/requests:
●
Helps create documentation later.
●
Ensures ideas are not lost.
●
User perception highlighted.
●
Bugs not forgotten.
●
Ownership for users.
●
Auditable.
●
Scheduling.
●
Track effort.
Clean Application Development – Why track?

24
● Use tools.
●
Many software packages available.
●
Agreed upon by team.
●
Should be simple.
●
Should compliment workflow.
●
Connected with source control.
●
Must enhance communication.
●
Customizable. (not just appearance)
Clean Application Development – Tracking Tools

25
● Useful report examples.
●
Average time spent per ticket.
●
By category.
●
By severity.
●
By developer.
●
% Deadlines met on time. (SLA)
●
Total.
●
By Developer.
●
Avg. # failed fixes by QA.
●
By developer.
●
Count per category assigned.
●
By Developer.
Clean Application Development – Tracking Reports

26
Clean Application Development – Time Management
Time Management

27
● Key elements
●
Track everything!
●
Build habits.
●
Use applications.
●
Hamster.
●
Freshbooks.
●
Keep it simple.
●
Easy input.
●
Basic reports.
●
Future estimates.
Clean Application Development – Key Elements

28
Clean Application Development – Service Level
Agreement
SLA – Service Level Agreement

29
● Definition and acceptance.
●
Determine acceptable response levels.
●
Get agreement from stakeholders.
●
Make them public.
●
Based on ticket severity.
●
Must manage user perception.
Clean Application Development – Agreement

30
● Response Times.
●
Blocker = business stopped – 1 hour response
●
Urgent = someone can't work – 3 to 4 hour response
●
High = customer inconvenienced – 8 hour or 1 day response
●
Medium = employee annoyance – 2 days to 1 week response
●
Low = nice to have – 1 to 2 week response
●
Wish = no response, but perhaps a friendly thank you email
Clean Application Development – Responsiveness

31
● Response Contents.
●
Thank user.
●
Acknowledge understanding. (re-state problem)
●
Provide “real“ time estimate of work.
●
Define when work will start. (for higher priority items)
●
Give idea of when work will start for low priority items.
Clean Application Development – Response

32
Clean Application Development – Dev Tools
Dev Tools

33
● Modern IDE
●
Pick one, learn it WELL!
●
Features:
●
Syntax highlighting.
●
Code completion.
●
Source control integration.
●
Issue tracking integration.
●
DB management.
●
Deployment.
●
Testing.
●
Console.
●
Debugging.
Clean Application Development – Using an IDE

34
● Basic Editor
●
Pick one, learn it WELL!
●
Features:
●
Syntax highlighting.
●
Able to handle large files.
●
Opens fast.
●
Saves quickly.
●
Closes error free.
Clean Application Development – Basic Editor

35
● Vim Editor
●
Must know at least basic usage.
●
Exists on most Linux and Unix servers.
●
Don't fear it.
Clean Application Development – Vi / Vim

36
● Vagrant for virtualized development
●
Vagrantup.com
●
Vagrantbox.es
●
Command line tool.
●
Uses:
●
VirtualBox
●
VMWare
●
AWS
●
Others...
●
Can use Puppet or Chef.
●
Free and open source.
Clean Application Development – Vagrant

37
● Vagrant automated
●
http://puphpet.com For Puppet manifests.
●
http://rove.io For Chef recipes.
Clean Application Development – Vagrant
Automated

38
● Frameworks help keep things in line
●
Using a framework helps keep your code light, simpler.
●
Heavy lifting and complexity within core.
●
Most modern frameworks are MVC
●
Model – Business logic, Data
●
View – GUI, Presentation
●
Controller – Directs, Commands
●
Generally have a naming convention
and coding standard.
Clean Application Development – Using frameworks

39
● Dos
●
Pick one, and learn it best.
●
Dabble with others secondary.
●
Get certified.
●
Create your own.
●
Don'ts
●
Roll your own for large projects.
●
Edit framework core.
●
Rebuild functionality.
●
Fall behind. (learn more)
Clean Application Development – Frameworks

40
● Debugging Proxy
●
Must know at least basic usage.
●
Exists on most Linux and Unix servers.
●
Don't fear them.
Clean Application Development – Debugging Proxy

41
● Zend Server
●
Deployment and rollback.
●
Debugging and profiling.
●
Code tracing.
●
Monitoring.
●
Bytecode caching.
●
Session clustering.
●
Page caching.
●
On many cloud providers.
●
Available at ServerGrove!
●
IDE Integration.
Clean Application Development – Zend Server

42
● PHP QA tools
●
http://phpqatools.org
●
PHP Unit
●
PHP CPD (copy/paste detector)
●
PHP Loc (lines of code)
●
PHP MD (mess detector)
●
PHP Codesniffer
●
PHP Depend
●
Jenkins PHP
●
More....
Clean Application Development – PHP QA Tools

43
● XHProf
●
Pecl package.
●
Hierarchical profiler.
●
'How to' on my blog. (http://geekyboy.com)
Clean Application Development – XHProf

44
● XDebug
●
An extension for PHP.
●
Can be installed via Pecl, or using phpize or manual compiling.
●
Allows debugging of PHP code.
●
IDE integration.
Clean Application Development – XDebug

45
● getcomposer.org
●
Dependency manager for PHP.
●
Not a package manager.
●
It is a PHP application in composer.phar.
●
Configured by using composer.json file.
Clean Application Development – Composer

46
● Using Composer
●
Used via command line.
●
Issue commands to the composer.phar.
●
Packages get downloaded, WITH dependencies.
Clean Application Development – Composer Usage

47
● Packagist.org
●
Composer package repository.
●
Archivist of PHP libraries.
●
14,505 packages listed!
●
47,316 versions.
●
52,034,902 packages installed since 2012-04-13.
●
How to use:
●
Search for desired package.
●
Copy/paste the required line to composer.json.
●
Run 'composer install' (or update).
Clean Application Development – Packagist

48
● Just search!
Clean Application Development – Packagist Search

49
Clean Application Development – Database
Database

50
● Database should be clean as well
●
Stick to conventions. (defined by project)
●
Table names
●
ID field
●
Foreign field names {table}_id
●
Timestamps for created/modified
Clean Application Development – Data Conventions

51
● Choose the right database for the job
●
Many to choose from:
●
MySQL
●
MongoDB
●
MSSQL
●
DB2
●
Postgres
●
Oracle
●
SQLite
●
Text file
Clean Application Development – Right Database

52
Clean Application Development – Source Control
Source Control

53
● Learning to code, like walking, takes time
●
We fall down...alot!
●
Learning new methods.
●
Scope changes.
●
Bugs.
●
Refactoring.
Clean Application Development – Baby steps

54
● Source Control
●
Helps us get back up!
●
Diff.
●
Blame.
●
Rollback.
●
Audit trail.
●
Link back to tickets.
Clean Application Development – Pick-up

55
● Key characteristics of source control
●
Track changes.
●
Keep history.
●
Be available.
●
Easy to use.
●
Secure.
●
Allow multi-user.
●
Able to merge changes.
Clean Application Development – Characteristics

56
● Subversion style SCM workflow
Clean Application Development – Subversion
Shared Repository
Developer Developer Developer

57
● Integration manager SCM workflow
Clean Application Development – Integration Mgr.
Blessed
Repository
Integration
Manager
Developer
Public
Developer
Public
Developer
Private
Developer
Private

58
● Dictator and lieutenants SCM workflow
Clean Application Development –
Dictator/Lieutenant
Blessed
Repository
Dictator
Developer Developer Developer Developer
Lieutenant
Lieutenant

59
Clean Application Development – Workflow
Workflow

60
● Project Iteration
●
Average sprint is 2 weeks.
●
At the end of the sprint EVERYTHING is “done“.
●
Tests.
●
Development.
●
Documentation.
●
Velocity charts are very important, put them up!
●
Burn down chart must go on the wall to let everyone know just how “screwed“
they really are.
●
Agile = hope killer. *joking*
●
Allows business to recover.
●
Lack of charts prevent graceful recovery.
Clean Application Development – Agile

61
● Team development workflow
●
Developer is assigned task.
●
Checks out code to private development branch.
●
Developer adds functionality.
Clean Application Development – Team Workflow
Checkout dev.
to private
{user}-development
Coding
Project
assigned

62
●
After coding is completed developer tests code.
Checkout dev.
to private
{user}-development
TestingCoding
Project
assigned

63
●
When all tests pass, developer pushes code to public development branch.
Checkout dev.
to private
{user}-development
Merge changes
to development
TestingCoding
Tests
pass
Project
assigned

64
● Team QA workflow
●
QA testing in development branch.
●
If bugs, return to developer.
●
If pass, merge with staging branch.
Testing from
development
Merge to
staging
Test
passed
Testing
assigned
yes
no
Return to
developer flow

65
● Team deployment manager workflow
●
Regression test in staging branch.
●
If failed, create temp branch for bug fix.
Regression testing
In staging
Test
passed
Deploy
assigned
no
Temp branch
created
Bug
fixed

66
● Team deployment manager workflow
●
If pass, merge to master branch.
●
Create tag for new version.
Regression testing
In staging
Merge to
master
Test
passed
Deploy
assigned
yes
no
Temp branch
created
Bug
fixed
Tag
created

67
● Single developer workflow
●
Pretty similar, but no staging.
●
Still use a private development branch.
{user}-development
Merge to
development
Test
passed
Project
assigned
Tag
created
Regression
test
Merge to
master

68
Clean Application Development – The Code
The Code

69
● Resource on clean coding practices.
Clean Application Development – Resources
Clean Code
By Robert C. Martin

70
● Disasters happen, resulting in bad code...
●
Writing dirty code is easy.
●
Short deadlines.
●
Laziness.
●
Lack of “how-to“.
●
Coupled application.
●
Impatient boss.
●
Bored of same ol' app.
●
Come back and clean later.
●
We are the cause!
●
Why did we write it!?!
Clean Application Development – Drivers

71
● It is our responsibility to say “NO“ and provide good code
●
Managers job = defend schedule and features.
●
Our job = defend the code.
●
Managers cave to realistic reasons and explanations.
Clean Application Development – Defend the code

72
● We have all seen bad code
●
Time waster.
●
Causes bugs.
●
Excessive debugging
●
Causes procrastination.
●
Missed deadlines.
●
Technical debt.
●
Financial losses.
●
Company killer.
●
I didn't write it!!!
Clean Application Development – Result of bad
code

73
Clean Application Development – Dirty Code
Results

74
Results
Time Waste

75
Results
Time Waste

76
Results
Time Waste Creates Bugs

77
Results
Time Waste Creates Bugs

78
Results
Time Waste Creates Bugs Debugging

79
Results

80
Results
Procrastination

81
Results
Procrastination

82
Results
Procrastination Late Projects

83
Results
Procrastination Late Projects

84
Results
Procrastination Late Projects $$$ Loss

85
● Bad code starts innocently
● Hire a new professional/developer
●
Clean slate, no expectations.
● Start a new project
●
Initial code output is quick, setting
expectation.
●
Slows down over time.
●
Bug introduction increases.
●
Over-coupled system.
●
Complexity increases.
●
Completion time...unknown.
●
Domino effect.
Clean Application Development – How we cause it?

86
● How do we handle this?
●
Severely padded estimates.
●
Hide.
●
Become defensive.
●
Blame others/requirements.
●
Add more developers to increase productivity.
●
New developers break the system, because they don't “know“ it.
●
Change jobs.
●
Rewrite!
Clean Application Development – The aftermath

87
● Others judge us on our code
●
We are @authors.
●
Others read our code regularly.
●
And they talk about it!
●
How developers talk about us = “CRED“.
Clean Application Development – You are judged
And they talk about it!

88
● Coding Standards save time
●
Choosing a standard gives direction on best practices.
●
PHP Framework Interoperability Group (https://www.php-fig.org).
●
PSR-0 Autoloader.
●
PSR-1 Basic Coding Standard.
●
PSR-2 Coding Style Guide.
●
PSR-3 Logging
●
PEAR (helped with PSR).
●
Zend Framework (helped with PSR).
●
Symfony2 (helped with PSR).
●
CakePHP (helped with PSR.
●
Lithium (helped with PSR).
●
Many more (helped with PSR).
Clean Application Development – Coding standards

89
● Names should be clear
●
Functions and variables should tell a story.
Clean Application Development – Clear names
$elapsedTimeInDays;
$daysSinceCreation;
$daysSinceModified;
$fileAgeInDays;
$elapsed;
$createdDays;
$modifiedDays;
$age;
GoodBad

90
● Shy away from variations of the same name
●
To ensure names are different enough to portray difference.
Clean Application Development – No confusion
$product
$productInfo
$productData
$productDescription
What is the difference between these?

91
● Certain characters are hard to understand
Clean Application Development – Bad characters
Lower case L
Uppercase O (oh)
Uppercase I (eye)
Bad

92
● Use technical names to help developers, since developers will be
reading the code. Leave non-technical terms for client
documentation.
● Class names should be nouns
●
They describe.
●
Ex. - Customer, Account, Product, Company.
● Method names should be verbs
●
Take action.
●
Ex. - getCustomer, closeAccount, updateProduct, addCompany.
●
Pick a set of keywords and stick with them.
●
Ex. - fetch, get, add, update, remove, delete
Clean Application Development – Name grammar

93
● With all of these problems, clean code makes sense
●
Shortens development time.
●
On-boarding of developers easier.
●
Less bugs.
●
Happier end-users.
●
Predictable schedules.
●
It's the professional thing to do.
Clean Application Development – Common sense

94
● The problem with a rewrite
●
Reasons NOT to rewrite:
●
Budget.
●
Time.
●
Retain business logic.
●
Rewrite is the lazy way out. (perceived)
●
Refactoring = best teacher.
●
Circle of HELL!
Clean Application Development – Rewrite problems

95
● More on Clean Code
●
Functions are pretty much what we expected. No surprises.
●
Small and well named.
●
Code makes language look simple.
●
Recognizing bad code doesn't mean we know how to write clean code.
●
We know if a song is good/bad, but we are not song writers.
●
Knowing code is bad doesn't mean we know how to clean it up.
●
Clean code is written by someone who cares, and it can't really be changed
much.
●
Does not require many, if any, comments.
Clean Application Development – Clean code

96
● Comments can also be a bad “smell“
●
Comments are often used to cover up bad code.
●
Code should be self-documenting
Clean Application Development – Code comments

97
● Standard and quick solutions to common coding problems
●
Provide standard ways of dealing with common code problems.
●
“Guide to PHP Design Patterns“ by Jason Sweat.
●
“Design Patterns, Elements of Reusable Object-Oriented Software“ by Gang of
four
Clean Application Development – Design Patterns

98
● Peer code review great learning tool
●
Peers help train each other on strong points.
●
Fresh set of eyes.
●
Builds better teams.
Clean Application Development – Peer code reviews

99
Clean Application Development – Refactoring
Refactoring

100
● Great refactoring resource.
Clean Application Development – Resources
Refactoring
By Martin Fowler
Companion PHP code at: https://github.com/adamculp/refactoring101

101
● What is refactoring?
●
...process of changing a computer program's source code without modifying its
external functional behavior... en.wikipedia.org/wiki/Refactoring
●
Should not add functionality.
●
Improve code readability.
●
Simplify code.
●
Not optimizing.
Clean Application Development – Definition

102
● Two hats
●
Adding functionality hat
●
Refactoring hat
●
We add functionality, then refactor, then add more functionality ...
Clean Application Development – Two Hats

103
● Why refactor?
●
Prevent code decay.
●
Poor design.
●
Preserve design.
●
Reduce duplication.
●
Improve maintainability.
●
Help code faster.
●
Locate bugs.
●
Code smells.
●
It's professional.
Clean Application Development – Why Refactory

104
● Code smells
●
What are smells?
●
Indications of spoiled code nearby.
●
Not conclusive.
●
Smell is not bad code, but hints of potential problems.
Clean Application Development – Code Smells

105
● Smells list
●
Duplicate code.
●
Large class.
●
Long methods (functions).
●
Long parameter (argument) list.
●
Divergent change – cascade change to accommodate one.
●
Shotgun surgery – change ripples as bugs throughout.
●
Feature envy – method uses many parts from other class.
●
Data clumps – data items accompany one another.
●
Primitive Obsession – using primitive objects to represent various concepts in
places they don't actually fit. (string vs integer, integer vs float, string vs date)
●
Switch statements – often not alone, and sacrifice polymorphism.
Clean Application Development – Smells of bad
code

106
● Smells list (cont'd.)
●
Parellel inheritance hierarchies – forced to subclass due to another subclass.
●
Lazy class – class not doing much, just to be a class.
●
Speculative generality – something built for possible future.
●
Temporary field/variable.
●
Message chains – object asking object asking object, etc.
●
Middle man – directors in place but serve no real purpose.
●
Inappropriate intimacy – classes should not share private parts.
●
Data class – getters and/or setters, but nothing else.
●
Comments – where comments explain bad code.
Clean Application Development – Smells of bad
code

107
● Let PHP CodeSniffer detect bad smells
●
Set rules to detect if coding standard is not followed.
●
Run during commits in version control.
●
IDE integration.
Clean Application Development – Code sniffer

108
● When to refactor?
●
No special time, do in short bursts.
●
Don't decide to refactor, do it to gain something.
●
Prior to adding functionality.
●
Highlights code to modify.
●
Fix code preventing addition.
●
When fixing a bug.
●
Makes code understandable.
●
Highlights the bug.
●
During code review.
●
Fresh eyes see things differently.
●
More concrete results.
Clean Application Development – When to refactor

109
● First steps
●
Use source control (Git, SVN, etc.)
●
Record each step, and provides rollback points.
●
Prove we did/didn't break it.
●
We MUST FIRST GET IT WORKING!
●
Do NOT refactor a broken application.
●
Pre-load database or create fixtures for consistent results.
●
Create tests on working application.
Clean Application Development – How to start

110
● Tests and refactoring
●
Cannot properly refactor without tests.
●
To gauge success/failure.
●
Basic refactor steps:
●
Ensure tests pass.
●
Plan refactor.
●
Implement.
●
Ensure tests still pass.
●
Updating tests if needed.
●
Only needed if structure changed.
●
Add more tests to cover newly discovered items.
●
Repeat!
Clean Application Development – Tests

111

112
Not if Broken

113
Not if Broken

114
Not if Broken Create Tests

115
Not if Broken Create Tests

116
Not if Broken Create Tests Detect Smells

117

118
Different Hats

119
Different Hats

120
Different Hats Improve Code

121
Different Hats Improve Code

122
Different Hats Improve Code No Change

123
Clean Application Development – Architecture
Architecture

124
● We can tell pretty simply this “looks“ like a library. (bookshelves,
computers, book categories)
Clean Application Development – Clear architecture

125
● With cars driving through and shelves on the sides we can guess
this is a drive through.
Clean Application Development – Simple overview

126
● These are pretty obvious without any explanation.
Clean Application Development – Obvious purpose

127
● This would take a bit more digging to figure out.
Clean Application Development – MVC
architecture?

128
● Shouldn't “Architecure“ be
cleaner/clearer/simpler?
Clean Application Development – Future challenges

129
Clean Application Development – Testing
Testing

130
● Selenium IDE
●
Integrated into browsers.
●
Automates human steps.
●
Customizable.
Clean Application Development – Selenium IDE

131
● Behat
●
Open source.
●
For PHP 5.3 and 5.4.
●
Human-readable sentences describing feature.
Clean Application Development – Behavior Driven

132
● Unit testing (our parachute) ensures we write clean code
●
A unit test should only test one thing, a function may need multiple tests.
●
Function should only do one thing, making them short.
●
Testing ensures system is functioning as expected.
●
Helps make refactoring and cleaning easier.
Clean Application Development – Unit Testing

133
● Unit testing is important, so should be done first
●
Write failing tests first, then write the code required to make it pass.
Clean Application Development – TDD

134
● If tests are trusted, they become QA process
●
If tests are good, QA finds no issues.
●
If QA finds an issue, write a test for it.
●
Tests cover requirements.
●
Tests = requirements.
●
QA to write automated tests that fail.
●
Developers execute tests during
development till they pass.
Clean Application Development – Tests = QA

135
● Put QA at the begining of the process, instead of the end
●
QA has a terrible job, waiting for code to test.
●
If they write unit tests they jump to the front.
●
Developers write code to pass tests.
●
The end is not so bad now.
Clean Application Development – QA and unit tests

136
Clean Application Development – Continuous Int.
Continuous Integration

137
● PHing Is Not GNU make.
●
Based on Apache Ant.
●
Uses simple XML build files and extensible PHP 'task' classes.
●
Runs unit tests.
●
File transformations
●
File system operations.
●
Interactive build support.
●
SQL execution.
●
SCM operations.
●
Documentation generation.
●
More....
Clean Application Development – Phing

138
● Zend Deployment
●
Built into Zend Server.
●
Create ZPK of project in Zend Studio.
●
Upload to Zend Server.
●
Deploy!
Clean Application Development – Zend Deployment

139
● Jenkins
●
Formerly known as Hudson.
●
Built with Java.
●
789 plugins.
●
Runs PHPUnit.
●
Runs CodeSniffer.
●
Runs PHP QA Tools.
●
Deploys.
Clean Application Development – Jenkins

140
● Jenkins Results
Clean Application Development – Jenkins Results

141
Clean Application Development – Professional
Be Professional Grade!

142
● Our clients hired a professional, they should get one
●
Professionals are trusted to do a good job, give good estimate, and provide
quality.
●
Professionals are fairly easily replaced, depending on availability.
●
Replaceable = Promotable
(and you can take vacation easily)
●
Shouldn't need to start from scratch.
Clean Application Development – Human resources

143
● Clean application development is:
●
Learning, repetition, practice.
●
Clear architecture.
●
Coding standards and styles.
●
Framework and best practices.
●
Testing.
●
Agile.
●
Learning to say “NO“, and defend the code.
●
Living up to the title “Professional“.
Clean Application Development – Close

● Resources
●
Adam Culp @adamculp and http://geekyboy.com
●
http://RunGeekRadio.com
●
Book: “Clean Code“ by Robert C. Martin
●
Book: “Refactoring“ by Martin Fowler
●
Book: “Guide to PHP Design Patterns“ by Jason Sweat
●
Book: “Design Patterns“ by Gang of four
●
http://www.php-fig.org
●
http://www.phpunit.de
●
http://www.soflophp.org Thank You!
https://joind.in/14892

Clean application development tutorial

More Related Content

What's hot

Viewers also liked

Similar to Clean application development tutorial

More from Adam Culp

Recently uploaded

Clean application development tutorial