So I want to do a web app, where to start? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 5 years ago.

Improve this question

As a programmer my first instinct is to start coding, but then again chapter one of every programming book says that you should NOT sit down and code.

So the question is, where to start?

I've given the project some thought, it's going to be a fairly simple web app, kind of a time logging app, to give you an idea.

Even though it's a small project I want it to have great-for-general-public-use quality, and I am willing to even cash out a bit to have a designer do a proper look and feel for the page.

This is a list of things I've thought about:

• It's going to be in ASP.NET MVC

• I want it to have the most dead

  simple log-in (a la Instapaper, but

  possible with option to do OpenID, a la SO)

• Should be able to use it with no log-in too, just session cookie

• It's going to have several "layers" of usability, from very basic, to a more "dashboard" info tracking.

• The webpage should very simple to use.

• Planning on using jQuery for interactivity

• Will use Linq2Sql

• I want to start with the MAIN time tracking function, and then add other tools that not all people might want to use, but that more advance users would like (and no is not feature-ism, they are things that really have to go there for the product I want to do)

• If the page was a little bit successful, I'd like to add mobile apps, so I should have some sort of internal we开发者_开发技巧b API?

So where should I start? Class diagrams? Basic "sketch/design" of the app? Workflow Diagrams? Mission statement?

And what should I do after that? When is "good" to start coding till I fall asleep?

---

This question is a bit subjective but here is a very short explanation of what i do.

I always begin with my data. What do I want to store and how? Then I build my database and indexes.

I then create a data layer project and import my db as a linq2sql class.

Then I decide on the first bit of functionality i want to sign off. perhaps enter a time.

I then write my test cases in a test project. then i make each test pass by writing the code in my data repository layer.

then i write a controller and finally my views.

then i move on to the next story point or piece of functionality

---

but then again chapter one of every programming book says that you should NOT sit down and code.
I'll humbly disagree with those books (which books, btw?).

Sure, if you plan to create a better version of Microsoft Word, you'll need some relevant experience and a bit of consideration. But creating a simple webapp with few pages isn't such a big deal: most web frameworks will already provide architecture carcass for you (like MVC pattern), you just need to 'fill in spaces'.

So, my suggestion is to start with core functionality and grow it bit by bit. Just forget about class diagrams, mission statement and all that crap :)

PS Before you start, it might be useful to check existing applications dealing with this problem: maybe you'll want to borrow some ideas.

---

Which book(s) say that? I don't always agree with that. Also I beg to differ that you should start by data modelling, especially in case of apps that have a web user interface. Here's what I'd do:

• First step Start with UI (prorotyping). Do it in either html or use a tool like balsamiq This will give you (and your end users) an idea what functionality you want in your application. This will drive your data model and your controllers. IMO UI is the most important feature of your app because it will be directly interacting with the user. This notion is often neglected.

• Break down the app into modules if possible. e.g user management(registration, login, logout, roles) timekeeping, admin, etc.

• Design your data classes or data model and data access classes. Again the UI is going to determine what data you want your data access classes to fetch, etc.

• Start doing the UI simultaneously, with controllers. Take on each module one after the other.

• Evolve your design constantly. This also includes the UI. Evolving does not mean put in hacks. If you think you need to re-design, do it.

• Important: Write a bare minimum app (with only the most important fatures) that works well. Build on it.

• Read the 37 signal's getting real for inspiration

So a good time to start coding is "Right Now!"

---

Personally, I'd suggest some pencils and a big stack of paper. Think about your use cases, rough sketch the work flow, then from work flow think about how that be done in UI. Do rough sketches of those UIs, and actually go through the flow via you're paper prototype. Is there going to be some reporting functionality in there? Are you sure you've captured all the data and functionality you want to do this go round? Build a prototype, remember, prototype means something that can be thrown away, so do it in something quick, like rails, or grails, not sure what the analog would be in the .net world, but be sure that you're using good development methodologies, like TDD. Does the prototype suck? No?

Now you're ready for round 2, refactor the prototype to your target technology, if its helpful you can create all the diagrams and such you mentioned earlier. Found something you missed? Go back to step one. But the nicest part, is in the meantime, you have working software that at least doesn't suck, while you're getting the rest going.

Repeat until either you can't stand it anymore, or you're rich enough that you can hire other people to do this for you! ;)

---

Data modeling is essential, but many people prefer to begin by designing the interface first. So sketch out the various interfaces your app needs before you start to code. The interface is your product, and laying down the interface also lets you more clearly define/understand the user story—which you've likely already developed a rough idea of at this point.

This is the basic technique promoted in books like Getting Real, and I'm increasingly convinced it's the best way to start a web app. The data you want to model really depends on what the user wants to do with the app and how they'll go about doing it. If you don't figure out that "how" first, you'll end up designing a really clumsy app and having to redesign your database when you finally define the parameters of the user interaction and redesign the interface accordingly. I've personally wasted a lot of time in this process in the past, which is why I've adopted the interface-first approach.