2

I am developing a web application for my coworkers, and from a little management app it is becoming a more and intense large project that is involving more people as I go. I am pretty sure my boss will ask me to add even more as I will go on.

So I became unsure if I am doing things right, because I never worked on large projects (actually this is my first job).

The webapp I am working on is used by my company so I cannot do edits and changes while they are working on it; I will obviously expose them to some bugs and ux issues that could be deadly, like adding wrong data in databases etc. etc. etc.

So in the last months I "divided" my web application in two directories; one is the main index.php where they work, the other is the "development" directory, in the same server, which is only used by me.

When I finish all the edits and changes, I move everything in the development directory to the main directory used by my coworkers.

But I ask myself: is this a proper way to develop and test web apps? Lately I had been caught in terms like "continuous test driven development, unit-testing, sandbox development, etc." and moreover, making little changes in my code and uploading it every time to see what happens doesn't sound very professional to me anymore.

So how can I understand if this is a proper way to develop web applications? I am not sure even if I need all this testing, since I am the only webdev here.

I know that this can be "too broad" but I don't know any other ways to ask something like that as I know just a few things about web development in a larger scale. This is something that could be answered by a software architect for example, or a senior web dev, but I am the only web dev here.

closed as too broad by Ixrec, Arseni Mourzenko, gnat, Robbie Dee, Robert Harvey Mar 7 '16 at 21:56

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • On the long run having automated tests will save you a lot of time and headaches. So you should look into this and try to implement it. Using a web framework that has this already integrated would be a even better option. (Also this would come with defaults for environments, develop, test and production are common, each with it's own initialization and especially different databases). Also using some version control system like git is more or less mandatory nowadays. – thorsten müller Mar 7 '16 at 10:21
  • Uh, ok, i am using git but just for having a little organization of the releases and to undo some changes here and there but i don't use it that much |: Automated test? A new term there... – MarkWuji Mar 7 '16 at 10:28
  • As long as you are the only developer that's what you mostly do with git. But look into branching, it's a useful feature sometimes. Automated test is just another word for 'test driven' and 'unit tests'. Basically to write some code that runs a part of your projects functionality and sees if you get expected results (instead of doing this manually over and over again, and possibly forget to test something important) – thorsten müller Mar 7 '16 at 10:51
2

In a good environment, you'd have three separate arenas. Each with their own database, so you can work without fear of destroying production data.

  1. Local Dev
    • Nothing leaves your local work station.
  2. Test
    • This is where you upload your changes when you think they're ready to be tested by a business user. You do have a business user test your changes before they go into production, right? (Btw, this is called UAT [User Acceptance Testing]).
  3. Production

The more separated these environments are, the better off you'll be. Having separate environments makes it impossible to unintentionally break prod while you're developing. The Test/Dev environments are "sandboxed" away where any changes you make cannot harm production data. Preferably, Test does not live on the same server as Prod. (I've even seen some put it in an entirely different NT Domain, but that's overkill IMO.) Having separate Dev/test environments is nice because it gives you an opportunity to practice your deployment strategy.

That said, you can absolutely get away with only having 2, a Dev/Test and Prod. It's not ideal, but I've made it work in the past.

TL; DR: 3 environments that can't speak to each other. Dev, Test, Prod.


As for automated tests, I would highly encourage you to watch a few tutorials and practice a bit. I'm admittedly a TDD zealot, but studies have shown that it reduces the number of bugs that make it into production, where fixing them is orders of magnitudes more expensive, while only costing between 15-30% in cycle time (time to delivery). It's well worth the investment in my humble opinion.


One personal note...

Don't stay at this job long. Buff up your resume and go find a company that will invest in you as a developer. The longer you work without the mentorship of a veteran developer, the more bad habits you'll form. Working with experienced people will help you avoid many of the mistakes you're going to make learning all on your own.

  • Thank you especially for the final advice. Actually i am thinking about leaving for a lot of other reasons and this post was made to understand a little bit more what i should do as a developer. BTW i have no idea of how to pratically implement these arenas. No, i don't have someone who tests my program but i have the time to do it on my own (my mind switches off to "break the program" mode >:) ) but anyway i will look for most of the things you wrote. – MarkWuji Mar 7 '16 at 14:13
  • Implementing those things is a bit too broad for the Q & A format, and you don't need to do all of it, but a test copy of the database is a necessity. If you can get that much in place, you'll likely be ok. – RubberDuck Mar 7 '16 at 14:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.