The process of WEB development
The development of any product can be a huge process and just like any others that you would expect a positive result from, the WEB process needs to be thought out and measured. A lot of developers, especially the junior ones or even the little companies, think that some stages of development are just a waste of time, mainly referring to the planning stage. But this is usually not true because spending time at the initial stages of development can save you almost twice as much in the end. There are lots of variables that affect the process, but the purpose of any management system, especially when the developer is self-managed, is to keep the development process transparent and optimal.
Naturally, there are specific cases or projects in which you need to make changes to even the well thought out and most organized dev processes, but there are constants. In this article, we describe the typical process of development and the recommended approach to it.
Selection of Development Tools
The dev tools selection process is both a preliminary and a one-time thing. This means that you won’t have to repeat it each time you start a new project, but you do need to go through the process at least one time. Fortunately, the times when developers wrote the code in the usual text editor and compiled the projects from a console are things that are long gone. No matter what language you want to build on, there are lots of tools that will help the developer save his or her time, simplify things and suggest the automation of processes that originally distracted them and required a manual interference.
Imagine that a developer makes 40 Git-commits per day. In order to make one commit manually, he or she needs 30 seconds. If we select the proper IDE that supports version control systems–with the help of hot keys–one commit will only take 10 seconds to complete. So in total, the developer saves 13 minutes per day, 1 hour per week or 4 hours per month. And this is just the commit of the code, not to mention the user friendly Git-conflict resolutions, search by project and enormous other different aspects that take much more time than just a simple Git-commit.
There are a huge number of paid and free tools in any sphere of development, so any person can select the one that follows their expectations and financial scope. Never save money on something that would save you money. In our practice, in GBKSOFT, we use the wide range of tools that depend on the programming language:
The software common to everybody:
- Version control system GIT
- Go Git Service as a painless, self-hosted Git service
For web development, developers can select to work in PHPStorm IDE or Netbeans IDE
For Android development, programmers typically use:
- Android Studio with the desired set of plugins
- An emulator that is part of Android SDK
- And the Genymotion emulator, if necessary
iOS developers use the XCode package
The purpose of any type of planning is a project or project documentation to be specific. Project documentation is the number of text and graphic materials used that fully describe the expected result of the development on finishing the project.
During the planning you need to keep in mind several aspects:
- Technical specifications of the project — text description of functionality of future product with as many details as possible
- The scheme of the product components’ interaction: the used solutions, protocols, DBMS, etc
- Prototypes and mockups — interactive schemes of product and its end user.
- Description and interaction schemes with all third party services and solutions, such as the API of payment systems, content distributions systems, etc.
The rule is simple. The more detailed information you have prepared before the actual development begins, the more accurate your estimate and quote will be and the less risky your project becomes.
Here at GBKSOFT, apart from the standard set of technical documentation, we also use:
For UML class diagrams, states and interactions:
- Plantuml with plugins for required IDE
- StarUML as independent software
For initial database structure:
- MySQL Workbench
- SQLiteStudio for mobile databases
Swagger to document the RESTful API
Planning can also include the selection of environment and technologies, as well as calendar planning. In terms of calendar planning and risk management, there are lots of methodologies starting from waterfall and ending with modern scrum. Each developer selects the one that is best for the conditions he is in. In order to select the proper methodology, you need to evaluate the project, client, timelines, budget, etc.
Selection of the environment is more technical and depends on the project type. Since we are experts in WEB and Mobile development, let’s talk about WEB development. Here are the next layers in the environment and technologies of a WEB Project:
- Hosting is a server where the site physically resides, but is also a set of services that keep the project functional, from the server(s) up to the automatic backup and restore systems).
- Web-server is software that’s a direct “successor” of requests from users’ web browsers and is an “allocator” of those requests within the server software. This is what decided on how the user’s browser request should be processed: redirected to one of the existing interprets or processed independently.
Programming language/interpreter is software that usually handles the next functions:
- Receive and process user’s browser data
- Reading of data, its recording and the changes in db
- Generation of dynamic response, depending on what is required and based on user request
Framework and/or CMS:
- To keep it simple, framework is a set of ready functions, modules, classes, etc. that speed up the process of development
- CMS is the ready set of functional modules (website sections and admin panel)
- Database is the storage of different data that are planned to be used within a project
All of those are closely and tightly connected between each other: if you select something from hosting it will oblige you to select the rest among a limited number of other things. In terms of a database, planning often touches the creation of its initial structure.
The process of development can be one of two types:
- Classic — where we take the task, think of a resolution, make it and then test the result, which is nothing overly complicated
- Test-Driven Development — is more complicated (and more expensive), but at the same time, a more reliable approach to development. If you decide to go with it, you first write the tests that would check the developed functionality in the end. After that, you would write the functionality itself. Usually the flow is the next step:
- Developer writes the tests for the functionality he or she develops. At this point, it’s very important that the developer is 100% aware of the requirements for the new functionality or else he won’t write the correct tests.
- Tests are launched. The expected result here would be the failure of tests, because there’s no functionality yet.
- Now, the developer writes the code which is the execution of the direct task to the developer and this code should pass through the ready tests. At this point the task is not to write the perfect code, but to write good enough code.
- Tests are launched again to make sure they all pass.
- Refactoring of the code begins, which is the process of changing the internal structure of the program without touching its external behavior with the aim to make the understanding of its work easier, as well as remove the duplicated snippets of code and make it scalable in the near future. In addition, the test should also get passed in the end of refactoring.
There are so many approaches to the testing of developed functionality, starting from the manual one and ending with the automatic. Each one has its pluses and minuses:
- Manual testing suggests the multiple repeat of uniform procedures. Even though this is probably the least expensive method, it still bares the risk of human error. There is always a chance that the tester missed or forgot SMT.
- Automated testing involves more qualified, quality assurance personnel and raises the expenses for the ongoing modification of automated tests, which is required as a result of change and the adding of functionality. But of course, it guarantees the highest quality.