4 ms·

I work on a 100 KLOC Python project and have written a fair bit of C++ too. We must have different definitions of "all hell from breaking loose", since none of

by dagss 10y ago

I work on a 100 KLOC Python project and have written a fair bit of C++ too. We must have different definitions of "all hell from breaking loose", since none of those tools would help me avoid that in C++ at all. Hell has broken loose when you have an unmaintainable ball of mud, which IMO has little to do with what those tools help with. But for those tools: Many of them you just don't need in Python due to language differences. You need to make sure all branches of your code are somehow tested, but memory management is easier with (mandatory) reference counting, you don't have pointers that are not valid, and so on. As for performance profiles, well, since you're thinking of using Python, you already decided IO is your bottleneck and not CPU. The moment you find yourself thinking "I should profile this code and speed it up" is the moment you consider using another language for the job.

twotwotwo 10y ago
Working on SaaS product with ~150K lines of Python in it (wc lines; there are fewer sloccount lines). Very much agree about maintainability. When the business situation allows it, you need to get around to fixing the annoyances that pop up and bug you. You eventually wind up asking yourself "is it safe to change this behavior?" pretty often. If you do something weird you know needs to be preserved (or know can be fixed after some other fix), comment why. If a piece of code is depended on by some other thing in a potentially unexpected/important way, note that. Of course, you can't always predict what info will be most useful, but at least think of it as you write. You're probably on a team on this size of project. You should make as much outside-the-code info as you can accessible and searchable by as many folks as possible. It can be reasonable to make bugs tracking your work/plans/intentions even if you're the only one working on a change. Write internal docs on how large new chunks of code work. Sometimes writing forces you to sort things out that you didn't even realize were messy when they were just in your head. You can wind up with accidental "ownership" of old and more-difficult-to-safely-update code. Fight this. Try to get everyone working on everything as much as feasible. If you worked on the old code, be clear you don't think it's perfect and encourage improvements to it. If you're looking at other folks' code, if you need to ask silly-sounding questions to help figure it out, do. Relatedly, new folks will need help, especially if they are actually junior, not just new to the product. Do help, and when you help them with a specific problem also help them fish (like, show where they'd go to look for the info you're pointing them towards, and if there's no such place, maybe there should be one). When they think things are strange, pay attention; they aren't inured to your project's weirdness like you inevitably are. Release often, have real QA, and be prepared to be responsive as bugs come up. Releasing often tends to find bugs while the change that introduced them is fresh on the mind. Splitting up large features can help achieve that (we're still figuring this out ourselves, though). It's probably worth running your unit tests in parallel (I've heard of a very large Ruby SaaS product using a cluster). Depending on what kind of stuff you test, you may have to deal with flaky tests. They're one of those annoyances worth working on; you want a test failure to be meaningful. Look for ways to shrink the project. Maybe something can be done by an outside product or library, and let you focus on what only you do. Getting things basically right across a wide range of areas is more important (and harder) than zooming in on a single area like how the code looks. In our world, that means getting operational processes, monitoring, support, feature prioritization, how well folks work together, etc. right, and minimizing walls within the org that would impede that.

by dagss 10y ago

twotwotwo 10y ago

Working on SaaS product with ~150K lines of Python in it (wc lines; there are fewer sloccount lines). Very much agree about maintainability. When the business situation allows it, you need to get around to fixing the annoyances that pop up and bug you. You eventually wind up asking yourself "is it safe to change this behavior?" pretty often. If you do something weird you know needs to be preserved (or know can be fixed after some other fix), comment why. If a piece of code is depended on by some other thing in a potentially unexpected/important way, note that. Of course, you can't always predict what info will be most useful, but at least think of it as you write. You're probably on a team on this size of project. You should make as much outside-the-code info as you can accessible and searchable by as many folks as possible. It can be reasonable to make bugs tracking your work/plans/intentions even if you're the only one working on a change. Write internal docs on how large new chunks of code work. Sometimes writing forces you to sort things out that you didn't even realize were messy when they were just in your head. You can wind up with accidental "ownership" of old and more-difficult-to-safely-update code. Fight this. Try to get everyone working on everything as much as feasible. If you worked on the old code, be clear you don't think it's perfect and encourage improvements to it. If you're looking at other folks' code, if you need to ask silly-sounding questions to help figure it out, do. Relatedly, new folks will need help, especially if they are actually junior, not just new to the product. Do help, and when you help them with a specific problem also help them fish (like, show where they'd go to look for the info you're pointing them towards, and if there's no such place, maybe there should be one). When they think things are strange, pay attention; they aren't inured to your project's weirdness like you inevitably are. Release often, have real QA, and be prepared to be responsive as bugs come up. Releasing often tends to find bugs while the change that introduced them is fresh on the mind. Splitting up large features can help achieve that (we're still figuring this out ourselves, though). It's probably worth running your unit tests in parallel (I've heard of a very large Ruby SaaS product using a cluster). Depending on what kind of stuff you test, you may have to deal with flaky tests. They're one of those annoyances worth working on; you want a test failure to be meaningful. Look for ways to shrink the project. Maybe something can be done by an outside product or library, and let you focus on what only you do. Getting things basically right across a wide range of areas is more important (and harder) than zooming in on a single area like how the code looks. In our world, that means getting operational processes, monitoring, support, feature prioritization, how well folks work together, etc. right, and minimizing walls within the org that would impede that.