Programming performance issues can be a frustrating and time-consuming problem for developers. However, tracking down these issues is a crucial step in creating software. Here are some steps that developers can take to track down programming performance issues:
The first thing to do is ALWAYS hook up a profiler to your code, reproducing your issue, and measuring what is causing it. Performance issues are often not obvious and if you don’t profile you’ll waste a bunch of time speeding up things that don’t matter(or just hide the base issue).
Over the years Software Engineering has gone through many iterations of best practices. Form field validation is no exception to this.
The morale of the story here is stop rolling your own validation. This is one of those things that seem super easy to do, so you just quick roll your own and then move on. Except you never move on because you’ll get tickets to fix stuff until the end of time.
Every time I make a file new project I need to add logging – how many times have I spent time figuring out what needs to go where, how to format the error email, and how to log uncaught errors(oh noes!). Too many times. So here is me condensing adding NLog to a web project quickly and easily:
Install NLog.config(and with it NLog) on your web project.
Add these to NLog.config:
Some code smell I came upon today! Exceptions should always be handled in some way, even if just logging it and continuing on(the next person troubleshooting a problem will thank you). Also, exceptions should be exceptional – they are slow and break up code flow; avoid using them for normal circumstances, like bad user input.
try { //do something } catch (Exception e) { }
How important is it that your software runs correctly and to spec? For most software it is of the utmost importance. One of the Joel Test 12 is “Do you fix bugs before writing new code?”. Smart development, testing, and QA help prevent bugs in software.
Fixing Code Before Production and After
Fixing code before it goes to production will save you time. I have had bugs that would have taken 30 seconds to fix before going to production that I spent more than a week on fixing after it went to production because it messed up data in another system.
When building an interface/class, a software engineer should think about how other software engineers are his target customer. This means that the interface should be designed with the needs and preferences of other software engineers in mind.
Here are some reasons why software engineers should consider other software engineers as their target customer when building an interface:
Efficiency in Workflow: Other software engineers will have similar workflows to the developer who is building the interface. The interface should be designed to facilitate efficient workflows, using well-established patterns and conventions to streamline the process.