Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


PHP: Methods, Practices, Patterns, and Teamwork.

A quick rundown of how/why to structure PHP code, how to build dev teams, and the hows/whys of building and deployment.

Shawn Stratton

on 5 May 2011

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of PHP: Methods, Practices, Patterns, and Teamwork.

Who Am I? PHP Developer since 2001 (Basically a web designer for a few years).
Started doing enterprise dev in 2007.
Now I work for Discovery Communications, LLC on the site HowStuffWorks.com.
Worked on NationalGuard.com.
Dabble in Open Source (phpDocumentor, ZF2, Wires.)
Highly nervous in front of crowds (excuse the stuttering, getting lost, etc.) Thank You Shawn Stratton @mfacenet sstratton@php.net Programming
Paradigms Event Driven Procedural Functional Object Oriented Aspect Oriented $z = 5;
$z = $z + 1;
print $z; Also known as imperative, or order based, programming.
Executes linearly from start to finish.
Uses GOTO, Labels, and conditionals for flow control. Groups reusable code into Functions.
Eliminates the need for GOTO.
Allows for better flow control and code reuse.
Heavily used in PHP prior to PHP 4. Example function addOneAndPrint($z) {
$z = $z + 1;
print $z;
addOneAndPrint(5); Define objects (data and data modification methods) using blueprints (classes)
Some duplication still exists, code is very wordy and requires knowledge of architecture and interaction.
Introduces concepts of:
Polymorphism (Overloading). Example Loosely supported in PHP-Next (maybe 5.4) as traits.
Allows for finely granulated “concerns” to be written separate of their implementation. e.g. Logging facilities to be used in every transaction object. Traits in PHP-NEXT Not natively supported by PHP, generally lives in the realm of UI and Interaction.
Known from javascript body.onLoad().
Bind actions to events (triggers).
Can use the observer pattern to mock out. Practices “Programming is like sex. One mistake and you have to support it for the rest of your life.” ~Michael Sinz Best practices theoretically ensure the best possible outcome. (This isn't always true)
Like every field, our rules and practices are written as a result from failure and sometimes due to success. These practices allow you to learn from others failures/successes. Tech Debt Keep It Simple Don't Repeat Yourself Code Decoupling Commenting Be Descriptive and Explicit “Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise” Ward Cunningham - 1992 - http://en.wikipedia.org/wiki/Technical_debt Tech Debt cont. Leaving problems in code can build how much time you spend fixing it later.
Debt mounts with interest, unless put in check, until it can own the code base.
Estimated that every line written puts an amount of debt on the project, some more than others. (According to a CAST study average is $2.82. http://www.castsoftware.com/Resources/Materials/News/PR_092810.aspx) Repetition is a Maintenance Nightmare, imagine when you'll have to find and change every instance of what you just copied and pasted.
Polymorphism and Overloading are much better alternatives. Readability - You (and maybe others) have to maintain this in the future (you'll have slept by then.)
Errors - Complexity brings risk, the more simplistic something is the more likely it is to be defect free. Write simple code so that it can almost be read naturally - also known as self documenting code.
Write informative docblocks for your files, classes, methods, functions.
Document complexity (intentional or unavoidable messes.)
Use task tags for things you find or leave behind - @TODO @FIXME @BUG Variable name choice means a lot. ($arrayer vs. $dbRows)
Function/method names should document some of the functionality.
Blow out conditionals. (if (condition) { return; } vs. condition & return; ) Lessen internal dependencies (or likelihood that one change will cause cascading failures.)
Allows you to swap, or overload, concrete objects to allow extension of functionality.
Associated theories: Inversion of Control (DI,) Polymorphism, Adapter Pattern. Testing Always Test Your Code before releasing to client/production.
In absence of automatic testing (Unit/Functional Testing) manual testing is still an option.
You don't save time by skipping testing, just shift time (at a penalty) until later. Unit Testing Allows for testing of individual small units of code (usually functions or methods.)
Can show where a change breaks other functional units.
Tests can double as documentation.
Tests give programmers additional confidence while making changes that they are not breaking existing functionality.
Foundation of Test Driven Development (Write Tests first, code until tests pass.) PHPUnit Example Taken from http://www.phpunit.de/manual/current/en/writing-tests-for-phpunit.html#writing-tests-for-phpunit.test-dependencies Selenium (Frontend) Testing Checks web frontend functionality.
Simulates end-user moving through application, verifies interaction works as expected in multiple browsers (IE, Chrome, Firefox).
Written in selenese (a subset of HTML) but can be ported to PHP, .NET, Java, etc.
DOES NOT verify styles render correctly or for that matter even timely. Example <table>
</table> Code / Peer Review Serves multiple purposes:
Gets other developers to check code being written.
Familiarizes others with areas of functionality (decreases the bus factor.)
Reviews decisions made and forces the programmer to defend their position. Patterns & DSLs Development Methodolgies Teams Builds & Deployments What are Patterns?

Reusable problem solutions (technology independent) for common problems in software architecture.
Well defined DSL to allow for better communications between Programmers/Architects/etc.

Whats a DSL?

Common language specific to a problem Domain.
Software Development Specific Example of a DSL Term: On the Subject of DSLs, an example term Yak Shaving - The objective of all dedicated product support employees should be to thoroughly analyze all situations, anticipate all problems prior to their occurrence, have answers for these problems, and move swiftly to solve these problems when called upon. However, when you are up to your ass in alligators, it is difficult to remind yourself that your initial objective was to drain the swamp. From:http://blog.calevans.com/2010/08/20/software-development-dsl/ Common Design Patterns Singleton
Registry yak shaving by LiminalMike, on Flickr Anti-Patterns & Patternitis Patternitis - The use of patterns in areas where it's not needed due to the developers/architects obsession with using design patterns. E.g. using singletons or factories for every object in your project.

Anti-Patterns are bad solutions to common problems, examples: (from http://en.wikipedia.org/wiki/Anti-pattern)
God object: Concentrating too many functions in a single part of the design (class).
Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules.
Sequential coupling: A class that requires its methods to be called in a particular order. Agile Kanban Waterfall Scrum We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more. Based on Short Iterative Development Cycles (1 to 4 weeks usually)
Daily Standup - Daily Scrum - asks 3 questions.
What did you do Yesterday?
What are you doing today?
What is blocking you?
Sprint Planning, Review, and Retrospective meetings.
Roles: Scrum Master, Pig, Chicken. (Chicken contributes while the Pig has bacon on the line.)
Works from Product Backlog, team selects tasks based on prioritized list that it can commit to during the duration of the sprint. XP Pioneered by Kent Beck in the Late 90's.
Combination of smaller concepts to aide in iterative development.
Concepts used:
Pair Programing.
Test Driven Development.
Continuous Integration & Releases.
Others Others Agile Unified Process (AUP)
Dynamic Systems Development Method (DSDM)
Essential Unified Process (EssUP)
Feature Driven Development (FDD)
Open Unified Process (OpenUP)
Velocity tracking Listed on Wikipedia Like most of the Agile methodologies, Kanban is an iterative practice which was taken from Japanese Manufacturing and applied to software development.
Uses a binning system to limit the amount of work in different stages (Development, Documentation, QA, etc) and ensures that things are written as they are needed and not before.
Based on Six Rules
Do not send defective products to the subsequent process
The subsequent process comes to withdraw only what is needed
Produce only the exact quantity withdrawn by the subsequent process
Level the production
Kanban is a means to fine tuning
Stabilize and rationalize the process Standard Development methodology in most traditional shops, which believes entire project should move through 7 phases as a whole unit.
Prescribed in US Government Work (that should say everything about old and slow that needs to be said here.)
Likely causes for failure with this paradigm: Slow Time to Market, Inability to plan for everything without having built anything, etc. aka Cascading Failure Philosophy Unstructured Structured Team Size Mythical Man Month Every team member is responsible for Architecture, Database Administration & Design, and sometimes even Operations.
Very common in smaller companies or “non IT” companies.
Somewhat disorganized, very hard to drive change.
Likely to find “Legacy” code, outdated software packages, and stressed workers who have no clue what their daily activities will bring. Some mixture of architecture (usually 1 or 2,) Operations (1 or 2,) Database Administrator (usually one of the ops people,) and multiple programmers (of various degrees of seniority and skillsets.)
Likely to find highly structured code & highly structured process.
Process is likely to decrease programmer/other's creativity.
Change is driven in a very orderly way, requiring buy in from various levels, usually with gobs of documentation created.
Can de-motivate workers, as they will feel the structure chokes them. Agile development teams are usually roughly 7 people.
Size & Makeup usually vary greatly between companies, projects, etc.
7 Seems to be a magical number (I've observed this number at a few companies I've worked that weren't agile) “Assigning more programmers to a project running behind schedule will make it even later, because of the time required for the new programmers to learn about the project, as well as the increased communication overhead. When N people have to communicate among themselves (without a hierarchy), as N increases, their output M decreases and can even become negative, i.e., the total work remaining at the end of a day is greater than the total work that had been remaining at the beginning of that day, such as when many bugs are created.” – Wikipedia – http://en.wikipedia.org/wiki/The_Mythical_Man-Month

Group Intercommunication Formula: n(n 1) / 2
Example: 50 developers give 50 · (50 – 1) / 2 = 1225 channels of communication. Code Management Systems available (and in use, hence no CVS) today include:

SVN - Common - used by PHP itself, Google Code, various larger projects.
GIT (Distributed)- Somewhat Common - Used by and developed for, the Linux Kernel project, Github, Zend Framework, Symfony.
Bazaar (Distributed) - Less Common - Used by MySQL, Ubuntu, .
Mercurial (Distributed) - Less Common - Used by Mozilla, GO Lang, OpenOffice. Tagging is taking a snapshot of the codebase from a branch (or mainline/trunk/master) at a point in time.

Tags are usually used to mark:
Release Versions.
Nightly Snapshots (for historical purposes.) Branching Tagging Branching is taking a “branch” from the mainline of development to:
Develop additional features.
Store partial features.
Create a modifiable support image.
There's a million different uses for branching. Builds Converts raw source code into a software artifact (or something or other.)
Takes the source you have written and creates usable software, sometimes incorporating testing, documentation generation, and generation of metrics (line count, mess detection, etc.) Continuous Integration Continuous Deployment Runs builds on a regular trigger (modifications to revision system, time, etc) and alerts on build failure.
Several systems exist: CruiseControl, Hudson, etc.
Early warning sign of failure in software. Extension of Continuous Integration, takes any successful builds and pushes them to the production server.
Known to be used at Flickr.
Pushes code constantly to the server, masks functionality under conditions or version numbers (to allow unfinished features to be present in production code.)
Common solution to bring the benefits of Continuous Deployment to a traditional software shop is usually to reduce the iteration/sprint time. Traditional Deployments Direct Deployment (Dropping Files onto a server)
Very common with smaller projects.
Manually copying over files to the server whether via FTP, rsync, scp, smb, etc.
Doesn't usually take Revision Control into account.
Can cause unexpected problems of code being overwritten or only partially deployed. Deploying using installation
Several technologies to help exist: Phing, Ant, Capistrano, rsync (when used correctly.)
Usually involves exporting a tag & processing it (creating a build) then pushing it to the server at once.
Process takes time so deployment takes time from code completion to live on the server.deployed. Create Logic to modify, collect, and/or display data.
Debug Logic.
Keep updated on technology trends.
Maintain Code Base.
Troubleshoot and resolve problems.
Technically the toughest job on the team at “Senior” levels. Makeup Programming Primary Duty - Ensure the operations and availability of the Application Servers, Network Components, and Database Servers.
Secondary Duties
Monitors resources on the servers and acts as a front line of defense for application failure.
Plans capacity of the application servers/database servers, etc.
Develops backup plans, failure response, etc. Architecture Operations Primary Duty - Ensure quality of code and it's ability to withstand the test of time.
Secondary Duties
Make design decisions (Patterns, Structure, etc.)
Act as a mentor to developers.
Reconciles individual projects with the long term project goal. “A PROGRAMMER IS A DEVICE FOR TURNING COFFEE INTO CODE” - Unknown Database Administrator Primary Duty - Responsible for ensuring the database is running optimally full time.
Secondary Duties
Works with Architecture to design database schema.
Optimizes database performance and monitors for performance problems.
Develops backup plans, failure responses, and scale out plans for the database. Operations Specialty PHP: Methods, Practices, Patterns, and Teamwork. Shawn Stratton
@mfacenet http://shawnstratton.info Phases: Requirements Specification
Implementation Testing
Maintenance Management Not really part of the "tech team"

Types of Management:
Team Lead / Development Manager - The team's father figure, usually all Programmers report to this person.
Project Manager - Works with business analysts, clients, etc to prioritize, schedule, and ensure that projects are completed. Collaboration Communication:
Instant Messenger
Google Wave?
Yammer? Other Tools:
Bugtracker - Jira, Mantis, Eventum, Bugzilla, etc.
Wiki - DokuWiki, MediaWiki, Confluence.
Calendar - Google Calendar, Exchange, etc. Should be available from anywhere! About this talk: Not a good detailed discussion, just an overview.
Not everything contained is applicable to every body/project/company.
My goal: Give a good overview of Advanced (Non-Technical) Topics of PHP Development and lay the seeds for newer developers to grow from.
The quality of this talk is highly dependent on conversation, I would rather have a group discussion for an hour than read slides. (Interrupt me and ask questions!) After Party @ Vickery's. They're closing down after this month :( What practices do you use and which are most important to you? Why Patterns? (Hint: Our brains can recognize patterns)
Full transcript