From Good to SOLID

From the talk at CodeTalks Conference 2018

Working with companies from early-stage startups to Fortune 500, I've experienced both the struggle of continuing someone else's work and the joy of it. The difference is only in their approach towards the design of their code. It's a minor effort if done on time, with a huge impact on the overall development of the software. In this presentation, we'll focus on what distinguishes a good developer from a strong one and learn how to stand out from the crowd.

Transcript

1. Katerina Trajchevska From Good to SOLID Architecture
2. Katerina Trajchevska • Senior Software Engineer & co-founder of Adeva • Remote Work Advocate • Community Volunteer • Consultant with startups and Fortune 500 companies Software Engineer and co-founder of Adeva
3. @ktrajchevska The state of software development Cutting costs by sacrificing good software architecture.
4. @ktrajchevska SOLID Design Principles • Encourage writing code that is: ◦ Easier to read and understand ◦ Easier to maintain ◦ Easier to extend • Introduced by Robert Martin (Uncle Bob), named by Michael Feathers.
5. Single Responsibility Principle A class should have one, and only one, reason to change.
7. @ktrajchevska Single Responsibility Principle • A class should only do one thing. • Find one responsibility and move everything else out of the class. • Very precise names for many small classes > generic names for large classes.
8. 1 2 3
12. Open/Closed Principle An entity should be open for extension, but closed for modification.
14. @ktrajchevska Open/Closed Principle • Extend functionality by adding new code instead of changing existing one. • Easily extend the system; never break it. • Example: Open Source library
22. Liskov Substitution Principle Let φ(x) be a property provable about objects x of type T. Then φ(y) should be true for objects y of type S where S is a subtype of T.
24. @ktrajchevska Liskov Substitution Principle • Any class should be able to substitute its parent class without breaking the program. • Every class that implements an interface, must be able to substitute any other class that implements the same interface without breaking the program. • Every part of the code should get the expected result.
25. Returns Illuminate\Support\Collection
27. Returns array
29. Returns Illuminate\Support\Collection
33. Interface Segregation Principle No client should be forced to depend on methods it does not use.
35. @ktrajchevska Interface Segregation Principle • A client should never be forced to depend on methods it doesn't use. • Changing one method in a class shouldn’t affect classes that don’t depend on it. • Replace a large interface with many small, specific interfaces.
36. Illuminate\Database\ Eloquent\Model: 1600+ lines of code
39. Dependency Inversion Principle High-level modules should not depend on low-level modules. Both should depend on abstractions.
41. @ktrajchevska Dependency Inversion Principle • Never depend on anything concrete, only depend on abstractions. • High level modules should not depend directly on low level modules. • Able to change an implementation easily without altering the high level code.
47. @ktrajchevska The results of SOLID Cutting costs by implementing good software architecture.
48. @ktrajchevska ⚠ Words of caution • SOLID design principles are principles, not rules. • Know your trade-offs and use common sense when applying SOLID. • Avoid over-fragmenting your code. • Don’t try to achieve SOLID, use SOLID to achieve better developer experience.
50. @ktrajchevska Final Thoughts • SOLID helps you achieve code that’s easy to maintain, extend and understand. • Spend more time writing and less time reading code. • Always know your trade-offs and use common sense.
51. SOLID is your tool, not your goal.
52. Thank you @ktrajchevska Connecting tech companies with world-class developers