I'm looking for an experienced and reliable programmer that would be available to support and troubleshoot a .net application recently developed. The application was a tracking system warranty service work for a manufacturing company.
We have change requests on a regular basis.
As well this application was coded to the best standards so i am looking to improve coding standards.
It is a little hard to detail the description of the application or include source code before the successful candidate is chosen.
PLease refer to the broadcast messsage for more details
Most importantly you ? must:
* ? have at least two years experience and be very reliable.?
* ? You must also be someone whose work is organized and professional.
* You must be available on an ongoing basis and averaged 10 - 20 hrs per week
* BE VERY EASY? TO COMMUNICATE WITH ..meaning? online? availablity and someone who can keep us posted as to progress **regularly**?
Please supply references and? and feel free to ask? any questions you may require.
* * *This broadcast message was sent to all bidders on Monday Jun 16, 2008 8:57:38 AM:
Hi and thank for all your bids. There was a lot more replies than i expected.. so it will take a little longer to choose the right person. I have included below a list that was prepapred by the programmer that can no longer work on this project. He listed the kind of changes that need to be done to "tweak" the application. this was originally done by poor coders ...so these are the things that need to be cleaned up :) ============== These recommenations are general so it is not possible to do them overnight, but if development goes according to them the project will be improved.
1. There are lots of hardcoded sql statements throughout the application. Some work was done to gather them in one place which is DataAccessLib. There is a set of data adapters which use either sql in strings or stored procedures calls but what is important they incapsulate database access logic. Probably it makes sense to use some kind of third party data access layer e.g. nHibernate.
2. Interface and business logic are mixed. There are often big control even handlers. Business logic should be moved to separate files. Model-View-Presenter pattern is adviced. In short, we should use as small interface files as possible separating all handling logic in code files. This would make interface changes and business logic testing easier.
4. Full page renewals. The page is often renewed fully though only the little part of it was changed. AJAX usage adviced.
<strike>5. Code duplication.
</strike> 6. There are many places where "style" tag is overused. Use CSS instead. 7. Not enough unit testing. In ideal case, all business logic should be separated and tested by unit tests.
8. Interface elements duplication. Consider using [url removed, login to view] user controls.
9. Direct database connection. Probably it would be better to get data from database by means of web service.
* * *