5 ms·

First of all: PHP is fine. It really is. Second: Doing a full rewrite with a junior team is not going to end well. They’ll just make other mistakes in the rewr

First of all: PHP is fine. It really is. Second: Doing a full rewrite with a junior team is not going to end well. They’ll just make other mistakes in the rewritten app, and then you’ll be back where your started. You need to gradually introduce better engineering practices, while at the same time keeping the project up and running (i.e. meeting business needs). I’d start with introducing revision control (git), then some static testing (phpstan, eslint), then some CI to run the test automatically, then unit/integration tests (phpunit), etc. These things should be introduced one at a time and over a timespan of months probably. I’d also have a sort of long term technical vision to strive against, like “we are going to move away from our home-written framework towards Laravel”, or “we are moving towards building the client with React Native”, or whatever you think is a good end outcome. You also need to shield the team from upper management and let them just focus on the engineering stuff. This means you need to understand the business side, and advocate for your team and product in the rest of the organization. You have a lot of work ahead of you. Be communicative and strive towards letting people and business grow. I can see you focus a lot on the technical aspects. Try to not let that consume too much of your attention, but try to shift towards business and people instead.

yieldcrv 4y ago
the only reason people dunk on php is because of experiences like this from a user perspective seeing a php file extension is an accurate predictor with seeing a disorganized mess of everything and a “LAMP stack” stuck in 2003 just as described here from a developer perspective it’s correlated with everything described by OP you’re correct it isn’t inherently php’s problem, it can do RESTful APIs and a coherent code design pattern no problem
neverartful 4y ago
It's worth re-emphasizing this point: "Doing a full rewrite with a junior team is not going to end well."
- majikandy 4y ago
  Or a senior team.
unity1001 4y ago
> home-written framework towards Laravel I would think about that very long. Over the years, experience has shown me that regardless of what framework or library you use, you introduce a lot of dependencies to your app when you build on such a framework or library. The common sense says that they should make things easier, and at the start they definitely do that. But over the years, you start encountering backwards-incompatible changes, major moves etc in those frameworks and libraries which start taking your time. And sometimes a considerable chunk. I would only use a framework or library that has a major backwards compatibility policy or viewpoint. JSON's 'only add, never deprecate' is a very good ideal to strive to. Even if this couldn't be entirely feasible in software, it should be at least strived to. So I'd say if something that is built in-house works, easy to use and keep maintained, there is absolutely no reason to move to an external framework.
- larsnystrom 4y ago
  I don’t disagree with this :) It absolutely depends on the situation though. Having a foundation which is maintained and (perhaps more importantly) documented properly by a community can be quite powerful. My original point was more about the need for a long term technical vision, because I’ve found this to be an invaluable guiding star as I make smaller decisions along the way. Sometimes I need to change course before realizing this vision, but having a vision still helps. I’d feel like I was stumbling in the dark without this.

yieldcrv 4y ago

the only reason people dunk on php is because of experiences like this from a user perspective seeing a php file extension is an accurate predictor with seeing a disorganized mess of everything and a “LAMP stack” stuck in 2003 just as described here from a developer perspective it’s correlated with everything described by OP you’re correct it isn’t inherently php’s problem, it can do RESTful APIs and a coherent code design pattern no problem

neverartful 4y ago

It's worth re-emphasizing this point: "Doing a full rewrite with a junior team is not going to end well."

majikandy 4y ago
Or a senior team.

unity1001 4y ago

> home-written framework towards Laravel I would think about that very long. Over the years, experience has shown me that regardless of what framework or library you use, you introduce a lot of dependencies to your app when you build on such a framework or library. The common sense says that they should make things easier, and at the start they definitely do that. But over the years, you start encountering backwards-incompatible changes, major moves etc in those frameworks and libraries which start taking your time. And sometimes a considerable chunk. I would only use a framework or library that has a major backwards compatibility policy or viewpoint. JSON's 'only add, never deprecate' is a very good ideal to strive to. Even if this couldn't be entirely feasible in software, it should be at least strived to. So I'd say if something that is built in-house works, easy to use and keep maintained, there is absolutely no reason to move to an external framework.

larsnystrom 4y ago
I don’t disagree with this :) It absolutely depends on the situation though. Having a foundation which is maintained and (perhaps more importantly) documented properly by a community can be quite powerful. My original point was more about the need for a long term technical vision, because I’ve found this to be an invaluable guiding star as I make smaller decisions along the way. Sometimes I need to change course before realizing this vision, but having a vision still helps. I’d feel like I was stumbling in the dark without this.