3 ms·

> class names have been picked carefully Boom. You can stop here. This has nothing to do with PHP or your project. It's just the previous devs were good profe

> class names have been picked carefully Boom. You can stop here. This has nothing to do with PHP or your project. It's just the previous devs were good professionals. This is why "it's easy to navigate and extend". Proper naming is one of the most important tell of a code work well done. You got lucky. But a (good) framework will enforce a reasonable structure that will drive even less skilled professionals in a unperfect but sane direction. It's still possible to take bad decisions, but less often, and the cost of it is reduced.

linoge 9y ago
I don't get why this comment is voted down.
- daanlo 9y ago
  Imho because the poster says: it is possible to have maintainable code without entreprization and the comment says: "that just due to good developers". Which is exactly the point of the post: you don't need entreprization if you follow the basic simple rules.
  - sametmax 9y ago
    Yeah but you see, "entreprization" can help less skilled developers to stay on track and produce maintenable software. It's the difference between flask and django in the Python world. Beginners tend to go for flask. It seems easier. But I actually always recommend Django to beginners, and only flask to experts. Why ? Well, because I've worked on a lot of code bases with both django and flask, and when you don't have good devs, the result with flask is disastrous. Indeed, flask delegates a lot of decisions to the dev, and as a result, if you don't know what you are doing, the project ends up with bad structure and terrible security. E.G: django out of the box rotates your session key, provides csrf token, and en entire auth system. But I've worked last year on a flask project that used unsalted md5 password hashes. Their auth backend returned 403 for most errors in the authentication process, even for bugs, with unrelated 3 words messages. The thing is, if your project is not a success, you don't care. But the goal of a project is being successful, and if it is, less skilled devs will probably have to work on it. Hell, most projects don't even start with skilled devs. The reason is simple: there are too much demand for tech, and not enough devs. So we do with what we have. I mean, I have companies in the silicon valley paying a lot of money for me to work from my bedroom in France because they can't hire the expert they need around them anymore. And when I arrive on a new project, guess what happens ? If it's a framework I know, I can start working on it from day one. If it's not, I'll need time to adjust. It's it's custom, I'll need more time, in direct correlation with the skill level of the other devs that worked on it.
mgkimsal 9y ago
Came here to say something similar. Not sure if you were downvoted or what, but I've inherited projects with function names like "runFunc()" and "doit()" which then have 18 global variables imported, then 1000+ lines of "if(foo=='j' && (barfoo!='f' && foo_old2=='ff') || 7) { // do j stuff v3". You did indeed have a more professional set of folks developing that. I just inherited a small PHP project written 2 years ago: * no version control * running as root on apache 2.2 in /var/www/html * php 5.5 * about 12 "pages" each with a healthy mix of html/php ('header/footer' are abstracted to external incudes) the problem with the 12 "pages" is there's around more than double the logic states and I need to add more. there's a bunch of if($_SESSION['step3done'] && $_SESSION['step3errors']!="") {} interspersed all over the place. Do I continue the pattern? Or refactor? The previous developer would add 'new' stuff in a matter of a few hours, because they'd just expand on that pattern; it's now unwieldy, and I need to add 'new' stuff, and expectations are "a few hours". FWIW, it's probably what I'll do, but am migrating code in to version control, adding items in an issue tracker, and documenting my concerns in tickets, a README, and some code comments. It may come across as a bit passive-agressive, but it's not meant to; just trying to keep a history of concerns while also hitting their short deadline. PHP needs to be upgraded regardless.
- kilburn 9y ago
  Don't worry about the possible "passive aggressive" interpretation. You are doing the best that can be done in your position. If they don't see it... well, that's their problem, not yours. You are already being more than enough accommodating by just accepting to work on such a mess of a project!

linoge 9y ago

I don't get why this comment is voted down.

daanlo 9y ago
Imho because the poster says: it is possible to have maintainable code without entreprization and the comment says: "that just due to good developers". Which is exactly the point of the post: you don't need entreprization if you follow the basic simple rules.
- sametmax 9y ago
  Yeah but you see, "entreprization" can help less skilled developers to stay on track and produce maintenable software. It's the difference between flask and django in the Python world. Beginners tend to go for flask. It seems easier. But I actually always recommend Django to beginners, and only flask to experts. Why ? Well, because I've worked on a lot of code bases with both django and flask, and when you don't have good devs, the result with flask is disastrous. Indeed, flask delegates a lot of decisions to the dev, and as a result, if you don't know what you are doing, the project ends up with bad structure and terrible security. E.G: django out of the box rotates your session key, provides csrf token, and en entire auth system. But I've worked last year on a flask project that used unsalted md5 password hashes. Their auth backend returned 403 for most errors in the authentication process, even for bugs, with unrelated 3 words messages. The thing is, if your project is not a success, you don't care. But the goal of a project is being successful, and if it is, less skilled devs will probably have to work on it. Hell, most projects don't even start with skilled devs. The reason is simple: there are too much demand for tech, and not enough devs. So we do with what we have. I mean, I have companies in the silicon valley paying a lot of money for me to work from my bedroom in France because they can't hire the expert they need around them anymore. And when I arrive on a new project, guess what happens ? If it's a framework I know, I can start working on it from day one. If it's not, I'll need time to adjust. It's it's custom, I'll need more time, in direct correlation with the skill level of the other devs that worked on it.

mgkimsal 9y ago

Came here to say something similar. Not sure if you were downvoted or what, but I've inherited projects with function names like "runFunc()" and "doit()" which then have 18 global variables imported, then 1000+ lines of "if(foo=='j' && (barfoo!='f' && foo_old2=='ff') || 7) { // do j stuff v3". You did indeed have a more professional set of folks developing that. I just inherited a small PHP project written 2 years ago: * no version control * running as root on apache 2.2 in /var/www/html * php 5.5 * about 12 "pages" each with a healthy mix of html/php ('header/footer' are abstracted to external incudes) the problem with the 12 "pages" is there's around more than double the logic states and I need to add more. there's a bunch of if($_SESSION['step3done'] && $_SESSION['step3errors']!="") {} interspersed all over the place. Do I continue the pattern? Or refactor? The previous developer would add 'new' stuff in a matter of a few hours, because they'd just expand on that pattern; it's now unwieldy, and I need to add 'new' stuff, and expectations are "a few hours". FWIW, it's probably what I'll do, but am migrating code in to version control, adding items in an issue tracker, and documenting my concerns in tickets, a README, and some code comments. It may come across as a bit passive-agressive, but it's not meant to; just trying to keep a history of concerns while also hitting their short deadline. PHP needs to be upgraded regardless.

kilburn 9y ago
Don't worry about the possible "passive aggressive" interpretation. You are doing the best that can be done in your position. If they don't see it... well, that's their problem, not yours. You are already being more than enough accommodating by just accepting to work on such a mess of a project!