Vinai Kopp - How i develop M2 modules

EFFECTIVE MODULE DEVELOPMENT
FOR MAGENTO 2
!(c) Vinai Kopp - http://vinaikopp.com - twitter://@VinaiKopp - Meet Magento IT on 2018-05-24

1.
(c) Vinai Kopp - http://vinaikopp.com - twitter://@VinaiKopp - Meet Magento IT on 2018-05-24

OPTIMIZE THE
FEEDBACK LOOP

TDD !(c) Vinai Kopp - http://vinaikopp.com - twitter://@VinaiKopp - Meet Magento IT on 2018-05-24

REPL !(c) Vinai Kopp - http://vinaikopp.com - twitter://@VinaiKopp - Meet Magento IT on 2018-05-24

[R]ead
[E]val
[P]rint
[L]oop

n98-magerun2 dev:console

Next best thing after TDD

Interactive development
Poke the system with a stick & see what happens

Predeclared ObjectManager as $di

(REPL DEMO)
▸ Code Generation
▸ Testing Glue Code (e.g. ORM)
▸ Testing ObjectManager Config
▸ Inspecting the ObjectManager Config

2.

SEPARATE CUSTOM LOGIC
FROM FRAMEWORK CODE

Entry Point:
any custom method that is called by Magento

Plugins
Action Controllers
Observers
Blocks
Section Sources
Total Models
...

(ENTRY POINTS CODE EXAMPLE)
▸ Action Controller
▸ Extension Attributes

3.

EXPLICIT
IS BETTER THAN
IMPLICIT

Calling methods that
are not on the interface

MagentoFrameworkAppRouterBase

Assuming a specific implementation

MagentoCatalogModelProductRepository

What are the consequences?

breaks static code analysis
makes testing harder
makes refactoring harder
makes code harder to understand

It violates the interface contract

What to do instead?

Make the implicit explicit

Instead of assuming an implementation,
depend on the implementation

4.

COMPOSITION
OVER
INHERITANCE

What does this mean?

Inheritance Example:

// ClanMember inherits Customer
class ClanMember extends Customer
{
public function getFullName()
{
return __(
'%1 of the %2',
$this->getName(), // inherited method
$this->getClanName()
);
}
public function getClanName() {...}
}

Every call to a parent method
is like a call to a different object

// ClanMember is composed with Customer
class ClanMember
{
/** @var Customer */
private $customer;
public function __construct(Customer $customer)
{
$this->customer = $customer;
}
public function getName()
{
return $this->customer->getName()
}
public function getFullName()
{
return __('%1 of the %2', $this->getName(), this->getClanName());
}
public function getClanName() { ... }
}

What about extending a class
for customization?

Decorator Pattern
!

DECORATOR
▸ Wrap original instance instead of extending it
▸ No inheritance
▸ Implement same interface
▸ Implement changed methods
▸ Unchanged methods just call delegate

Example of inheritance based customization:

// inherit to customize render() via overwrite
class OrdinalPlaceholderRenderer extends Placeholder
{
private static $ordinal = ['first', 'second', 'third', 'fourth'];
public function render(array $source, array $arguments)
{
$source[] = reduce(keys(self::$ordinal), [$this, 'replaceOrdinalWithInt'], pop($source));
return parent::render($source, $arguments);
}
private function replaceOrdinalWithInt($source, $ordinalIdx)
{
$pattern = '/%' . self::$ordinal[$ordinalIdx] . 'b/';
$replacement = '%' . ($ordinalIdx + 1);
return preg_replace($pattern, $replacement, $source);
}
}

Decorator example:

class OrdinalPlaceholderRendererDecorator implements RendererInterface
{
/** @var RendererInterface */
private $delegate;
private static $ordinal = ['first', 'second', 'third', 'fourth'];
public function __construct(RendererInterface $delegate)
{
$this->delegate = $delegate;
}
public function render(array $source, array $arguments)
{
$source[] = reduce(keys(self::$ordinal), [$this, 'replaceOrdinalWithInt'], pop($source));
return $this->delegate->render($source, $arguments);
}
private function replaceOrdinalWithInt(string $source, int $ordinalIdx): string
{
}
}

Consequences

- More complex

+ Better code reuse
+ Easier to change
+ Easier to test
+ More upgradeable

5.

ATTITUDE

IMAGINE A LEGENDARY
DEVELOPER WILL REVIEW
IN 2 HOURS...!(c) Vinai Kopp - http://vinaikopp.com - twitter://@VinaiKopp - Meet Magento IT on 2018-05-24

What would _ _ _ _ do?

I am responsible for my attitude

6.

BUILD STRATEGIES

Strategy 1: From one to many

Get one working
private function replaceOrdinalWithInt($source, $ordinalIdx)
{
}

Then apply to many
$source[] = reduce(
keys(self::$ordinal),
[$this, 'replaceOrdinalWithInt'],
pop($source)
);

array_map
array_filter
array_reduce

Simpler to test
Simpler to reason about

Strategy 2: Favor immutability

After a variable is initialized,
never overwrite it's value

Simpler to refactor

Strategy 3: Favor pure functions

Same input, same output
No side effects

Simpler to test
Simpler to change
Simpler to compose

Strategy 4: Follow a design recipe

name, input, output, examples

A) When writing a function, start with a name
(but no arguments yet)

B) Add a docblock
document the inputs and output

C) Add one example of inputs and expected output
per execution branch

D) Write the method

E) Finally check the behavior matches the examples

Thank you for your attention!
!
Questions? !

Vinai Kopp - How i develop M2 modules

Recommended

Recommended

More Related Content

Similar to Vinai Kopp - How i develop M2 modules

Similar to Vinai Kopp - How i develop M2 modules (20)

More from Meet Magento Italy

More from Meet Magento Italy (20)

Recently uploaded

Recently uploaded (20)

Vinai Kopp - How i develop M2 modules