Embedded Files
.NET is a Framework, or foundation, that gives developers building-block components that makes designing a program easier. At TMW, I used the coding environment Microsoft Visual Studio with the .NET Framework, along with Infragistics and Resharper that also aid with design and debugging. When I would receive a notification that I a JIRA item has been assigned to me, it would typically be a bug within a .NET Project. .NET can support many different coding languages, but my team worked with C# as well as Visual Basic.
One of the first .NET issues I solved with was the "Show Group By Box" function. Multiple different Interface apps have issues with retrieving the correct cell data, as highlighted to the right when it was grouped my more than one column - for example the GL Number and Account Code columns in the top left corner. But, with the apps being very complex, developers have to realize that a change to one component can immediately affect another, like the connection to Customer Information at the bottom of this tab.
Another issue I succeed with, in many different apps, was adding a version check. Not only do apps need license checks to make sure the user has correct access, but since almost all of the apps are linked to SQL databases a version check needs to be added to notify the user of potential data inconsistencies.
The most noteworthy issue I eventually succeeded at was a Database (DB) Concurrency error. This error was reported by QA through a Ranorex testing which automatically executes regression tests and reports back files of issues that occur. Without initially even knowing what the definition of a concurrency error was, I started by debugging the software and pinpointing what line of code was throwing this error. I ended up debugging such error all the way into the TMW DAL or Data Access Layer. At the time since I had access to the layer and realized that's where the issue was occurring, I saw that it was trying to update the Data Base before it would update the deleted cycle of the displayed list. Therefore, I switched two lines of code in the DAL and committed my fix. Little did I know, that I had just changed one of the oldest lower-level solutions in all of TMWSuite. Hence, I ended up breaking the sprint build, more so many other applications relied on the file I changed that I created errors in many other places, rather than just fixing mine.
So, after my mini heart attack from breaking the build, I was driven to ask for help and ended up working closely with the programmer on my team that was most knowledgeable about the solution I was working in. The fix for the issue was not in plain sight for either of us, so I needed to write Unit Tests.
In Visual Studio, I used NUnit with Resharper to add a new test class with multiple test cases to thoroughly check what methods affected which aspects of the interface. After running the tests and printing out some results, I realized a that at the end of the save method a re-retrieve needed to occur to make the database and the displayed list synchronized - and that a higher level DAL was pulling keys instead of IDs. Overall, this experience taught me the value of automated testing, for my broken code could have made it to clients, how to never be afraid to ask for help, the importance of double checking, and the rigorousness of problem-solving required for complex software systems. Now, the automated tests I made to maintain the correct retrieval of data in this application will forever be embedded with the build tests so this level of concurrency error will not happen again.
Google Sites
Report abuse