131–139 of 139 posts
Earlier quoted context omitted.
To each his own...
Honestly they both sound horrific. Any code base that large ...
Earlier quoted context omitted.
This is the worst idea I ever heard. This only "works" for companies that have unlimited VC funds to light on fire, for companies who have to actually make money, this is in no way something you can do. This is the equivalent of bulldozing your house and building another because your hot water heater broke.
It works for every company who has software they maintain, and while I’m sorry you don’t think it’s a good idea, I think the issue is more with your lack of understanding than the idea itself. Specifically, your analogy to construction is a bad one - software is not construction, and one critical difference is the cost of rebuilding is many orders of magnitude cheaper. When you include the reality of obsolescence int…
2) If you need to make a profit (and NOT just light someone else's money on fire), you can't afford to just throw away your profitable product(s) and rebuild them because some devs are easily triggered prima donnas who want to whine because "legacy." That's not how business works in the real world.
3) Companies (again, the ones who must make a profit) aren't going to get clients that way. Clients invest in software because the large upfront costs and small maintenance costs will amortize over the many years they intend on using this product. They aren't going to fund rewriting the product from scratch multiple times.
4) Clients are not going to fund a rewrite ever few years because the cost of rewriting is not "many orders of magnitude cheaper," that's a complete and total fiction. I know this because I've participated in ROM estimates for clients.
Of course, if your "business" has unlimited VC funds coming in then its backwards land. But most businesses exist to make a profit, not to spend someone else's money.
Earlier quoted context omitted.
Honestly they both sound horrific. Any code base that large ...
Yep, indeed. Most of my head scratch moments with big code bases aren't about anything as technical as types. It's not as if knowing the types would have made me realize what the code actually does, which is the main hurdle.
Sure it won't do magic with 1MLOC of spaghetti code, but in a reasonably sane codebase it makes it much easier to know which parts to care about and which you can ignore for the time being. Again, that's my experience at least.
Earlier quoted context omitted.
If you read/scan 10 lines a second, you still need over 24 hours non-stop to read a 1M+ code base. I doubt a random file ordering is helpful! Especially if you lose code navigation features like "go to definition".
With the language server protocol, this works reasonably well in Python code bases for me in Emacs.
This is one of the big reasons I prefer static typing. When looking at some unfamiliar code in an unfamiliar codebase, I can reason about the code much faster when I can see what functions return, and quickly go check their types out if the type is unknown. This makes me much more productive. I helped maintain a 250kLOC Python program. I came in when it already at over 200kLOC. I spent so much time , every time, just…
250kLOC Python sounds scary. But that would easily be 1mLOC+ lines in Java ...
With proper usage of spring-data, spring-cloud-stream, spring-* lomboked java code can be very terse. If you follow conventions repositories, rest clients, mappers etc. are often defined only by interfaces and annotations - actual implementations are generated.
The downside is that the entrance to the full blown spring-* world has a step learning curve - there is a lot to read at spring.io.
Are there any visual "code flow" interpreters? Something that would separate the 1000s of interactions between functions and show flow lines between them?
I wrote one for Tcl years ago, as I started working on a really complicated product with around 50k lines of code (or more, distant memory). Maybe I should give it another crack for modern languages - there is an even greater need for it these days with dependency injection and microservices being common. The way I see it the need stems from needing to understand what is REALLY going on, as opposed to what the code i…
This is a great article. I felt like it was describing a job I recently left, especially this piece: > It’s fine to have less experienced people working on a large system as long as they have the elders overseeing their work. In the world where senior titles are handed left and right, that is often not the case and it’s how you end up with a very fragile system that is suitable for a replacement as soon as it was bui…
Use the IDE for intellisense? Great idea except the database models are in a different project... If for whatever reason you can't link the project properly, as a tip for the future, I've ended up just making a separate copy of the project which included a reference to the uncompiled project. And in the worst instance I actually used a reverse generated project from the binary. I actually gradually refactored that au…
This is a great article. I felt like it was describing a job I recently left, especially this piece: > It’s fine to have less experienced people working on a large system as long as they have the elders overseeing their work. In the world where senior titles are handed left and right, that is often not the case and it’s how you end up with a very fragile system that is suitable for a replacement as soon as it was bui…
Gaming company in San Mateo? Lol
It's kind of nice to know that it's a problem everywhere though. Solidarity.
This is one of the big reasons I prefer static typing. When looking at some unfamiliar code in an unfamiliar codebase, I can reason about the code much faster when I can see what functions return, and quickly go check their types out if the type is unknown. This makes me much more productive. I helped maintain a 250kLOC Python program. I came in when it already at over 200kLOC. I spent so much time , every time, just…