On Thu, Feb 8, 2024, at 11:15 AM, Григорий Senior PHP / Разработчик Web wrote: > Just because PHPStan is a ready solution for design errors that you can > predict. > My case is about errors that you detect later, after the design is > finished, PHPStan shows you that "all done!". > > Because it's not \LogicExceptions (types, mappings), it's all > \RuntimeExceptions... You have to implement it after the design is done! > Also writing code comments for PHPStan accidentally increases time of > catching \LogicExceptions that will be autocatched once an exception > happens and is reported. This is necessary work, but it increases the > estimate; the business does not want to hear long deadlines, and considers > you ineffective. But if you say too small, the code will not even pass > PHPStan, it will not even pass visual inspection. Therefore, I say some > magical things, and then I correct them, for some reason they like this > approach better, they are not used to improving until everything works > properly, they even push the word into the lexicon - MVP. This means “it > doesn’t work well but it works”, it seems normal to them in order to get > results faster. Because they will receive bonuses for results, but for bad > results you will receive punishment. > > A closer solution is "get out from the job where business was built that > way to ignore complainings". I had worked for 12 years. I've changed a lot > of jobs because of that. And any new job is the same. It could be more or > less ready to build the same, but they are working on it. It's not a > solution either. As a result - "you cant rebuild > non-yours successful business that gives you money because you know how > things work", you have to fix or lose your rent home. > > === > > @Arvids Godjuks <arvids.godj...@gmail.com> > > I had to work in such companies, and there were 13 projects at the moment. > But after some time I realized that nothing depends on the number of > projects. All businesses strive to not give away the right to think to > their employees. If this happened, it was more an accident than a goal. If > they are forced to listen to you, you are considered a problem that they do > not yet know how to solve. > > Now my company has only one project, which they are leading themselves. But > business and profit dictate the conditions - at first we do a year very > quickly, then we redo it for 3 months, which we will have time, but the > amount of legacy is too large, because the pace is insane, and the tasks > are becoming more and more difficult. > > They can't just "wait quietly until you finish." They will ask you when, > and will be disappointed if you suddenly suddenly realized that you need to > move the deadlines, because there are already 5 new ones behind the current > task and they are planned for the quarter. “Rewrite better” is not included > in them. > > Let's stop discussing my personality, I gave a rationale for why languages > should preferably help developers, since such a question arose. Because > there won’t be fewer situations like mine, but there will be more jobs. And > there will be a lot more bad companies, and in the end there will be very > bad ones left.
OK, there's multiple, really unrelated things going on here. Let's cut to the chase: It sounds like the root problem is not code, but management. The OP's management is insisting "make change X to a bad codebase, but we'll give you 1/10 as much time as doing it properly actually needs." That is a social problem, not a technical problem. No software will solve a social problem. In this case, the social problem is "your manager is an abusive moron." Sorry, PHP cannot help you with that, no matter what feature we add. Moreover, adding features to the language to make it easier to write sloppy code that will be harder for the next person to maintain is a losing proposition. It will just compound on itself until both the language and applications written in it are universally trash. PHP has spent 20 years digging out of "quick and easy" design decisions that were made back in the 90s that are still causing problems today. I do not see any appetite for adding more such structurally-poor features. There may be an appetite for adding features that make it easier to write good code that is self-correcting. We can (and do) debate what features qualify for that description, and whether my checked exceptions proposal qualifies for that, but that's independent of "my boss is asking the impossible." It's not the language's job to solve for bad bosses. I think what you're looking for (since your descriptions are not particularly precise) is a customizable version of json_last_error() and friends, which operates on global state. I am only one vote, of course, but based on prior discussions here I don't believe there will be any support whatsoever for a global-state-based error mechanism in PHP, ever. If anything the trend is to move away from that, in part because it makes "hack random shit into random crappy code with more globals" harder. That's a good thing. If that's the case, we should probably just close this thread and potentially move the checked exceptions discussion to a new thread, if anyone else is interested in continuing it. But the original request here is, if I am understanding it, dead on arrival. No amount of talk about bad bosses with poor expectations will change that. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
