├── .gitignore ├── CNAME ├── README.md ├── _config.yml ├── images ├── ide-code-templates-code.png ├── ide-code-templates-files.png ├── ide-code-templates-includes.png ├── ide-live-templates.png ├── logo-key-promoter-X.png └── logo-php-inspections.png ├── team-work ├── README.md ├── agile.md ├── agreements.md ├── code-reviews.md ├── documentation.md ├── estimations.md └── knowledge-sharing.md └── technical-skills ├── README.md ├── comments.md ├── decoupled-business-logic.md ├── final-classes.md ├── functions.md ├── git-mastering.md ├── ide.md ├── immutability.md ├── meaningful-names.md ├── minimum-scope.md ├── performance-tips.md ├── static-analysis.md ├── strict-types.md └── testing.md /.gitignore: -------------------------------------------------------------------------------- 1 | .idea/ 2 | -------------------------------------------------------------------------------- /CNAME: -------------------------------------------------------------------------------- 1 | php.chemaclass.com -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # PHP Best Practices 2 | 3 | Apart from consulting: 4 | 5 | * [PHP The Right Way](https://phptherightway.com/) 6 | * [Clean Code adapted for PHP](https://github.com/jupeter/clean-code-php) 7 | * [Awesome PHP libraries and resources](https://github.com/ziadoz/awesome-php) 8 | * [My personal blog](https://chemaclass.com/blog) 9 | 10 | ## Teamwork 11 | 12 | | | | 13 | |------------------------------------------------------|-----------------------------------| 14 | | [Agile](/team-work/agile.md) | Agile software development values | 15 | | [Agreements](/team-work/agreements.md) | We need conventions | 16 | | [Code Reviews](/team-work/code-reviews.md) | Pair Programming & Pull Request | 17 | | [Documentation](/team-work/documentation.md) | Document your knowledge | 18 | | [Estimations](/team-work/estimations.md) | Discover the unknowns | 19 | | [Knowledge sharing](/team-work/knowledge-sharing.md) | Follow the news of your stack | 20 | 21 | ## Technical skills 22 | 23 | | | | 24 | |---------------------------------------------------------------------------|---------------------------------------------------| 25 | | [Comments](/technical-skills/comments.md) | They are not always updated | 26 | | [Decoupled business logic](/technical-skills/decoupled-business-logic.md) | Abstraction, concretions, layers and dependencies | 27 | | [Final Classes](/technical-skills/final-classes.md) | Composition over inheritance | 28 | | [Functions](/technical-skills/functions.md) | They should be small | 29 | | [Git Mastering](/technical-skills/git-mastering.md) | The best software version control | 30 | | [IDE](/technical-skills/ide.md) | Know your IDE | 31 | | [Immutability](/technical-skills/immutability.md) | It makes the code more predictable | 32 | | [Meaningful Names](/technical-skills/meaningful-names.md) | It should tell you why it exists and what it does | 33 | | [Minimum Scope](/technical-skills/minimum-scope.md) | For your variables, methods, and classes | 34 | | [Performance Tips](/technical-skills/performance-tips.md) | Use strict comparison | 35 | | [Strict Types](/technical-skills/strict-types.md) | Use strict_types constant when possible | 36 | | [Static Analysis](/technical-skills/static-analysis.md) | Identify bugs in your code | 37 | | [Testing](/technical-skills/testing.md) | Test what your software does | 38 | -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | theme: jekyll-theme-tactile -------------------------------------------------------------------------------- /images/ide-code-templates-code.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Chemaclass/php-best-practices/082feed52a48038b091649a3e24a7fba93206654/images/ide-code-templates-code.png -------------------------------------------------------------------------------- /images/ide-code-templates-files.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Chemaclass/php-best-practices/082feed52a48038b091649a3e24a7fba93206654/images/ide-code-templates-files.png -------------------------------------------------------------------------------- /images/ide-code-templates-includes.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Chemaclass/php-best-practices/082feed52a48038b091649a3e24a7fba93206654/images/ide-code-templates-includes.png -------------------------------------------------------------------------------- /images/ide-live-templates.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Chemaclass/php-best-practices/082feed52a48038b091649a3e24a7fba93206654/images/ide-live-templates.png -------------------------------------------------------------------------------- /images/logo-key-promoter-X.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Chemaclass/php-best-practices/082feed52a48038b091649a3e24a7fba93206654/images/logo-key-promoter-X.png -------------------------------------------------------------------------------- /images/logo-php-inspections.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Chemaclass/php-best-practices/082feed52a48038b091649a3e24a7fba93206654/images/logo-php-inspections.png -------------------------------------------------------------------------------- /team-work/README.md: -------------------------------------------------------------------------------- 1 | [Back to the index](../README.md) 2 | 3 | ## Team work 4 | 5 | | | | 6 | |---------------------------------------------|-----------------------------------| 7 | | [Agile](./agile.md) | Agile software development values | 8 | | [Agreements](./agreements.md) | We need conventions | 9 | | [Code Reviews](./code-reviews.md) | Pair Programming & Pull Request | 10 | | [Documentation](./documentation.md) | Document your knowledge | 11 | | [Estimations](./estimations.md) | Discover the unknowns | 12 | | [Knowledge sharing](./knowledge-sharing.md) | Follow the news of your stack | 13 | -------------------------------------------------------------------------------- /team-work/agile.md: -------------------------------------------------------------------------------- 1 | [Back to team work](../team-work) 2 | 3 | # Agile 4 | 5 | ## Continuous feedback 6 | 7 | A healthy environment of openness and honest feedback among team members is critical for a team to learn 8 | and adapt quickly in order to perform at their best potential. 9 | 10 | ## Minimize the scope of your tasks 11 | 12 | Try to minimize the scope of your working tickets to the minimum value that could make sense, 13 | in term of deployability. 14 | 15 | Keeping in mind a small and concrete goal to achieve by the given ticket description helps you to focus 16 | on the **Acceptance Criteria** that the tickets ask you to complete. 17 | 18 | There is an excellent kata/exercise to train exactly this, it's called 19 | "[Elephant Carpaccio](https://docs.google.com/document/d/1TCuuu-8Mm14oxsOnlk8DqfZAA1cvtYu9WGv67Yj_sSk/pub)". 20 | 21 | ## Agile software development values 22 | 23 | * Individuals and Interactions over processes and tools 24 | * Working Software over comprehensive documentation 25 | * Customer Collaboration over contract negotiation 26 | * Responding to Change over following a plan 27 | 28 | [Manifesto for Agile Software Development](http://agilemanifesto.org/) 29 | 30 | ## Agile software development principles 31 | 32 | 1. Customer satisfaction by early and continuous delivery of valuable software. 33 | 2. Welcome changing requirements, even in late development. 34 | 3. Deliver working software frequently (weeks rather than months) 35 | 4. Close, daily cooperation between business people and developers 36 | 5. Projects are built around motivated individuals, who should be trusted 37 | 6. Face-to-face conversation is the best form of communication (co-location) 38 | 7. Working software is the primary measure of progress 39 | 8. Sustainable development, able to maintain a constant pace 40 | 9. Continuous attention to technical excellence and good design 41 | 10. Simplicity—the art of maximizing the amount of work not done—is essential 42 | 11. The best architectures, requirements, and designs emerge from self-organizing teams 43 | 12. Regularly, the team reflects on how to become more effective, and adjusts accordingly 44 | 45 | ## Extreme Programming Values 46 | 47 | [Extreme Programming](http://www.extremeprogramming.org/) (XP) is based on values. 48 | The rules we just examined are the natural extension and consequence of maximizing our values. 49 | XP isn't really a set of rules but rather a way to work in harmony with your personal and corporate values. 50 | Start with XP's values listed here then add your own by reflecting them in the changes you make to the rules. 51 | 52 | #### Simplicity 53 | 54 | - We will do what is needed and asked for, but no more. This will maximize the value created for the investment made to date. 55 | - We will take small simple steps to our goal and mitigate failures as they happen. 56 | - We will create something we are proud of and maintain it long term for reasonable costs. 57 | 58 | #### Communication 59 | 60 | - Everyone is part of the team, and we communicate face to face daily. 61 | - We will work together on everything from requirements to code. 62 | - We will create the best solution to our problem that we can together. 63 | 64 | #### Feedback 65 | 66 | - We will take every iteration commitment seriously by delivering working software. 67 | - We demonstrate our software early and often then listen carefully and make any changes needed. 68 | - We will talk about the project and adapt our process to it, not the other way around. 69 | 70 | #### Respect 71 | 72 | - Everyone gives and feels the respect they deserve as a valued team member. 73 | - Everyone contributes value even if it's simply enthusiasm. 74 | - Developers respect the expertise of the customers and vice versa. 75 | - Management respects our right to accept responsibility and receive authority over our own work. 76 | 77 | #### Courage 78 | 79 | - We will tell the truth about progress and estimates. 80 | - We don't document excuses for failure because we plan to succeed. 81 | - We don't fear anything because no one ever works alone. 82 | - We will adapt to changes when ever they happen. 83 | 84 | ## References 85 | 86 | ### Books 87 | 88 | * **Extreme Programming Explained: Embrace Change** ([Amazon](https://www.amazon.de/-/en/dp/B00N1ZN6C0/)) [English] by Kent Beck, Cynthia Andres 89 | * **Clean Agile** ([Amazon](https://www.amazon.de/-/en/dp/B07XTL99JQ/)) [English] by Robert C. Martin 90 | 91 | ### Other links 92 | 93 | * [Agile software development- Wikipedia](https://en.wikipedia.org/wiki/Agile_software_development) 94 | * [Continuous Feedback Teams- infoq](https://www.infoq.com/articles/continuous-feedback-teams/) 95 | * [Kata log](https://kata-log.rocks/) 96 | -------------------------------------------------------------------------------- /team-work/agreements.md: -------------------------------------------------------------------------------- 1 | [Back to team work](../team-work) 2 | 3 | # Agreements 4 | 5 | ## We need conventions 6 | 7 | Why? 8 | 9 | * Working with different people mean to have different opinions. 10 | * Different opinions usually end into disagreements. 11 | * Disagreements can potentially end in discussions. 12 | * Recursive discussions generate burns down. 13 | * We should aim to avoid burns downs. 14 | 15 | ## The best way 16 | 17 | The concept of “the best way” or “the right way” depends on who are affected people, and how do they want to use it. 18 | 19 | In the context of software development, agreements should be, indeed, a *must*. Especially having so different 20 | backgrounds, cultures, the way of thinking, experience, readings, and understanding of life. 21 | -------------------------------------------------------------------------------- /team-work/code-reviews.md: -------------------------------------------------------------------------------- 1 | [Back to team work](../team-work) 2 | 3 | # Code Reviews 4 | 5 | ## Benefits 6 | 7 | * It helps to share the changes (and therefore knowledge) with the rest of your colleagues. 8 | * It helps to double-check if the changes are the correct ones or you might have forgotten something important while doing your changes. 9 | 10 | ## Common approaches 11 | 12 | * Pair Programming 13 | * By creating a Pull Request 14 | 15 | ### Pair Programming 16 | 17 | Pairing is the act of two people working together on a single programming problem. 18 | 19 | Pairing programmers sometimes adopt different roles. One may be the driver and the other the navigator. 20 | 21 | Most often, however, there are no roles at all. The programmers are simply co-equal authors sharing the mouse and keyboard in a cooperative manner. 22 | 23 | Pairs are not scheduled. They are generally short-lived. They are often not more than an hour or two. 24 | 25 | Pair Programing shouldn't be just for Seniors to mentor Juniors. 26 | 27 | It shouldn't be mandatory but highly recommended due it's benefits: 28 | 29 | * The members of a team do not work in isolation from each other. 30 | * Is the best way, by far, to share knowledge between team members and prevent knowledge silos from forming. 31 | * It's the best way to make sure that nobody on the team is indispensable. 32 | 33 | While you practice Pair Programming the code it's being reviewed all the time. Two brains think better than one. 34 | Thus, the review is not simply a static check to ensure that the team's coding standards are applied. 35 | Rather, it's a dynamic review of the current state of the code with an eye to where the code needs to be in the near future. 36 | 37 | 38 | ### Pull Request (PR) 39 | 40 | #### Your checklist for a pull request 41 | 42 | * You should cover all new functionality with tests 43 | * You should ensure that all functionality that you touched or modified somehow are covered by tests 44 | * All the tests must be green 45 | 46 | #### Mandatory description 47 | 48 | The purpose of the PR description is to eliminate the dependency on external resources for completing a PR. 49 | External tickets (from Jira, for example) might only contain WHAT has to be done (aka: Acceptance Criteria), 50 | and may or may not contain technical details needed to understand the PR. 51 | 52 | Recommendations for a great PR description message: 53 | 54 | 1. Include Information about what the PR is about 55 | 1. Point to the PR's entry point (if applicable) 56 | 1. Describe why you pick up that solution (if you already tried other ones or it just makes sense to mention them) 57 | 1. Guide with technical inputs related to the PR 58 | 1. In the case of refactoring, justify it 59 | 1. Screenshots for frontend PRs 60 | 61 | The PR description should be like the conversation between the author and the reviewer. 62 | Is the context that the reviewer will read just before start reading the code. 63 | It will provide some background that will facilitate the required understanding to do the review process 64 | smoother and easier for the reviewer. 65 | 66 | Tricks that might help you to put on the shoes of your reviewer colleagues: 67 | 68 | As a non-author dev: 69 | 70 | * What would I like to know before starting reading the code? 71 | * Where should I start reading the code? Where is the entry point in this N files changes? 72 | * Why the author pick this technical solution if there are another N possible solutions? 73 | * Might a picture/screenshot help to clarify some ideas? 74 | 75 | ## References 76 | 77 | ### Books 78 | 79 | * **Extreme Programming Explained: Embrace Change** ([Amazon](https://www.amazon.de/-/en/dp/B00N1ZN6C0/)) [English] by Kent Beck, Cynthia Andres 80 | * **Clean Agile** ([Amazon](https://www.amazon.de/-/en/dp/B07XTL99JQ/)) [English] by Robert C. Martin 81 | 82 | -------------------------------------------------------------------------------- /team-work/documentation.md: -------------------------------------------------------------------------------- 1 | [Back to team work](../team-work) 2 | 3 | # Documentation 4 | 5 | ## Document your knowledge 6 | 7 | 1. Use files (for example as this repository does with the MD files) to document the things that need to be documented 8 | or would be useful to have record somewhere. 9 | 10 | 2. Avoid writing documentation as comments in the code if you can make the code express itself! 11 | More about this topic [here](../technical-skills/comments.md). 12 | 13 | ### Links of interest 14 | 15 | * [Markdown cheatsheet](https://github.com/tchapi/markdown-cheatsheet/blob/master/README.md) 16 | -------------------------------------------------------------------------------- /team-work/estimations.md: -------------------------------------------------------------------------------- 1 | [Back to team work](../team-work) 2 | 3 | # Discourage the use of Story points 4 | 5 | The value you can get using Story points is not worth the energy or the value you can get from it. 6 | 7 | Instead, as an alternative, I would encourage slicing complex tasks into small tasks as much as possible, so in the end, you end up with work of (let's imagine) always 1 SP, so counting SP does not make sense anymore, but rather tasks and the value behind them. 8 | 9 | Additional resources: 10 | - 1.- [Agile Estimating (has an EVIL side-effect)](https://www.youtube.com/watch?v=eamw3jVF_3M) 11 | - 2.- [The BEST part of Agile Estimating. And how to get rid of it.](https://www.youtube.com/watch?v=K6PqofeqoCc) 12 | - 3.- [Agile Forecasting... WITHOUT Estimates?](https://www.youtube.com/watch?v=qAMEK36w2as) 13 | - 4.- [It's time to stop the madness. It's time to stop estimating](https://www.youtube.com/watch?v=go_pLBt8PP8) 14 | 15 | **TL;DR: Smaller Stories. Going small is everything. Aka: Story slicing.** 16 | 17 | #NoEstimates 18 | 19 | --- 20 | 21 | ## Estimations and Story points (deprecated) 22 | 23 | ### Basics 24 | 25 | Good estimations help us to achieve the best possible efficiency within our team and greatly help our Product Managers in the sprint planning process. 26 | 27 | Estimations can be done in different ways. You can estimate time or complexity. 28 | 29 | In my personal experience, I would prefer to estimate complexity, because it helps to pop up the unknowns and uncertainties that each individual of the team has. 30 | 31 | Use fibonacci numbers. This makes it easier to distinguish between complexity levels and to reach a relative estimate rather than a specific "complexity score". 32 | 33 | By estimating tickets constantly teams can over time gather insights on their performance and get a lot more realistic idea of what they can achieve per sprint. 34 | 35 | Even though story points are kind of arbitrary in nature, I will try to give an overview of what they mean to us in the next section. 36 | 37 | ### Story points 38 | 39 | #### 1 40 | 41 | The most basic and least complex kind of task. 42 | Is usually achievable in less than a day by one person without consulting others or doing any kind of investigation. 43 | That change must be straight forward. 44 | 45 | **example:** Changing a few simple lines of code in few files. 46 | 47 | #### 2 48 | 49 | Still, easily achievable without any kind of investigation but requires a bit more professional effort/ knowledge to finish. 50 | 51 | **example:** Adding a new field in an existing API resource. 52 | 53 | #### 3 54 | 55 | A task that requires a certain level of knowledge or investigation to solve but will be pretty straight forward for 56 | a person that is knowledgeable within the specific system/s. 57 | 58 | **example:** Adding a new configuration to a system by reusing and changing existing code. 59 | 60 | #### 5 61 | 62 | This task/problem may involve multiple systems and/or substantial investigation in order to complete it. 63 | Will most likely take more than a day and usually it requires a decent amount of implementation work. 64 | 65 | **example:** Doing a deep investigation in the system with multiple stakeholders and important functionality involved (even if fix is easy in the end). 66 | 67 | #### 8 68 | 69 | A complex task that involves multiple levels of substantial complexity e.g. different systems, uncertainty, lack of knowledge, code complexity, etc. 70 | Will definitely take multiple days and could also usually be split in sub-tasks. 71 | 72 | **example:** Implementing a new complex logic in multiple systems. 73 | 74 | #### 13 75 | 76 | This task has an almost unforeseeable amount of complexity in multiple areas and will take an unknown amount of time. 77 | To many factors of "uncertainty/unsureness" are involved. 78 | 79 | **example:** Investigating a new technology and drafting a concept without knowing if it's even feasible within the system. 80 | 81 | #### (21) 82 | 83 | This basically means the ticket has been poorly defined and should be split. 84 | It is not recommended to use 21 points (or higher) in estimations. 85 | 86 | ### References 87 | 88 | #### Books 89 | 90 | * **Clean Agile** ([Amazon](https://www.amazon.de/-/en/dp/B07XTL99JQ/)) [English] by Robert C. Martin 91 | -------------------------------------------------------------------------------- /team-work/knowledge-sharing.md: -------------------------------------------------------------------------------- 1 | [Back to team work](../team-work) 2 | 3 | # Knowledge sharing 4 | 5 | ### Follow the news of your stack 6 | 7 | Nowadays every stack have its social media account, and you should be aware of that for some reasons: 8 | 9 | * New version releases with dates and change logs. 10 | * Development status of that tool. 11 | * Easy communication with the people behind. 12 | 13 | ### Tech talks 14 | 15 | For bigger development-teams, it makes sense to share their knowledge time-boxing some time for them in order 16 | to talk and discuss any recently tech-related discovering or learned topic. 17 | 18 | ### Writing blog-posts 19 | 20 | It helps to the team members to consolidate and share with the external world some interesting tech-topics, as well within their team. 21 | 22 | An option for this it might be having your own [Medium account](https://medium.com/@chemaclass). 23 | 24 | ## References 25 | 26 | * [How to improve your tech-talk (or any other presentation)](https://medium.com/@chemaclass/how-to-improve-your-tech-talk-or-any-other-presentation-c2adbd3dc8b) 27 | -------------------------------------------------------------------------------- /technical-skills/README.md: -------------------------------------------------------------------------------- 1 | [Back to the index](../README.md) 2 | 3 | ## Technical skills 4 | 5 | | | | 6 | |-----------------------------------------------------------|---------------------------------------------------| 7 | | [Comments](./comments.md) | They are not always updated | 8 | | [Decoupled business logic](./decoupled-business-logic.md) | Abstraction, concretions, layers and dependencies | 9 | | [Final Classes](./final-classes.md) | Composition over inheritance | 10 | | [Functions](./functions.md) | They should be small | 11 | | [Git Mastering](./git-mastering.md) | The best software version control | 12 | | [IDE](./ide.md) | Know your IDE | 13 | | [Immutability](./immutability.md) | It makes the code more predictable | 14 | | [Meaningful Names](./meaningful-names.md) | It should tell you why it exists and what it does | 15 | | [Minimum Scope](./minimum-scope.md) | For your variables, methods, and classes | 16 | | [Performance Tips](./performance-tips.md) | Use strict comparison | 17 | | [Strict Types](./strict-types.md) | Use strict_types constant when possible | 18 | | [Static Analysis](./static-analysis.md) | Identify bugs in your code | 19 | | [Testing](./testing.md) | Test what your software does | 20 | -------------------------------------------------------------------------------- /technical-skills/comments.md: -------------------------------------------------------------------------------- 1 | [Back to technical skills](../technical-skills) 2 | 3 | # Comments 4 | 5 | When we think about comments in code, we have in mind comments that explain what code is doing. The problem with comments is that they are not always updated. Very often the code is changed but the old comments remain the same. So, the comments don’t reflect the code anymore. 6 | 7 | In time, code is moved from one location to another, it is refactored, split, and moved. Even if the code location is changed, the old comments remain in the same location. In time, we end up with comments that don’t reflect reality and the code around them. 8 | 9 | The hardest thing to do is to educate developers and make them understand that comments are part of the code. And, the moment the code is changed, the same thing should happen with the comments. But because of time pressure or indifference, we end up with outdated comments that don’t reflect reality anymore. 10 | 11 | We need to think of comments like documentation. It is an expensive artifact that needs to be maintained. Because of this we should add comments only in location where it is necessary and code itself cannot express what is happening there. 12 | 13 | ## Bad example of comments 14 | 15 | ### Ugly code 16 | Often comments are used in locations where code is ugly, and they are used to ‘fix’ the code. Don’t try to make a code more beautiful by adding comments. When you have an ugly code you should refactor it and write it in a way that expresses what you are doing there. 17 | 18 | ### Code explanation 19 | When you have a code that cannot be understood, then comments are not the solution. Try to rewrite the code or rename fields and other elements in a way that the reader will understand the action that you are doing there. 20 | 21 | In many cases, you can extract a method with a mindful name. The reader will understand very easily what is happening there based on the methods and fields name. 22 | 23 | ### Mumbling 24 | Adding comments into the code only because you think that is necessary is a bad thing. Often it happens that somebody adds comments in code only because he thinks that it is good, without a real background. In the end we end up with a lot of comments that are not useful and make code more difficult to read and understand. 25 | 26 | ### Redundant 27 | When you have a good name for your field or method, you no longer need a comment that describes what the scope of that field or method is. For example a method that is named “SendEmail” doesn’t need any additional comments when it is called. It is clear from the name of the method that an email is send. 28 | 29 | Another good example is a field called ‘vatValueForCurrentOrder’. From the name of the field it is pretty clear what value is stored in this field. You don’t need a comment that says “The value for the current order is stored”. The comment in this case doesn’t add valuable information. 30 | 31 | ### Misleading, Mandated and Noise 32 | In many cases, developers don’t express what they intended to do. Because of this you can end up with a comment that says that an email is sent to the customer, but you end up debugging and trying to understand why the email is not sent. 33 | 34 | In the end you realize that the method that is called under that comment doesn’t send an email, only constructs the email object. 35 | 36 | Usually in big companies and projects you end up with rules that require each method and class to have comments. You end up with a lot of comments that don’t add a real value. They are added by developers only because it is required. For example a property called “Id” had the following comment “Gets, sets the id of the current object”. No useful information is added by this comment, only additional 3 lines of comments that pollute the code. 37 | 38 | What about commenting a constructor – “Construct an instance of object Foo”. Come on, it is clear what the scope of a constructor is. In general, constructors should never be commented. 39 | 40 | ### Journal 41 | 30 years ago, when source control wasn't used on every project maybe it was a good idea to write in the code the journal of code changes (when, what, why, who – changed the code). But now, with source control and other tracking mechanisms, there is no point to do this. 42 | 43 | Using a source control system you can see and track all the changes that happen on the code. 44 | 45 | Position markers 46 | 47 | Try to avoid using position markers into your code. For example adding `/////////` into the code to find more easily a specific part of the code. 48 | 49 | ## Good example of comments 50 | 51 | Yes, there are cases when comments are useful and can add value to our code. 52 | 53 | ### Legal and Informative 54 | There are cases when you need to add a comment because of the legal reason. The code can be under specific license terms and this needs to be specified. In this case you should add a comment that specifies this thing, but without adding all the license terms to it. You can point from the comment to a specific document or url link that describes the license terms. You don’t want to have 200 lines of comments with this information. 55 | 56 | There are cases when a comment can add value to a code. For example when we give more information about what is returned by a method. Be careful, there are cases when a good name of a method can remove the necessity of comments related to return value. 57 | 58 | ### Intention and Clarification 59 | A comment is always useful to express an intention. It is not important to comment what we have done in the code, because the reader can see the code itself. It is more important to explain what we wanted to do in the code. 60 | 61 | There are cases when we cannot express exactly what our intention is. Because of this we need to add comments that add more clarification and explain why we didn't take a specific action. Maybe there is a bug in an external library that we had to avoid, or the client had an odd request. 62 | 63 | ### Amplification and Warning 64 | There are times when we know that some lines of code are very important, and without them the application could crash, for example. In these cases, comments could warn other developers about the importance of those lines of code. 65 | 66 | A good example is a mutex variable that is used to access a shared resource. Maybe not all developers would understand the importance of that mutex, and a warning is needed. 67 | 68 | ### API Documentation 69 | All public API intended to be used by external clients and developers should be documented very well. Since they will not be able to see the implementation, the naming of different functions and classes in combination with comments should express very clear what the purpose of each method is and how it should be called. 70 | 71 | ## References 72 | 73 | ### Books 74 | 75 | * **Clean Code** ([Amazon](https://www.amazon.de/-/en/dp/0132350882/)) [English] by Robert C. Martin 76 | 77 | ### Other links 78 | 79 | * [Todaysoftmag](https://www.todaysoftmag.com/article/1120/clean-code-comments-and-formatting) about comments 80 | -------------------------------------------------------------------------------- /technical-skills/decoupled-business-logic.md: -------------------------------------------------------------------------------- 1 | [Back to technical skills](../technical-skills) 2 | 3 | # Decoupled business logic 4 | 5 | > Abstraction, concretions, layers, and dependencies. 6 | 7 | ## Your business logic should be decoupled 8 | 9 | Don't couple your business domain logic with any infrastructure code. 10 | 11 | **Infrastructure code is everything that has nothing to do directly with the logic of your business**. What is NOT business logic? 12 | 13 | - the framework that you are using 14 | - the connection to the database 15 | - the I/O system 16 | 17 | All of these are irrelevant details that should not be attached to your business logic. 18 | 19 | > In order to accomplish this goal, we should depend on abstractions (interfaces) instead of concretions. 20 | 21 | ## A complete application consists of three major layers 22 | 23 | - Domain 24 | - Application 25 | - Infrastructure 26 | 27 | ### The (business) domain layer 28 | 29 | The domain layer contains the domain entities and stand-alone domain services. 30 | Any domain concepts (this includes domain services, but also repositories) that depend on external resources, are defined by **interfaces**. 31 | 32 | ### The application layer 33 | 34 | The application layer contains the implementation of the application services. 35 | These services shouldn't have "business logic" in them, even though they orchestrate the steps required to fulfill the commands imposed by the client. 36 | The main difference between the domain and the application services is that domain services hold domain logic whereas application services don’t. 37 | 38 | ### The infrastructure layer 39 | 40 | The infrastructure layer **contains the implementation of the interfaces from the domain layer**. 41 | These implementations may introduce new non-domain dependencies that have to be provided to the application. 42 | Usually, the infrastructure layer is where all non-relevant-to-your-domain-details are placed. 43 | 44 | ## Benefits 45 | 46 | - Easy **testability**. When your business logic depend on abstractions (interfaces) you can easily create unit tests for all possible combinations of its behavior. 47 | - Your business logic became **easy to be replaced** and to be adapted to the new requirements. 48 | - **Loosely couple** with infrastructure code. When your logic depends on abstraction, you can postpone the details to the end and rather focus on the business requirements. 49 | 50 | ## References 51 | 52 | - [Advanced Web Application Architecture | Matthias Noback](https://leanpub.com/web-application-architecture/) 53 | -------------------------------------------------------------------------------- /technical-skills/final-classes.md: -------------------------------------------------------------------------------- 1 | [Back to technical skills](../technical-skills) 2 | 3 | # Final classes 4 | 5 | ## Motivation 6 | 7 | ### Reduce the scope visibility to the minimum 8 | 9 | When you see a class prefix with the `final` keyword you will be sure that this class is not extended by any other in the code, which makes it more readable. 10 | 11 | ### Help and encourage our "composition over inheritance" mentality 12 | 13 | If there is any reason why we would like to leave a class non-final: remove the `final` keyword, or don't add it. 14 | 15 | Any reason meaning: being aware we want to keep open a class to be extendable. 16 | 17 | ## Why is this class not final? 18 | 19 | If we aim for composition over inheritance, then we should try to avoid inheritance as much as possible, and use it only when it's really necessary. Inheritance is often misused in OOP. 20 | 21 | ## Misconception 22 | 23 | When we first taught OOP, we usually introduced the classic inheritance example. 24 | 25 | Nonetheless, when [Alan Kay](http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html) created Smalltalks, the inheritance is never the main concept of it. The main concept is messaging, which is you can send message to object and object encapsulate the data and logic in it, and we can change behavior by using different object, which actually is, composition. But the concept of inheritance is too popular that eventually overshadow composition. I think part of the reason is inheritance introduce an abstract layer from real world to explain object’s relation, which can make the code really easy to understand if we use it properly. 26 | 27 | ## Benefits 28 | 29 | - Clear contracts; using interfaces will force you to think in the term of communication between objects. 30 | - Isolated, side effect free code units; injecting interfaces only as dependencies will remove every nasty side effect around the code you are working on; changing an interface implementation won’t affect other concrete classes since they depend only on the interface abstraction. 31 | - Testability; mocking dependencies is extremely easy when they are interfaces; no more “I forgot to disable the constructor / mock a concrete method” troubles in your System Under Test. 32 | - Low, manageable complexity; as everything is isolated, you won’t need to worry about rippling changes; this dramatically decreases the complexity of your code. 33 | - Low cognitive load; with decreased complexity, your brain will be free to focus on what matters. 34 | - Code fluidity; removing any unnecessary coupling, you will be able to move things around way more easily than before. 35 | - Confidence in yourself; being able to test your code in isolation so well will give you a wonderful sense of confidence in changing it. 36 | 37 | ## Composition over inheritance 38 | 39 | - If you feel the need to reconfigure an object, to change parts of an algorithm, to rewrite part of the implementation, consider creating a new class instead of overriding an existing class. 40 | - If you need to represent a hierarchy of classes, where subclasses are proper substitutes for their parent classes, this would be the classic situation where you may still consider inheritance. However, the result may still be better if you don't inherit from concrete parent classes but from abstract interfaces. 41 | 42 | ## What you should start doing instead 43 | 44 | - use interfaces to define the contracts between your classes. 45 | - use final classes to implement behavior for those interfaces. 46 | - use composition (through constructor dependency injection) to put things together and prevent complexity. 47 | 48 | ## References 49 | 50 | - [Final classes by default. Why? - Matthias Noback](https://matthiasnoback.nl/2018/09/final-classes-by-default-why/) 51 | - [Inheritance is evil. Stop using it - Codeburst](https://codeburst.io/inheritance-is-evil-stop-using-it-6c4f1caf5117) 52 | - [Why inheritance is bad- Neethack](http://neethack.com/2017/04/Why-inheritance-is-bad/) 53 | - [When to declare classes final - Ocramius](https://ocramius.github.io/blog/when-to-declare-classes-final/) 54 | - [Why is using final so bad? - Stackexchange](https://softwareengineering.stackexchange.com/questions/89073/why-is-using-final-on-a-class-really-so-bad) 55 | - [Is inheritance a bad practice in OOP? - Quora](https://www.quora.com/Is-inheritance-bad-practice-in-OOP-Many-places-that-teach-design-patterns-say-to-opt-for-composition-over-inheritance-but-what-about-when-multiple-classes-share-logic-from-an-abstract-class-such-as-in-the-Template-Method-design-pattern) 56 | - [Final classes in PHP | Java | Any - Chemaclass](https://chemaclass.com/blog/final-classes/) 57 | -------------------------------------------------------------------------------- /technical-skills/functions.md: -------------------------------------------------------------------------------- 1 | [Back to technical skills](../technical-skills) 2 | 3 | # Functions 4 | 5 | > Functions should be small 6 | 7 | ## Argument objects 8 | 9 | When a function seems to need more than two or three arguments, it is likely that some of those arguments can be wrapped into a class of their own. In such cases, group them within a class: 10 | 11 | ```php 12 | // Bad 13 | function makeCircle(double $x, double $y, double $radius): Circle; 14 | 15 | // Good 16 | function makeCircle(Point $center, double $radius): Circle; 17 | ``` 18 | 19 | ## Have no side effects 20 | 21 | Side effects are lies. Your function promises to do one thing, but it also does other hidden things. Sometimes it will make unexpected changes to the variables of its own class or do unexpected behaviour. Sometimes it will make them to the parameters passed into the function or to system globals. In either case they are devious and damaging mistrusts that often result in strange temporal couplings and order dependencies, or hide some business logic you are missing. 22 | 23 | ## Command/Query separation 24 | 25 | Functions should either do something or answer something, but not both. 26 | 27 | ## References 28 | 29 | ### Books 30 | 31 | * **Clean Code** ([Amazon](https://www.amazon.de/-/en/dp/0132350882/)) [English] by Robert C. Martin 32 | 33 | ### Other links 34 | 35 | * [Object calisthenics](https://williamdurand.fr/2013/06/03/object-calisthenics/) Rules that help you write better Oriented Object code 36 | * [Medium post](https://medium.com/coding-skills/clean-code-101-meaningful-names-and-functions-bf450456d90c) about meaningful names and functions 37 | * [Functions- Clean Code, Episode 3](https://cleancoders.com/episode/clean-code-episode-3/show) By Uncle Bob 38 | -------------------------------------------------------------------------------- /technical-skills/git-mastering.md: -------------------------------------------------------------------------------- 1 | [Back to technical skills](../technical-skills) 2 | 3 | # Git Mastering 4 | 5 | > Using git via the terminal or via your IDE? 6 | 7 | ## Command Tool 8 | 9 | It's true that you can use git with your IDE ([PhpStorm](./ide.md), for example) but you should know 10 | the fundamentals behind these "short-cuts" buttons. 11 | 12 | Double check that you know exactly how the git commands work behind the scene using terminal 13 | before you get use to these button-helpers. 14 | 15 | ``` 16 | git status 17 | git checkout 18 | git diff 19 | git rebase 20 | git pull 21 | git push 22 | git stash 23 | git cherry-pick 24 | ... 25 | ``` 26 | 27 | You can even create your own aliases or use the ones that [omyzh](https://github.com/ohmyzsh/ohmyzsh/wiki/Cheatsheet#git) provide for you. 28 | 29 | ## Git Hooks 30 | 31 | My favorite git hooks are: 32 | 33 | - `pre-commit`: perfect to check the code style and run your unit tests. This one must be fast. 34 | - `pre-push`: perfect to run your integration / functional / e2e tests. 35 | 36 | This way, you will ensure that your "git commit" will have a minimum assert of quality, while 37 | your "git push" will fully pass the CI. 38 | 39 | Anyway, you can easily bypass any "git hook" using the `--no-verify` flag. 40 | -------------------------------------------------------------------------------- /technical-skills/ide.md: -------------------------------------------------------------------------------- 1 | [Back to technical skills](../technical-skills) 2 | 3 | # IDE 4 | 5 | - [Plugins](#plugins) 6 | - [Code Templates](#code-templates) 7 | - [Live Templates](#live-templates) 8 | 9 | ## [PhpStorm](https://www.jetbrains.com/phpstorm/) 10 | 11 | > The Lightning-Smart PHP IDE 12 | 13 | It provides the best code completion, refactorings, on-the-fly error prevention, and more. 14 | 15 | ### Plugins 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 39 | 44 | 45 | 46 | 58 | 63 | 64 | 65 |
25 |

