When I began programming professionally in the late nineties, sneakernet was a common way to share source code with other developers. Many developers stored versions of their programs’ source in zip files, and merging code was quite a task.
We have come a long way since those dark days, but there are a surprising number of development shops depending on simple file shares.
Even cowboy developers should use a version control system. If someone tosses your computer out the window, or you need an older version of the source code, version control systems make it easy to recover. Of course, you do need to make sure the server is running on a separate system.
It’s the twenty-tweens, and there is no excuse not to use version control. There are plenty of flavors of free systems and tooling to match.
Everything essential to recreate your project should go into version control, and you should implement a regular backup schedule.
Prepare for the worst! Backups should be stored on premises separate from the server. An extinction-sized meteor may not hit your building, but fires and other catastrophes do happen.
The systems administrator mistakenly deleted your version control server, and no one bothered testing the backups to make sure they worked. You’ve lost everything, and the future is bleak.
Instead of rewriting everything, use a decompiler to recover your code. The source will not be a one-to-one comparison, but it’s better to start at 90% than 0%.
If you’re a .NET developer, try out JustDecompile. It’s free for everyone, forever. Best of all, it can generate complete projects from a .dll or .exe.
You may have the superior product, feature-wise, but if it performs poorly, users will abandon it for the competition. Fewer users mean less revenue, and less revenue means you may soon be out of a job.
Application performance issues come in many shapes and sizes, and they cost users tons of time. Use a .NET profiler such as JustTrace to identify the best target for optimization.
A long running but optimized task gives the perception of poor performance if the user is not receiving feedback. Be sure to use asynchronous calls for calls that may run long. No matter what, avoid locking the user interface.
There are many ways to mismanage memory in a .NET application, but you’re at least guaranteed to recover the memory by closing the application. Well, not quite. It is possible to create a true memory leak with unmanaged resources. Even if the unmanaged resource didn’t leak, improper handling of unmanaged resources will cause memory usage to grow during the life of the application.
Do the right thing and clean up unmanaged resources. Release them in finally blocks or by using the disposable pattern.
If your application is unstable due to out of control memory usage, use a memory profiler to identify the culprit. JustTrace does that, too.
Depending on your industry and the type of application you are creating, there are many more tips to consider. Please add your own tips in the comments.
Here’s one final tip: don’t be evil.
CodeProject Chris has saved a project or two, but he will not say whether he has saved any lives. After all, non-disclosure agreements are binding.
Chris Eargle is a Microsoft C# MVP with over a decade of experience designing and developing enterprise applications, and he runs the local .NET User Group: the Columbia Enterprise Developers Guild. He is a frequent guest of conferences and community events promoting best practices and new technologies. Chris is a native Carolinian; his family settled the Dutch Form region of South Carolina in 1752. He currently resides in Columbia with his wife, Binyue, his dog, Laika, and his three cats: Meeko, Tigger, and Sookie. Amazingly, they all get along... except for Meeko, who is by no means meek.