科技回声

About a year ago at my workplace we decided to get into developing a web app for internal use (as part of a more intricate system which is irrelevant to this question). No one really had experience in web development, so probably some of our decisions were wrong, but all in all we've had success with the tool we were developing. Since we did have experience developing in Python, we chose Django as our platform.My question is about "who does what". The way we split our work was: there is one team which handles all the Python code - which means all the Django urls, views and models, as well as the actual backend to handle asynchronous task execution (something a bit like Celery). A different team (more precisely, a single person in a different development group - but this is just implementation) is responsible for the templates (data binding), javascript, design, HTML, CSS, etc.We have been working like this, as I said, for about a year now. I'm starting to think that maybe the line of responsibilities between the two teams is wrong. The reason is that there's a pretty big overhead whenever we need to interact - which is a lot. For example, when we add a new table and we want to display it, we need to let the "frontend guy" know what the url would be and what it would contain. Then we need to integrate out work to see if everything's alright. Sometimes we didn't pass enough context to the template to make it work and there's a slow ping-pong of information between us.So my question is this - what is the accustomed way to split work on web apps? Who takes care of the different modules - models, views, urls, templates, design, user experience, HTML, CSS, javascript? I'd love to know how YOU do it.

I'm not sure if this is helpful, but as a full stack-developer, I still work in a similar structure to the way you've described.Essentially you're talking about two sides of development. Front-end vs. Back-end, and yes, it is very common to split up work like that. I've never heard anybody describe 'modules' as 'models','views','urls', etc. etc. though.A back-end dev, team, or when doing back-end work, you're focused on the server side architecture and code. That would include your models, views, controllers, routes, database, etc.A front-end dev can then take these end-points (routes or URLS) and build the templates, and front-end experience (HTML, CSS, Javascript).I think the problem you may be having is in how you're defining what you're working on. You say specifically 'when we add a new table', but a front-end guy isn't going to know what to do with a 'table'. That is back-end. Both teams should be focusing on the feature or capability you are providing, not the technical structure. So rather than saying to the front-end guy 'we added a table and need a view into that table', you may have more success saying 'we want to show how weather patterns affect our shipping rates' or whatever it is the table does. Then the front-end guy can take your URL and from a user-perspective build a solution which solves the problem.Another thing to consider is that design and user experience is not part of Front-end development. You may have a front-end dev who is good at UX and design, but if so, you'll be very fortunate. Some Front-end devs can do design, but not all. So you may want to make sure that before the Front-end (or even Back-end) guys get coding, they have the design of what they are building. That may help both sides come to the best solution quickest.

Diving into frontend vs. backend is very common and in my experience, a successful strategy. But within reason. To use your example, your backend developers should be able to code an HTML table.

Ask HN: How do you split work on web apps?

2 条评论

Ask HN: How do you split work on web apps?

2 条评论