Magento 2 Best Practice Workfow // David Lambauer // Meet Magento 2017 // Leipzig

1
Magento 2
Best Practice Workflow

Twitter: @DavidLambauer2
David Lambauer // Software Developer
I ♥️
Open Source
Software Quality
Quotes, Emoji’s and Memes

Twitter and GitHub
@DavidLambauer
github.com/DavidLambauer

Twitter: @DavidLambauer4 Abbildung: https://www.aoe.com/de/home.html

That moment when you
feel like a total noob.

7
No matter how good you are at something, there's
always about a million people better than you.
- Homer Simpson

• Documentation
• Automation / Generation
• Code Segmentation (Business Logic, Framework, Application)
• Tests (Unit // Api // Integration // Static // …)
• Reusability
• Maintenance
• ♥️ the Details!
• …
How do I write awesome Code (in Magento) ?

Same procedure, every Module
Abstract
Module
Components
App Code
Business Logic
Framework
Meta
Entry Points like Plugins. Code to make things work like
the registration.php.
Code that works only in the Context of Magento.
Non coupled Components which implement a specific
business logic.
Code that can be used in different projects and has
injected dependencies.
Components that are totally independent:
e.g. Fileparser / HTTP Clients / DB Abstraction.
Documentation / Specification / Guidelines.
Automated Tests / Dependencies.

As a Sir, I don’t want minors buy Alcohol.

General Workflow
Works for most custom modules.
ReviewImplementTest
SpecifyUnderstand Research Core
Not as time
consuming as you
might think.
Defining a Specification is an early
documentation of your work. The Spec can
be used to share work between the team
more easy.

Research Core
DISCOVER THE CORE
TO REUSE MAGENTO
COMPONENTS
Due to the research, you’ll learn the
“Magento Way” of solving problems and
speed up further developments.
Discover Entry Points.
Check if there are any Components you
can reuse, like a ValidationInterface
where you are able to add another
Validation.
The DevDocs do also have great
examples!
Check relevant Modules
• module-sales
• module-checkout
• module-customer
Check API’s and Events first
• Checkout  AgreementsValidatorInterface::isValid()
• Sales  OrderManagementInterface::place()
• Customer  AccountManagementInterface::validate()
Evaluate & Debug
Try to find where your search results are used. A quick
debugging session could help a lot. Add breakpoints to each
result to check when they are called.
01
02
03

Add the Specification
• Use a Format that is easy to read, easy to use and fast to write.
• Markdown ♥️ // reStrcuturedText // LaTeX
• Use a Tool to share your Work in PDF or HTML.
• Add UML Diagrams, so people have the chance to dive into your specs quickly.
• Write Specifications for Humans. Add general information!
• Don’t shorten, make sentences.

Avoid hand-hacking; write programs to write
programs when you can.
Rule of Generation
- Eric Raymond’s

Twitter: @DavidLambauer17 http://squidfunk.github.io/mkdocs-material/

Twitter: @DavidLambauer18 http://squidfunk.github.io/mkdocs-material/

Adding a Specification - Bird Eye View
• Add a StoreConfig to
– Section / Group / Field
– Define Label / Id / Note / Type / ...
• Add a beforePlaceOrder Plugin.
– Define Classname / Dependencies / Methods / Parameter / Usage
• Add a Validator to check the age.
– Define Classname / Interface / Dependencies / Methods / Parameters / Usage

[Without unit tests] You're not refactoring, you're just
changing shit.
- Hamlet D'Arcy

Testing Overview
Unit & Static Testing
Unit testing is the testing of an individual unit or
group of related units.
Integration Testing
Integration testing is testing in which a group of
components are combined to produce output.
Functional Testing
Functional testing is the testing to ensure that the
specified functionality required in the system
requirements works.
System / Performance / Frontend / …
Depending on the complexity and the business
impact of your module, add as many tests as you
need.
Abbildung: Eigendarstellung

Writing Unit Tests
• Use File- and Live Templates (PHPStorm).
• Assertion should be as simple as possible.
• Test possible Exceptions with Annotation (i.e: @expectedException).
• Unit Test can be a 3-Liner.
• Use Multi-Cursor whenever it is possible.

Twitter: @DavidLambauer23 Abbildung: PHPStorm EAP 2017.1

Twitter: @DavidLambauer24 Abbildung: PHPStorm EAP 2017.1

Implement
• After the Specification, generate standard Magento Code.
• Implement the business Logic.
• That’s it! We already did the main work by adding the Specs.

Twitter: @DavidLambauer26 https://mage2gen.com/

Twitter: @DavidLambauer27 https://github.com/netz98/n98-magerun2

In case you missed it, what did we actually do?
• Learned from the Core.
• Added some Markdown to have a Specification.
• Generated a good looking Document with a single Command.
• Generated UML Diagrams by adding some simple Code.
• Generated Unit Tests with File- and Live Templates.
• Generated Magento Standard Code with one of the great Code Generator.

Avoid hand-hacking; write programs to write
programs when you can.
Rule of Generation
- Eric Raymond’s

Started on GitHub!
AOEpeople/Magento-2-Module-Skeleton
Get situated under a minute.

One more thing…

As a Troll, I do change my requirements!
Minors should not be able to register either!

Add one more entry point and we‘re good.
Restart the Workflow, don’t forget to add the new specs.

That’s it!
Thank you so much for your attention, I would love to answer some
questions.

Magento 2 Best Practice Workfow // David Lambauer // Meet Magento 2017 // Leipzig

Recommended

More Related Content

What's hot (20)

Similar to Magento 2 Best Practice Workfow // David Lambauer // Meet Magento 2017 // Leipzig (20)

More from AOE (20)

Recently uploaded (20)

Magento 2 Best Practice Workfow // David Lambauer // Meet Magento 2017 // Leipzig

Editor's Notes