So we have a team with 2 developers one manager. The dev server sits in a home office and the live server sits in a rack somewhere handled by the larger part of my company. We have freedom to do as we please but I want to incorporate Kiln DSVC and FogBugz for us with some standard procedures to make sense of our decisions/designs/goals.
Our main product is web-based training through our .NET site with many videos etc, and we also do mobile apps for multiple platforms. Our code-base is a 15 yr old fragmented mess. The approach has been rogue .asp/.aspx pages with some class management implemented in the last 6 years. We still mix our html/vb/js all on the same file when we add a feature/page to our site. We do not separate the business logic from the rest of the code.
Wiring anything up in VS for Intelli-sense or testing or any other benefit is more frustrating than it is worth, because of having to manually rejigger everything back to one file.
How do other teams approach this?
I noticed when I did wire everything up for VS it wants to make a class for all functions. Do people normally compile DLLs for page-specific functions that won’t be reusable?
What approaches make sense for getting our practices under control while still being able to fix old anti-patterns and outdated code and still moving towards a logical structure for future devs to build on?
3
It seems that the dvcs is the smallest part of the problem. I’m not sure if you’re saying you’re not on source control. If not, that’s the first step and Kiln/Mercurial is an excellent choice.
Regarding how to move your code to a managed approach is to step back from your code base and to analyze, refactor and group common sections of code into logical sections. Determine which design pattern(s) will best fit what you’re trying to achieve. Keep in mind a few ideas when designing your new solution. Particularly DRY and loose coupling. Consider brushing up on SOLID. Unit tests would come in very handy here but my guess is you don’t have any. I would suggest writing down logic on how you expect the site to work in specific scenarios, particular the key sections of the site. This way, as you move to the next step, you’re not breaking logic.
Secondly, implement these changes. Many teams structure their code base in a solution with multiple projects. Generally, we use a classic approach where a solution will consist of 3 projects (UI, Business Logic, Data Access). Work to create an abstraction between each layer, particularly between the business logic and data access. Each layer should know very little about the other.
Thirdly, add unit tests to your project. Specifically, unit test key elements of your business logic to confirm everything works as expected. Generally, this is done first. However, since this is a Brownfield project, this is the only approach we have.
Once done, you’ll find adding changes to the site are manageable and predictable.