The Plane codebase is a good read. If you want to see a well put together Django + Nextjs project you should check it out. There has been a lot of talk recently about what open source means. To completely side-step that discussion, I have plane starred on github because I learned a lot looking at their code without ever having run it or ever using the product.
I can't speak for the Python part (which another commentator also already did comment on), but I don't think the React part is anything to highlight as "code you should try to imitate".
I just did a quick look, but it seems to suffer from common problems lots of UIs suffer from. Zero tests (unless I missed where they are located), even for things that doesn't even touch the DOM (like the "helpers"). Components filled with heavy logic at instead of being cleanly separated out. Just two examples after a quick 5 minute browse.
That said, I've definitely seen worse codebases and this wouldn't be too hard to work on in a professional setting. Clearly it works for them, and they seem to be progressing, which is good enough. But again, wouldn't flag it as "exceptional" either which you seemed to have done here.
IMHO UI tests are just too difficult to be worth bothering with in most situations.
Maybe AI will change that. But for now I think dev time is generally better invested in other ways of making code work properly, or just fixing bugs that have already been reported.
> IMHO UI tests are just too difficult to be worth bothering with in most situations.
Yes, that's because you're doing them wrong.
Don't mess around with the "golden master" testing (edit: seems the frontend ecosystem call that "Snapshot Testing" actually, but it's the same) you see bunch of projects do, that compare the old DOM vs the new DOM you accept/deny changes based on component render output. That's a waste of time and won't actually prevent bugs.
Instead, extract the logic-heavy parts out from your components, then put those under unit tests, like any other code you write.
Boom, easy to maintain, verifies your implementation and makes your UI easier and faster to refactor and build in the first place.
In an ideal world one might argue that everything testing-worthy (ie. the logic-heavy parts) is already factored out from the UI components but getting to that point either needs a good amount of foresight and discipline or some a lot of refactoring which is difficult to trust without existing UI tests...
You are wrong. Just checked Django part. No annotations, `__all__` in serializers, exists+get instead just calling .first(), etc. It's no way a good Django codebase.
Also noticing copious use of select distinct within the views, which indicates issues with the schema. It may also partially be due to the somewhat limiting API provided by Django Rest Framework, which I personally tend to avoid. All things can be improved though.
Why do you avoid DRF? It's what keeps me coming back to Django over .NET Core or other API stacks (although I have yet to tilt at RoR in earnest/anger).
I just want to start by acknowledging the demo of basic functionality is fantastic and feels very magical, and–perhaps crucially–it has been a couple years since I gave up on DRF completely. With that out of the way, I've run into issues with it when building actual applications. DRF serializers were absurdly slow. Relations were handled poorly. It steers you away from many of Django's standard features, including the forms interface, which is one of Django's best features. The documentation was lacking for rough patches in the API.
It might not be perfect, or live up to whatever expectations you personally possess, but it legitimately is a pretty good example of a clean and straightforward Django application.
This is not the best practice codebase as I wrote it when I was learning Django. But is it very applied. Any beginner should be able to understand this.
Although the structure is fairly good, but I'm always puzzled why testing is so neglected, especially with projects that are popular and - hypothetically - production-ready...
I suppose this mimics real software I've worked on in the past (though thankfully no longer). It seems most of the lessons of software development have fallen on deaf ears despite decades of preaching best practices to each other.
It's all fair criticism. The lessons learned will only take you so far, so the caveat is that if you think it's a bad project then you're already above a certain level. Go you :)
You might take it in the context that they are shipping a real product at a fair speed so where it deviates from ideal what you're seeing is the educated choices of the tradeoffs to make in a real business (which is a statement of the plane team's opinion, yours may vary).
Yes, this! People tend to forget when reviewing code long after it was written, that there is a lot of context around code that isn't "codified".
I remember looking once at a project me and some others got pulled into, where everything was working but the code was spaghetti (which, to be fair, is usually why I get pulled in), and they were having a hard time adding new features without breaking existing ones.
At first, our reaction was the same as many programmers; "Oh my god what have they done and why have they done it like this?!"
Turns out, the company was on the brink of extinction, had about two months of runway left and made this Hail Mary project to attract some new attention and eventually landed them new funding.
So the project was rushed, a lot, but that's OK, but if they didn't rush and wrote super shitty code, the company wouldn't have existed at all. They were OK with this, because they traded "existing today" for "refactoring in the future", which sometimes is the right call to do.
