When I worked on another project, I met an interesting opinion. They say, all the code in the project should be as open as possible by default. I.e. we should make all new methods and fields public, and we should not put final anywhere, except some special cases when it's really necessary. It was motivated with the difficulties of further codebase support:

If I want to inherit the class, and there is a private method, I have to study the code to understand why it was made private and whether I can make it public.

This opinion was very unusual for me, and I decided to figure it out if there is really more problems when fields and methods are private by default.
Let's write an extra public method and see how easy is it to support it.

interface FooInterface {
  public function foo();
}

class Foo implements FooInterface {
  public function foo() {
    // do stuff
    $this->bar();
    // do stuff
  }

  public function bar() {
    // do stuff
  }
}

With this article, I open a rubric "Don't do this." It will contain code from real projects, from which I will remove all references to the projects themselves. And, of course, my explanations of why shouldn't you do this, and the way it should be done.

So, the first patient. Inside the trait, the fields of its descendants are used. I mean something like this:

trait Foo
{
    public function bar(): string
    {
        return $this->field . static::CONSTANT . $this->method();
    }
}

What are the worst mistakes in programming? I would single out two types:

• those that cause a business to lose a lot of money
• and those that are the least common.

While the first ones are immediately clear, what about the second ones? The fact is that the less often we encounter some type of error, the more difficult it is to understand what caused them.

This happened to me at work as well. One morning, the testers noticed that some requests to the backend returned a 502 (Gateway Timeout) error. This bug was a release stopper, so all the senior developers and a devops engineer took it up. At first, it was believed that Nginx returned this error, and the backend had nothing to do with it. After a while, we realized that PHP was to blame. We sinned for everything: turned off the BlackFire, changed OpCache settings, tried different patch versions in PHP, and so on. However, the error itself was not in the infrastructure, but directly in the application code.

When an IT product evolves, there always comes a time when it becomes necessary to bring some new tool into it or replace the old one with something more suitable. While it seems that a lot of articles have been written on the topic of choosing tools, and there is nothing new to say, the question still remains relevant, in some places even sharp.

Here are the most popular approaches:

• Find something hype on the left road
• Take something proven and reliable on the right road
• Go straight ahead and use your favorite tool

They are good because you don't have to think when using them. You just take what you want - and that's it 😃 Well, if there is a need or a desire to approach the issue more seriously - welcome under the cut, we'll figure it out.

There are many architectural patterns in the development world. Some of them we use every day, some - less often. Surely each of you has seen the Singleton and the Factory many times. Many of you have written them on your own. But when I first read about the Builder pattern, at first I did not understand in what situation it can be applied. What is completely ridiculous: I regularly used its implementation (QueryBuilder from the Yii framework), but my eye was so blurry that I could not match the name and functionality of this class and the corresponding design pattern 😂 Of course, after a while it dawned on me. And over more time, a situation was found in which the Builder pattern fit perfectly.