Technology has made its way into every aspect of our lives, whether it be the devices you use, the tools you work with, or the software you use on a daily basis. Code is everywhere, and billions of lines of code are written daily to build applications that people use on a day-to-day basis. Building an application that stands the test of time has to be planned out, especially when the application is too big to be built and maintained by a single person. Here are seven rules to follow when building an application:
Developers often work in teams, and the members build functionality on top of each other's code. Each developer in your team should write their code in a manner which lets other people use it as well. Writing methods for your own functionality which could have been used in other places as well is usually a bad idea. Every time you write a method be sure to ask yourself, "can this be useful somewhere else too?". If the answer is yes, encapsulate the core logic into common methods and use them in your method instead.
One way to do this is to create extension methods for commonly used data types. They should be available in the namespaces which you intend for them to be useful, and ease of use is an added bonus. A simpler way to achieve this is to have a common area to create these methods which your team can decide beforehand.
On the other hand, too much reusability isn’t a good idea either. The best way to decide whether to modify an existing method or create a new one is to analyze whether the logic you want to add is dependent on the context or not.
The code that you write today may be unrecognizable to you tomorrow. Furthermore, you probably aren't the only one working on the project and others need to understand what you built too. Even if you are working by yourself, you don't want to have to be reading unreadable code. Writing code with good variable names, uniform spacing between logic blocks, and formatting it well will serve your future self and your team nicely. Most developers skim through code to understand it, and you don't want to force them to dive deeper just because you decided to name your variables as single letters instead of well-suited words. As the saying goes, "never underestimate the power of good naming conventions".
A good way to tackle this problem is to follow the naming convention of the programming language. You can solve the formatting issue (which usually creates problems in version control if you're not careful) by setting up default formatting rules in your repository. You can also set up an auto formatter in your editor of choice and circulate it among team members to ensure all of you are using the same formatting rules.
Another tip for teams working with version control is to discuss good practices beforehand. Once a commit is made and pushed, it can be tedious (or even impossible) to change the commit message. Good naming conventions for commit messages, branch names, and tags can help improve code readability. Grouping the changes made according to relevance and topics is a good practice too and helps when your commits have to be cherry-picked to production.
Also, be sure not to write code in a single line when it should be on multiple lines, it’s one of the worst habits.
3. Well organized
Projects in teams usually span over a few years, and the organization of your codebase is paramount. Deciding on naming conventions for your files and the structure of your project should be an important checkpoint of your planning process.
A good way to decide the names of objects is to tell the reader what the object is meant for and what type of object it is, all in the name itself. Organizing objects into folders helps too as you can use them to compartmentalize objects used in different areas of your project. You can always use reference repositories that demonstrate good architecture and stay up to date with the latest trends in the industry. A great example of a well-organized and thought-out architecture for an e-commerce solution is NopCommerce.
No matter the size of your application or the userbase for it, you should be writing code that is efficient and can scale. Having a strong understanding of how web applications (or your tech-stacks) work is important and implementing logic that is inefficient can cost you and your company a lot of money, especially when the application scales up.
Frequent code reviews of the codebase and well-thought-out design patterns are a good way to mitigate efficiency-related problems. Load testing your applications can also help you discover any problems as well.
5. Follows conventions and industry standards
Although it’s been stated in previous sections, it cannot be reiterated enough. Following conventions can save you a lot of time as the problems you are going to face in terms of semantics have already been solved by the creator of the language or the community. It’ll also save you onboarding costs as the developers you hire off the market have probably been using the industry standard in their previous place of employment. If you use tools like Resharper or CodeMaid, you can use them to help you name and organize your code according to the conventions too. Click here for more examples of C#.
6. Staying up to date
Technology changes by the second, but you don't necessarily need to play catch up. Planning the architecture according to the versions of the libraries and frameworks you are intending to use is a good start. It’s always better to start with the latest version so that you have good support throughout the lifecycle of your project, but not too new so that there isn't any support from the community and half the functionality is still being patched up. Keep in mind that the latest versions do have better support and more features, but wait a few months before you pounce on a new library and start using it in a mission-critical process. Click here to find out more about the latest and supported versions for .NET.
If you are on the other side of the spectrum and are have been maintaining a legacy codebase for 10+ years, migrations could be your solution. Newer frameworks are becoming easier to use and migrate to by the day. Be sure to consider it if your team is spending more time weaving around the delicate balance of the framework instead of handling business logic.
7. Make room for more
Requirements can change, bugs can mandate a change in business logic, and your application's design should be able to accommodate it without any drastic changes. Design an application and your code blocks in such a way that they work fine as they are but can be easily changed when the situation demands it. It might require some extra time now to implement it in this way, but it might save you time in the long run.
The best way to go about this is to prototype a feature before you start building upon it. Plan and build the architecture for your application so you know where everything is supposed to go, and then start building the innards.
Implementing all of the above can be challenging at first so try implementing them into your project one at a time if needed. If you need help with your solution be sure to contact us.