26 | 27 | Php Inspections (EA Extended) 28 | 29 |

30 |
    31 |
  • Architecture related issues
    • 32 |
  • Weak types control and possible code simplifications
    • 33 |
  • Non-optimal, duplicate and suspicious conditions
    • 34 |
  • Validation of magic methods usage
    • 35 |
  • Performance, compatibility & security issues
    • 36 |
  • Github Repository
    • 37 |
38 | 		40 | 41 | Php Inspections logo 42 | 43 |
47 |

48 | 49 | Key Promoter X 50 | 51 |

52 |
    53 |
  • It helps you to learn essential shortcuts while you are working
    • 54 |
  • Its shows you the actions you use the most and directly provides you with their shortcut
    • 55 |
  • Github Repository
    • 56 |
57 | 		59 | 60 | Key Promoter X logo 61 | 62 |
66 |
67 | 68 | ### Code Templates 69 | 70 | They are a built-in templates used each time you create a new PHP class by selecting `New | PHP Class` from the popup menu in one of the project views. 71 | 72 | #### Preferences → Editor → File and Code Templates 73 | 74 | --- 75 | 76 | **`Files` tab:** 77 | 78 | ![Code Templates: Files](../images/ide-code-templates-files.png) 79 | 80 | - Add `declare(strict_types=1);` just after the `modify('+1 day'); 29 | // The original object changed 30 | $dateTime->format('Y-m-d'); // 2019-10-10 31 | ``` 32 | 33 | ```php 34 | // Good 35 | $dateTime = new DateTimeImmutable('09-10-2019'); 36 | $modified = $dateTime->modify('+1 day'); 37 | // The original object remains the same 38 | $dateTime->format('Y-m-d'); // 2019-10-09 39 | // `modify()` returns a new object instead 40 | $modified->format('Y-m-d'); // 2019-10-10 41 | 42 | ``` 43 | 44 | ## References: 45 | 46 | * [Wikipedia](https://en.wikipedia.org/wiki/Immutable_object) 47 | * [5 benefits of immutable objects](https://hackernoon.com/5-benefits-of-immutable-objects-worth-considering-for-your-next-project-f98e7e85b6ac) 48 | * [Why is immutability so important](https://stackoverflow.com/questions/34385243/why-is-immutability-so-important-or-needed-in-javascript) 49 | -------------------------------------------------------------------------------- /technical-skills/meaningful-names.md: -------------------------------------------------------------------------------- 1 | [Back to technical skills](../technical-skills) 2 | 3 | # Meaningful Names 4 | 5 | The name of a variable, function, or class, should answer all the big questions. It should tell you why it exists, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent. 6 | 7 | A variable's name represents what information it contains. 8 | 9 | ## Use intention revealing names 10 | ```php 11 | // Bad 12 | private $d; // elapsed time in days 13 | 14 | // Good 15 | private $elapsedTimeInDays; 16 | ``` 17 | 18 | ## Use pronounceable names 19 | ```php 20 | // Bad 21 | class DtaRcrd102 22 | { 23 | /** @var Date */ 24 | private $genymdhms; 25 | 26 | /** @var Date */ 27 | private $modymdhms; 28 | } 29 | 30 | // Good 31 | class Customer 32 | { 33 | /** @var Date */ 34 | private $generationTimestamp; 35 | 36 | /** @var Date */ 37 | private $modificationTimestamp; 38 | } 39 | ``` 40 | ## Use searchable names 41 | 42 | If a variable or constant might be seen or used in multiple places in a body of code, it is imperative to give it a search-friendly name. 43 | ```php 44 | // Bad 45 | for ($i = 0; $i < 34; $i++) { 46 | $s += ($t[$i] * 4) / 5; 47 | } 48 | 49 | // Good 50 | const NUMBER_OF_TASKS = 34; 51 | const WORK_DAYS_PER_WEEK = 5; 52 | const REAL_DAYS_PER_IDEAL_DAY = 4; 53 | 54 | $sum = 0; 55 | for ($i = 0; $i < self::NUMBER_OF_TASKS; $i++) { 56 | $realTaskDays = $this->taskEstimate[$i] * self::REAL_DAYS_PER_IDEAL_DAY; 57 | $realTaskWeeks = $realTaskDays / self::WORK_DAYS_PER_WEEK; 58 | $sum += $realTaskWeeks; 59 | } 60 | ``` 61 | Sum above is not really useful but at least is searchable. The intentionally named code makes the function longer, but check how easier it will be to find WORKS_DAYS_PER_WEEK than to find all the places where 5 was used. 62 | 63 | ## Class and Variables: always nouns 64 | 65 | Classes and variables should have noun or noun phrase names like `Customer`, `WikiPage`, `Account`, and `AddressParser`. 66 | 67 | Avoid words like `Helper`, `Processor`, `Data`, or `Info` in the name of a class. 68 | 69 | ## Method Names 70 | 71 | Methods should have verb or verb phrase names like `postPayment()`, `deletePage()`, or `save()`. 72 | 73 | When constructors are overloaded, use static factory methods with names that describe the arguments. 74 | ```php 75 | // Bad 76 | $fulcrumPoint = new Complex(23.0) 77 | 78 | /// Good 79 | $fulcrumPoint = Complex::fromRealNumber(23.0); 80 | ``` 81 | 82 | For methods/functions that return a boolean, must be predicated. 83 | For example: `isValid()` or `hasSomething()`. 84 | 85 | ## Pick one word per concept 86 | 87 | When starting to have a huge code base, you and your team might start failing to be consistent in the concepts. That might end up having a `fetch`, `retrieve`, and `get` as equivalent methods of different classes. 88 | 89 | We must use `find` in Repositories and `get` for Entities or Services. 90 | 91 | ## References 92 | 93 | ### Books 94 | 95 | * **Clean Code** ([Amazon](https://www.amazon.de/-/en/dp/0132350882/)) [English] by Robert C. Martin 96 | 97 | ### Other links 98 | 99 | * [Names++ - Clean Code, Episode 2](https://cleancoders.com/episode/clean-code-episode-2/show) 100 | -------------------------------------------------------------------------------- /technical-skills/minimum-scope.md: -------------------------------------------------------------------------------- 1 | [Back to technical skills](../technical-skills) 2 | 3 | # Minimum Scope 4 | 5 | ## Properties and methods 6 | 7 | ### Public | Protected | Private 8 | 9 | * `public`: it will be expose to the outside. 10 | * `protected`: only when you are using inheritance, and you want to have them accesible from the child classes. 11 | * `private`: it should not be expose to the outside. To encapsulate code within its minimum scope. 12 | 13 | ### Best rule of thumb 14 | 15 | Keep to the minimum the scope of your methods and properties. 16 | 17 | ## Classes 18 | 19 | Reduce the scope visibility to the minimum using the `final` keyword. 20 | 21 | When you see a class prefix with the final keyword you will be sure that this class is not extended by any other in the code, which makes it more readable. 22 | 23 | You can read more about final classes in [its own page](./final-classes.md) 24 | 25 | ## Common anti-patterns 26 | 27 | #### Protected by default 28 | 29 | Writing `protected` when there is no inheritance at all. 30 | 31 | > Do not leave `public` or `protected` something unless you know that you will have to expose it to the outside. 32 | 33 | -------------------------------------------------------------------------------- /technical-skills/performance-tips.md: -------------------------------------------------------------------------------- 1 | [Back to technical skills](../technical-skills) 2 | 3 | # Performance tips 4 | 5 | ## Comparison 6 | 7 | Don’t use loose comparison, always be as strict as possible. 8 | 9 | ```php 10 | // Bad: 11 | if ($a == $b) {/* ... */} 12 | 13 | // Good: 14 | if ($a === $b) {/* ... */} 15 | ``` 16 | 17 | ## Using fully-qualified function calls 18 | 19 | When calling functions in a namespaced context, additional actions are triggered in PHP which result in slower execution. 20 | 21 | ```php 22 | // solution 1: 23 | namespace baz; 24 | \foo(); 25 | 26 | // solution 2: 27 | namespace baz; 28 | use function foo; 29 | foo(); 30 | ``` 31 | 32 | ## References 33 | 34 | * [Optimizing PHP Performance](https://veewee.github.io/blog/optimizing-php-performance-by-fq-function-calls/) 35 | -------------------------------------------------------------------------------- /technical-skills/static-analysis.md: -------------------------------------------------------------------------------- 1 | [Back to technical skills](../technical-skills) 2 | 3 | # Static Analysis 4 | 5 | If this is a completely new topic for you, I would recommend you to start with [Psalm](https://psalm.dev/docs/), for example. 6 | 7 | ## Psalm vs PHPStan vs Phan 8 | 9 | ### Psalm 10 | 11 | [Psalm](https://psalm.dev/) is an open-source static analysis tool for PHP that helps you identify both obvious and hard-to-spot bugs in your code. 12 | 13 | Psalm is designed to be useful on both large legacy codebases and small, modern ones. It can help you prevent the vast majority of type-related runtime errors, and also enables you to take advantage of safe coding patterns popular in other languages. 14 | 15 | Lastly, Psalm can automatically fix a number of the errors it finds, allowing you to improve your code without breaking a sweat. 16 | 17 | ### PHPStan 18 | 19 | [PHPStan](https://phpstan.org/) focuses on finding errors in your code without actually running it. It catches whole classes of bugs even before you write tests for the code. 20 | 21 | It moves PHP closer to compiled languages in the sense that the correctness of each line of the code can be checked before you run the actual line. 22 | 23 | ### Phan 24 | 25 | [Phan](https://github.com/phan/phan) is a static analyzer for PHP. Phan prefers to avoid false-positives and attempts to prove incorrectness rather than correctness. 26 | 27 | 28 | ## Standard checks 29 | 30 | Of course, the analyzers perform all the standard checks on the code, to ensure that: 31 | 32 | - there are no syntax errors 33 | - all the classes, methods, functions, and constants exist 34 | - the variables exist 35 | - the hints in PHPDoc correspond to reality 36 | - there are no arguments or variables unused 37 | 38 | Many of these errors inevitably lead to "fatals" in the code. 39 | 40 | You can read more about these three in this Medium post: [PHP static code analysis based on the example of PHPStan, Phan and Psalm](https://medium.com/bumble-tech/php-code-static-analysis-based-on-the-example-of-phpstan-phan-and-psalm-a20654c4011d) 41 | 42 | ## Conclusion 43 | 44 | If you develop with PHP nowadays, it doesn't matter which one do you use, as long as you're using one of them. 45 | -------------------------------------------------------------------------------- /technical-skills/strict-types.md: -------------------------------------------------------------------------------- 1 | [Back to technical skills](../technical-skills) 2 | 3 | # Strict types 4 | 5 | ### Declare strict_types constant when possible 6 | 7 | ```php 8 | To enable the strict mode, a single declare directive must be placed at the top of the file. 16 | > This means that the strictness of typing for scalars is configured on a per-file basis. 17 | > This directive not only affects the type declarations of parameters, but also a function's return type. 18 | 19 | The good thing about declaring a PHP file as strict is that it actually applies to **ONLY** the current file. 20 | It ensures that this file has strict types, but it doesn't apply to any other file in the whole project. 21 | It allows you to do, step by step, this migration from non-strict code to strict code, especially for new files or projects. 22 | 23 | ### Strict types affect coercion types 24 | 25 | Using hint type without strict_types may lead to subtle bugs. 26 | Prior to strict types, int $x meant $x must have a value coercible to an int. Any value that could be coerced to an int would pass the hint type, including: 27 | 28 | - a proper `int` (example: 42 -> 42) 29 | - a `float` (example: 13.1459 -> 13) 30 | - a `bool` (example: `true` -> 1) 31 | - a `null` (example: `null` -> 0) 32 | - a `string` with leading digits (example: "15 Trees" -> 15) 33 | 34 | By setting `strict_types=1`, you tell the engine that `int $x` means `$x must only be an int proper, no type coercion allowed`. 35 | You have the great assurance you're getting exactly and only what was given, without any conversion or potential loss. 36 | 37 | ### Who should care about this "strict type" line? 38 | 39 | Actually, `declare(strict_types=1)` is more for the reader than for the writer. 40 | Why? Because it will explicitly tell the reader: 41 | The types in this current scope (file/class) are treated strictly. 42 | 43 | ### 'strict_types=1' is more for the reader than for the writer 44 | 45 | The writer just needs to maintain such strictness while writing the expected behavior. 46 | That said, as a writer, you should care about your readers, which also includes your future self. 47 | Because you are going to be one of them. 48 | 49 | ## References 50 | 51 | * [Scalar type declarations](https://www.php.net/manual/en/migration70.new-features.php#migration70.new-features.scalar-type-declarations) 52 | * [What do strict types do in PHP?](https://stackoverflow.com/q/48723637/3454593) 53 | -------------------------------------------------------------------------------- /technical-skills/testing.md: -------------------------------------------------------------------------------- 1 | [Back to technical skills](../technical-skills) 2 | 3 | # Testing 4 | 5 | ## Definition 6 | 7 | A test is basically the proof of the expected behaviour of your software. 8 | 9 | ## Common types 10 | 11 | ### Unit test 12 | 13 | - Verify that given an input will expect an output, from a unit perspective. 14 | - A unit is the minimum scope of your code. 15 | - We could agree on a class behaviour or a function itself. 16 | - These tests must be independent of each other. 17 | - They cannot talk to the DB. 18 | 19 | ### Integration test 20 | 21 | - It verifies the behaviour of multiple units together. 22 | - They can talk to the DB. 23 | 24 | ### Functional / End-to-end / black-box test 25 | 26 | - These tests don't care about how but if the ending result of a total is the expected behaviour, without caring at all about any detail implementation. 27 | - They are independent of the DB. 28 | - The importance of these tests is that they are completely agnostic from the software which is running the production result. 29 | 30 | ## Frameworks 31 | 32 | There are plenty of frameworks to write tests, but I will encourage you to first master the most popular one: [PHPUnit](https://phpunit.de/documentation.html). Once you know this one, you will be able to learn any other testing-tool without any problem. Mostly, because almost all of them are based on this one. 33 | 34 | ## Cohn Pyramid 35 | 36 | - The more integrational test -> the slower it will be. 37 | - The more isolated test -> the faster it will be. 38 | 39 | ## Methodologies 40 | 41 | ### Test-Last 42 | 43 | These tests are implemented after the final/production code was written. 44 | 45 | ### Test-First 46 | 47 | These tests are implemented before start writing the final/production code. 48 | 49 | ### Test-Driven Development (TDD) 50 | 51 | Similar to Test-First, with the important remark that the tests will help you to define and refactor the production code while you are implementing the final result. TDD helps you to design an easily testable code because the production code and its tests are written in parallel. 52 | 53 | ## References 54 | 55 | ### Books 56 | 57 | * **Testing y TDD para PHP** ([Leanpub](https://leanpub.com/testingytddparaphp/read)) ([Github](https://github.com/franiglesias/testing-php)) [Spanish] by Fran Iglesias 58 | * **Working Effectively with Legacy Code** ([Amazon](https://www.amazon.es/Working-Effectively-Legacy-Robert-Martin/dp/0131177052)) [English] by Feathers Michael 59 | 60 | ### Medium Posts 61 | 62 | * [The Art of Testing: where Design meets Quality](https://medium.com/@chemaclass/the-art-of-testing-39c6af8c9076) 63 | * [The importance of the tests in our software](https://medium.com/@JesusValeraReales/the-importance-of-the-tests-in-our-software-71c6ca020cf6) 64 | --------------------------------------------------------------------------------