This Slidedeck was used for my talk at MMDE17 in Leipzig. The Talk is about a best practice workflow in Magento and targets developer who are used to write a lot of modules in their daily work.
9. Twitter: @DavidLambauer9
âą 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) ?
10. Twitter: @DavidLambauer10
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.
13. Twitter: @DavidLambauer13
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.
14. Twitter: @DavidLambauer14
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
15. Twitter: @DavidLambauer15
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.
21. Twitter: @DavidLambauer21
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
22. Twitter: @DavidLambauer22
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.
25. Twitter: @DavidLambauer25
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.
28. Twitter: @DavidLambauer28
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.
Hallo zusammen,
Freut mich das so viele gekommen sind. Heute geht es um Magento 2 Best Practice Workflow und zwar in der Modulentwicklung. Ich möchte zum einen zeigen, welche Vorgehensweise sich bewÀhrt hat und wie man diese Vorgehensweise wirtschaftlich effizient und technisch qualitativ hochwertig einsetzten kann.
Bevor wir anfangen, ein paar Worte zu mir:
Ich bin David Lambauer, Software Entwickler und habe ein Fabel fĂŒr Open Source, Software QualitĂ€t, Zitate, Emojis und Memes. HĂ€tte man aber bestimmt auch gemerkt im Laufe des Vortrags :D
Ich bin zu finden auf Github und Twitter...
Und ich arbeite bei AOE in Wiesbaden!
Jedem ist es schon einmal passiert, dass man in ein fachliches GesprÀch gekommen ist und der GesprÀchspartner von Dingen erzÀhlt von denen man noch nie etwas gehört hat. Nach diesen Situationen gehe ich immer total geflasht raus und frage mich wie es sein kann das ich absolut noch nie etwas von dem Inhalt des GesprÀchs vorher gehört habe.
In diesem Momenten fĂŒhlt man sich immer wie ein totaler noob :D Das ganze ist aber nur semi schlimm und mittlerweile mag ich es total in solche Situationen zu kommen, denn nur so wird man wirklich besser.
Es gibt immer jemanden der besser auf einem bestimmten Gebiet ist als man selbst. Das sollte man definitiv fĂŒr sich nutzen und so viel Wissen einsammeln wie es nur geht. Deswegen wird dieser Vortrag auch keine expliziete Schritt fĂŒr Schritt Anleitung sondern eher eine theoretische Story mit vielen Buzzwords ï
Nachdem ich wiederholt auf die fachlich vermeintlich besseren Menschen traf habe ich beschlossen zu analysieren was denn eigentlich so cool ist und warum sie so gut sind wie sie sind.
Als Grundlage dafĂŒr habe ich mir verschiedene Quellen gesucht. Zum einen habe ich klassische Literatur gelesen wie etwa das Gang of Four Buch oder Clean Code. Zum anderen habe ich meine Kollegen beobachtet, GitHub Module analysiert und versucht diese Quellen zusammen zu bringen und auf Magento 2 zu mĂŒnzen.
Es gibt eine Hand von Buzzwords die mir besonders im Magento 2 Umfeld wichtig waren. Diese habe ich mal wie folgt definiert:
Spiegelstriche vorlesen....
Nachdem ich diese sehr Allgemeine Analyse gemacht habe, habe ich eine weitere Analyse zu Magento 2 Modulen erstellt. Das Ergebnis davon ist etwa das folgende:
Ein M2 Modul besteht prinzipiell aus vier Bestandteilen.
Application Code ï Registration.php // di.xml // module.xml
Business Logic ï Komponenten die mit Magento interagieren aber kein direkter Bestandteil des Systems sein mĂŒssen.
Framework oder Library ï Guzzle // CsvParser // FileWriter
Meta ï Tests // Composer Dependencies // Dokumentation // Spezifikation
Diese vier Bestandteile sollten wir im Hinterkopf behalten.
Um unsere Analysen nun auch nutzen zu können, habe ich mir eine Super simple Story ausgedacht, die aber recht anschaulich ein Beispiel zeigen sollte
Ich möchte nicht, das Jugendliche in einem definierten Alter Alkohol in meinem Shop kaufen