Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Closed 9 years ago.
Improve this question
When developing an application which mostly interacts with a database, what is a good way to start? The application requires a lot of filtering based on user input, sorting and structuring.
The best way to start is by figuring out "user stories" (or "use cases" -- but the "story" approach tends to really work great and start dragging shareholder into the shared storytelling...!-); on top of that, designing the database schema as the best-normalized idea you can find to satisfy all data layer needs of the user stories.
Thirdly, you may sketch layers such as views on top of the schema; fourthly, and optionally, triggers and stored procedures that might live in the DB to ensure consistency and ease of use for higher layers (but, no matter how strongly DBAs will push you towards those, don't accept their assurances that they're a MUST: they aren't -- if your storage layer is well designed in terms of normalization and maybe useful views on top, non-storage-layer functionality CAN always reside elsewhere, it's an issue of convenience and performance, NOT logical consistency, completeness, correctness).
I think the business layer and user-experience layers should come after. I realize that's a controversial position, but my point is that the user stories (and implied business-rules that come with them) have ALREADY told you a LOT about the business and user layers -- so, "nailing down" (relatively speaking -- agility and "embrace change!" should always rule;-) the data storage layer is the next order of business, and refining ("drilling down") the higher layers can and should come after.
When you get to the database layer you'll want to handle the database access via stored procedures. This will help give you additional protection against SQL Injection attacks, and make it much easier to push logic changes to the database layer.
If it's mostly users interacting with data, you can design using a form perspective.
What forms are needed for user input?
What forms are needed for output reports?
Once you've determined that, the use of the forms will dictate the business logic needed to be coded behind the scenes. You'll take the inputs, create the set of procedures or methods to deal with them, and output what is necessary. Once you know the inputs and outputs, you will be able to easily design the necessary functions.
The scope of the question is very broad. You are expecting me to tell what to do. I can only do a good job of telling how to do things. Do investigate upon using Hibernate/Spring. Since most of your operations looks like querying db, hibernate should help. Make sure the tables are sufficiently indexed so your queries can run faster if filtered based on index fields. The challenging task is design your DB layer which will be the glue between your application and db. Design your db layer generic enough so that it can build queries based on the params that you pass to it. Then move on to develop the above presentation layer. Developing your application layer by layer helps since it will force you to decouple the db logic from the presentation logic. When you develop the db layer, assume that not just your presentation layer but any client can call it. This will help you to design applications that can be scalable and adaptable to new requirements.
So bottom line : Start with DB, DB integeration layer, Controller and last Presentation Layer.
For the purpose of discussion, I'm going to assume that you are working with a starting application that doesn't have a pre-existing database. If this is false, I'd probably move the order of steps around quite a bit.
1 - Understand the Universe
First, you've got to get a sense of what's around you so you can really understand the problem that you are trying to solve.
User stories or use cases are often a good starting point. Starting with what tasks the user will try to do, and evaluating how frequently they are likely to be is a great starting point. I like to start with screen mockups as well, with or without lots of hands on time with users, I find that having a screen gives our team something really finite to argue about.
What other tools exist in this sphere? These days, it seems to me that users never use just one tool, they swap around alot. You need to know two main things about the other tools you users use:
(1) - what will they be using as part of the process, along side your tool? Consider direct input/output needs - what might they want to cut/copy/paste from or to? What tools might you want to offer file upload/download for with specific formats, what tools are they using alongside your tool that you might want to share terminology, layout, color coding, icons or other GUI elements with. Focus especially on the edges of the tools - a real gotcha I hit in a recent project was emulating the databases of previous tools. It turned out that we had massive database shift, and we would likely have been better starting fresh.
(2) What (if anything) are you replacing or competing with? Steal the good stuff, dump and improve the bad stuff. Asking users is always best. If you can't at least understanding the management initiative is important - is this tool replacing a horrible legacy tool? It may be legacy, but there may be the One True Feature that has kept the tool in business all these years...
At this stage, I find that things are really mushy - there's some screen shots, some writing, some schemas or ICDs - but not a really gelled clue.
2 - Logical Entities
Or at least that's what the OO books call it.
I don't care much for all the writing I see on this task - but I find that any any given system, I have one true diagram that I draw over and over. It's usually about 3-10 boxes, and hopefully less than an exponentially large number of lines connecting them. W
The earlier you can get that diagram the better.
It doesn't matter to me if it's in UML, a database logical model, something older, or on the back of a napkin (as long as the napkin is shrouded in plastic and hung where everyone can see it).
The earlier you can make this diagram correctly, the better.
After the diagram is made, you can start working on the follow on work that may be more official.
I think it's a chicken and egg question on whether you start with your data or you start with your screens and business logic. I know that you certianly want to optimize for database sizing and searchability... but how do you know exactly what your database needs are without screens and interfaces giving you a sense for the data?
In practice, I think this is an ever-churning cycle. You do a little bit everywhere, and then you change it all.
Even if you don't get to do a formal agile lifecycle, I think you're best bet is to view design as agile -- it will take many repetitions and arguments before you really feel it's "right".
The most important thing to keep in mind is that your first, and most likely 2nd 3rd attempt at designing the database will be wrong in some way. That might sound negative, maybe even a little rash, (it's certainly more towards the 'agile' software design philosophy) but it's important thing to keep in mind.
You still need to do your analysis thoroughly of course, try to implement one feature at a time, but try to get all layers working first. That way you won't have to do to much rework when the specs change and you understand the issues better. One you have a lot of data loaded into a system, changing things becomes increasingly difficult.
The main benefit of this approach is you find out quickly where you design is broken, where you haven't separated you design layers correctly. One trick I find extremely useful is to do both a sqllite and a mysql version, so seamless switching between the two is possible. Because the two use a different accent of SQL it highlights where you have too tight a coupling between the layers.
A good start would be to get familiar with Multitier architecture
Then you design your presentation layer.
In your business logic layer implement all logic
And finally you implement your data access layer.
Try to setup a prototype with something that is more productive then C++ for example Ruby, Python and well maybe even PHP.
When the prototype works and you see your data model is okay and your queries are too slow then you can start using C++.
But as your questions suggests you have more options then data and in this case the speed of a scripting langauge should be enough.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I found around 8 Strenghts and flaws of using APEX over another program(http://en.wikipedia.org/wiki/Oracle_Application_Express), but i am not sure i quite understand WHEN to use it.
From what i understand, if you want a fast and easy-to-use development tool related to Oracle, Apex is your first choice. While if you need a complex solution, APEX won't fit.
I would like to know you guys opinion on this. In my case, i need to know if i should recommand this product or not for a raquetball club. Since it is not a big company, i believe HTML DB would be the best choice because we want as less manipulations as possible once it's implemented. We also don't want the owner of the club to pay a lot of money to get somoeone who can develop updates.
Apex is free, and an oracle XE database is free too. Apex is rapid development.
But what you're asking depends on so much more.
From what i understand, if you want a fast and easy-to-use development
tool related to Oracle, Apex is your first choice.
Is an oracle database already being used?
Easy to use dev tool: yes, sure. But as with anything, it depends on whether you have some experience with it, what the specs and expectations are, ...
While if you need a complex solution, APEX won't fit.
Well,... Would a complex solution be so much less complex in another environment? Just how complex are we thinking? In my opinion, you can go pretty far in apex and adapt it to your needs. it might involve creating templates and plugins to set up a framework, but it is doable. An example would be apex projects whom have been completely integrated with ExtJS. Apex is not the answer to everything too, but it's good. If you'd stay within the Oracle stack for more involved/complex, i'd say the next thing is ADF. Personally, i'm not convinced by that one though. It also has its pros and cons (such as: requiring java knowledge. pro for some, con for others...)
In my case, i need to know if i should recommand this product or not for a raquetball club. Since it is not a big company, i believe HTML DB would be the best choice because we want as less manipulations as possible once it's implemented.
How large is this club? How intense will the website be used?
Is there a DB already? Is it Oracle?
Who has DBA knowledge (even basic)?
Who will develop?
If your specs are up to spec, then much fiddling shouldn't be necessary after the launch.
We also don't want the owner of the club to pay a lot of money to get somoeone who can develop updates
Who will host the server? Who will run it? Who will administrate it? Do you plan to go cloud-based?
I'd almost ventured to suggest PHP may be a good alternative if this is a small project. Those developers may be easier to find and less expensive than an apex/oracle developer. But then again, if you're planning to outsource it may be less of an issue. If your oracle instance would be in the cloud somewhere, you'd even be pretty safe i'd believe...
Really, what options are you trying to compare? You're asking about apex, do you have any experience with it?
Honestly, your question is not so much a question as it is an opener to a discussion. Each technology and database will have its pro's and cons, fans and dislikers.
Personally, i really like apex. It has a lot going for it, especially when you're already invested in the Oracle stack. And it is still growing, getting good support, and great releases with lots of new features.
I can't really say how it must be set up a (reliable) service from the ground up: server and database, doesn't matter how small, you'll need some understanding and knowledge for that. If you just wing it and cross your fingers, you'll burn them somewhere down the line. Same with development. But as far as i'm concerned that goes for any other tech. Unless you outsource those aspects of course.
Etc etc. There is much and more to be discussed this way.
I put a downvote there for these reasons: there is much to be discussed, it isn't really much of a question which has a conclusive answer. And it maybe only could fetch a conclusive answer if you put more specifications up there and get people of the concurrent platforms to respond.
Edit
I'd like to react on Daniel's post.
First I have to say that I am originally a PHP-Developer, and I really like this language and environment. Nevertheless I decided to do an internship this summer, where I am currently working with APEX. Together with another intern I am developing a bigger application, and I hope to give you some useful input. This only covers the development of the application, as I am not really involved in things like database administration and so on (although I have to say that a PHP Webspace with a MySQL Database also isn't to hard to administrate, especially if there are not too many users).
I'm a developer too, and i don't do server and database administration (corporate environment). Not that i haven't dabbled a bit here and there in my spare time, but i digress.
But my experience is that it gets very, very hard to solve tasks which are out of this range. That doesn't mean that you can't get multiple tables in one reports, some joining of tables is also not a big problem, and can be easily achieved. But if your application needs even more than this I cannot recommend APEX, so I totally agree with your rule, that complex applications should be created in another way.
So speaking as a PHP developer, would you even recommend PHP to achieve this? Would it be less or just as complex?
I'd also argue about complexity. I've worked on some large forms, which for me by now means there are more than your average amount of items, some dynamic actions, validations, maybe some custom process(es). I've not encountered extremely complex situations and honestly i'd question who created those expectations. Thinking outside the box may be a virtue at times, but that doesn't mean the box is always bad. Complex mechanisms or pages can maybe be broken down into more easily accomplishable parts. An example would be using modal pages to break it up.
I also think that the slogan with the limited programming experience is only partial true. It is only true if you have only easy applications, as you have already said. I personally also can't stand the mixing between an IDE and "easy to use"-forms.
I agree about limited programming experience: you'll only create the most basic forms and reports, and having almost no experience i'd think you'd shy away from even option pages in fear of breaking something. Same thing goes for even basic db and server administration: i wouldn't like to rely on such a person when there is no experienced backup (but a very small project as is apperently being described might be acceptable).
I too am only invested in the programming side.
It's also not very easy to create new templates and other things, at least in my opinion it would be much easier with other frameworks.
I'd say that the templates make things very flexible and are certainly not hard to use
And maybe even the worst thing: I think that this application is quite buggy. I don't know how many times simple deleting and new creation of a process/page/validation or whatever solved a problem, where you are simply not thinking of this solution.
Wow. I strongly disagree with this. I've maybe encountered one such thing over the course of a year and tons of forms. Not that i haven't heard of some problems on the OTN forums, but usually they had to do with upgrades.
Summary: I would only use APEX if you have application which REALLY fits it. That means just reports and forms, everything which is more results in pain debugging sessions (as this is also not easy in this environment...) and bad maintenance.
It is too bad that there are not that many large, public sites which use apex out there. As far as i'm aware, there are and have been large project involving apex, but those usually are in a corporate environment and thus are never shown off (can't be). I personally believe apex can be pushed a lot further than the basic forms+reports you mention (and i mean basic, because things will usually come down to forms+reports in this context).
Debugging does not have to be a pain though. If you provide enough debug messages and comments in your own code, that will help a great deal. Debugging the page, javascript console, and if needs be an autonomous error logging procedure to be used in your plsql packages,... I'd say there is plenty to help out (and if you're driven to this, you are working on some more complex material, and i assume that you have the knowledge to actually deal with the complexity you've set up).
And interesting point you raise lastly is maintenance though. I'd say a point on which apex should improve a lot is versioning, out of the box. Exports need to be improved so they can be broken up a lot easier.
Wow, look at that wall of text... I could've guessed this would turn out into a discussion.
First I have to say that I am originally a PHP-Developer, and I really like this language and environment. Nevertheless I decided to do an internship this summer, where I am currently working with APEX. Together with another intern I am developing a bigger application, and I hope to give you some useful input. This only covers the development of the application, as I am not really involved in things like database administration and so on (although I have to say that a PHP Webspace with a MySQL Database also isn't to hard to administrate, especially if there are not too many users).
To start we created a few applications, just to get a feeling. Afterwards we started with the easy parts of the application. APEX is really great if you only have to build some reports and forms to edit the entries of the database. It's very fast to create these things with the integrated wizards.
But my experience is that it gets very, very hard to solve tasks which are out of this range. That doesn't mean that you can't get multiple tables in one reports, some joining of tables is also not a big problem, and can be easily achieved. But if your application needs even more than this I cannot recommend APEX, so I totally agree with your rule, that complex applications should be created in another way.
I also think that the slogan with the limited programming experience is only partial true. It is only true if you have only easy applications, as you have already said. I personally also can't stand the mixing between an IDE and "easy to use"-forms. It's also not very easy to create new templates and other things, at least in my opinion it would be much easier with other frameworks.
And maybe even the worst thing: I think that this application is quite buggy. I don't know how many times simple deleting and new creation of a process/page/validation or whatever solved a problem, where you are simply not thinking of this solution.
Summary: I would only use APEX if you have application which REALLY fits it. That means just reports and forms, everything which is more results in pain debugging sessions (as this is also not easy in this environment...) and bad maintenance.
I am posting here as a guest--hopefully, I will create an account. I used O-HTML-DB from its early releases. We built pretty fine apps. I last used it in 2004, having moved to non-development roles.
Since 2007 though, I decided to revisit the tool and found out about APEX. I have since had my own test apps. I disagree with most of what the intern says.
If you have a limited objective (your business need and associated requirements), then your use of APEX will be limited. This is a very robust application, with sophisticated security features (I have been in InfoSec/Cyber since 2009.
Yes, you are correct than claims about APEX not requiring a solid development background are not accurate. You need to have a sound grasp of SQL/PL/SQL, JavaScript. But you c an also take great advantage of OTN, where developers generously share their know-how. When I started with O-HTML-DB, I had never built a DA in a business environment before. I had theoretical SQL skills. I was a Web Developer with a grasp of JavaScrip, training in Java from Learning Tree International (in addition to academics). But I and my colleague (we were two developers) learned a great deal from OTN. We built three Web apps, one of which supported over 6,000 users--just O-HTML-DB!
APEX has taken O-HTML-DB to new dimensions. You do not need to hard-code validations like we did with O-HTML-DB. Of course, you can modify, which requires a sound grasp of SQL/PL/SQL.
Maybe templating is somewhat confusing to many developers, understandably. But as you continue to "play" with APEX, I am sure you'll like it. It can do nearly anything. Only your limited vision will restrict it.
Erick
I'm developing a monitoring system(something like real-time web app). And the question is about system architecture.
Device connects to server and sends information about controlled parameters state. Sever should save information to Database and notify Comet server. Comet server sends message to user saying that new data avaliable. User gets new information.
What's the best way to analyze and save information(create alarm messages if needed) about device state:
Twisted app it self analyzes and interacts with DB(adbapi) and Comet server(Orbited).
Twisted pushes received data to Django(how to push?) and Django analyzes and saves data to DB and sends "NEW" flag to orbited.
Any Your suggestions, if there is a better way.
More information you can find on the pictures below:
This question is fairly open ended. Someone could probably write a dozen pages on each of the options you described, and that much again on a handful of other approaches as a bonus.
Instead of doing that, I'll take an alternate route.
Make sure you have a good understanding of your requirements. Think about which approach is going to be easiest for you (or for the developers on your team) to satisfy those requirements. Take that approach, documenting the overall idea and unit testing everything you write (preferably using TDD).
When you're done, you might not have the optimal solution, but you'll have a solution, and 99 times out of 100 that's indistinguishable from being optimal.
If I do think about your proposed approaches a little bit, then what mostly occurs to me is that they don't differ from each other very much. Your analysis is just some Python code somewhere that you're going to invoke. Whether you invoke it closer to some Twisted-using code or closer to some Django-using code doesn't seem to make a huge difference to the outcome. Perhaps some part of your requirements would make one approach better than the other. However, if you have unit tests and understand your requirements, then I expect you'll actually find it quite easy to switch between those two approaches.
After you've implemented something, you'll have a much better understanding of the trade-offs involved and you'll be in a better position to decide if one implementation is going to work better or worse than another.
Note that unit tests are a pretty essential part of this idea. Without them, you won't really know if you've implemented your requirements, you won't know if your functionality still works after any particular refactoring, and refactoring itself will be harder because your units will not be as well-defined and isolated as they would be if you were doing test-driven development.
I am working on a fat client legacy C++ application which has a lot of business logic mixed in with the presentation side of things. I want to clean things out and refactor the code out completely, so there is a clear seperation of concerns. I am looking at MVC or some other suitable design pattern in order to achieve this.
I would like to get recommendations from people who have walked this road before -
Do I use MVP or MVC (or another pattern)?
What is/are the best practices for undertaking something like this (i.e. useful steps/checks) ?
The most useful step are to create very robust and full set of regression tests, no matter which pattern you choose.
To choose between MVP and MVC, please review their differences in this SO question:
What are MVP and MVC and what is the difference?
If MVP vs. MVC is your main problem, you can probably choose freely.
There are three factors affecting that decision: your previous experience, support of your framework/libraries, and which fits the existing code base better.
In my epxerience both patterns fit on C++ legacy applications like cat puke on a wedding cake. Your main challenges will be:
Not breaking anything. Heck, it's probably not breaking everything
Noticing that you are actually moving forward
Doing that with small changes that don't require a three month rewrite of some components
The remainder is very generic to dealing with legacy applications, not related to the specifics of your question. I'll leave it here since you also have a generic part.
Rewrite vs. Refactor You already stated your decision, so I just put forward the pro rewrite arguments to consider: if you have a clear spec and understand how current users use this app, a rewrite might be faster and cheaper when 30% or more of the code need changes. (This doesn't mean "rewrite everything", this might also mean cutting back the application to logic-only, then planting a new presentation layer on top of it)
Assuming you go for refactor:
Define your goals Why do you need to refactor the app at all? Good reasons could be a lot of new features to be implemented, presentation layer needs to be replaced, or to buggy to remain sane. From that, decide what needs to change, and what can stay the way it is.
You have already picked your goal: MV*. I just want you to think about the benefits for the client and the code owner in the long run.
Read the code. No, really, take your time to get used to the code base. Step through it with the debugger. Try to understand the things involved. Take notes on improvements you think you should make.
Create tests - mostly regression tests for the currently desired behavior. With legacy code bases, they are more often than not manual, so create test protocols that a moron can follow, and try to get hold of a not-so-moron that can run these tests for your from time to time. Try to get some use cases from existing users.
Stick to small, reversible changes If a refactoring step goes wrong, it should be small enough to be thrown away without hesitation. Sometimes, this is not easy, my typical worst case steps are:
- decide which functionality to replace. Make plans how the new code should look like.
- move the existing code behind an interface that also works for the new code
- test
- replace the functionality with your new code
- test
- sometimes, the interface is "final", somethimes you can remove/reduce it
Always improve Don't accept functionality setbacks tha "can be fixed later".
You should take a look at "Working Effectively With Legacy Code" by Michael Feathers. The book outlines how to get your existing code into a test harness, as well as how to safely break the dependencies in the code.
I wish to present the idea of MVC to a bunch of old C++ spaghetti coders (at my local computer club).
One of them that has alot of influence on the rest of the group seems to finally be getting the idea of encapsulation (largely due in part to this website).
I was hoping that I could also point him in the right direction by showing him Model View Controller, but I need to do it in a way that makes sense to him, as well as it probably needs to be written in C/C++!
I realize that MVC is a very old architectural pattern so it would seem to me that there should be something out there that would do the job.
I'm more of a web developer, so I was wondering if anybody out there who is a good C/C++ coder could tell me what it is that made the MVC light switch turn on in your head.
Don't start off with MVC. Start off with Publish / Subscribe (AKA the "listener" pattern).
Without the listener pattern fully understood, the advantages of MVC will never be understood. Everyone can understand the need to update something else when something changes, but few think about how to do it in a maintainable manner.
Present one option after another, showing each option's weaknesses and strengths: making the variable a global, merging the other portion of code into the variable holder, modifying the holder to directly inform the others, and eventually creating a standard means of registering the intent to listen.
Then show how the full blown listener can really shine. Write a small "model" class and add half a dozen "listeners" and show how you never had to compromise the structure of the original class to add "remote" updates.
Once you get this down, move the idea into to the "model view" paradigm. Throw two or three different views on the same model, and have everyone amazed on how comparatively easy it is to add different views of the same information.
Finally discuss the need to manage views and update data. Note that the input is partially dependent on items which are not in the view or the model (like the keyboard and mouse). Introduce the idea of centralizing the processing where a "controller" needs to coordinate which models to create and maintain in memory, and which views to present to the user.
Once you do that, you'll have a pretty good introduction to MVC.
You might find it easier to sell them on the Document/View or Document/Presenter patterns. MVC was invented on Smalltalk where everything about the different UI elements had to be coded by the developer (as I understand, never used the thing). Thus the controller element was necessary because didn't have things like TextElement::OnChange. Now days, more modern GUI API's use Document/View but Document/Presenter is something I've seen proposed.
You might also consider reading Robert Martin's article on the TaskMaster framework.
You might also consider that any C++ developer who is not familiar with these patterns and already understands their purpose and necessity is either a complete newb or a basket-case best avoided. People like that cause more harm than good and are generally too arrogant to learn anything new or they already would have.
Get some spaghetti C++ code (theirs?), refactor it to use MVC, and show them what advantages it has, like easier unit testing, re-use of models, making localized changes to the view with less worry, etc.
I feel the need to refactor my old CF5 based code into CFC's. We already have some code in ColdSpring and Transfer but feel a large rewrite to ColdSpring and Transfer is pointless.
What tips, approaches and gotchas will I hit.
How can I make this easy?
I don't mind keeping ColdSpring in the mix but Transfer is the bit I'm scared of with the size of the project.
edit: my code base has been going for 7-8 years and is vast. To describe it would be difficult, however I'm looking for generic suggestions on approaches
Changing the whole code base just for the sake of it if it basically works would be introducing a lot of potential bugs into your system. I don’t think there is an easy way to do it.
If you look at the areas of your site which are 1: most likely to change and 2: executed the most you may be able to target some areas which could benefit from change and see how easily they would fit into a CFC based framework, and what benefits. But for most of the code if it is working OK, there may be no pressing need to change.
However whenever you need to do a major alteration to part of the system it may be worth looking at that from an OO perspective and moving the existing code over, where applicable.
In one of my ongoing projects (almost same situation, even more -- most of code is really bad) I am using technique I'd called "wave-style". General ideas I use are following:
Splitting processing from output. I can not implement true MVC here, but at least I can move view into separate templates (sometimes re-use them) and prepare all data in basic (model) templates.
Move all repeating code into components -- this is one of most important tips.
Group related functions into components. Say, all customer-related info grouped into CustomerManager.cfc, invoices into InvoiceManager.cfc etc.
Why "wave"? In a big project I can't just sit and rewrite all customer-related code. So I have make it step by step. For example, I have to work on customer signup, extend it with few attributes. I've created basic component, moved there methods to validate form (check login, email etc.) and add customer - so this page works in new style. Lated I will need to improve invoice page, where I need to get invoice owner details: I just add method into customer manager and get rid of direct queries. Later edit customer page... Also it can be called "on demand refactoring" or smth.
There can be additional stuff relying on your current project state. But it helped me a lot. Hope you'll find these tips useful.
Before you change anything: create a full set of regression tests!
When refactoring, the goal has to be preserve functionality first, so that you don't directly affect your clients.
I agree with Sergii's wave-style refactoring also - this allows you to break things into manageable chunks rather than doing everything in one go.
But whatever method you have, the more regression tests you can create, the better - it's really the only way you can confirm you haven't unintentionally changed something.
This is extremely hard (bordering on impossible) to answer without knowing any of your code.
The question is a bit like "I want to disassemble my old Volkswagen and build a new one from the parts, what should I consider?" :-)
My advice would be to start off by encapsulating your business logic into CFCs instead of worrying about the whole presentation layer of your site.
By just concentrating on the business logic, you'll be able to get the most important functionality into CFCs and ease the maintenance nightmare. It also won't be too hard to just "drop-in" these CFCs into your existing site.
After getting as much business logic into the CFCs as you can, you'll notice that the enormous monster has been cut down to size. At that point you can now decide on what you want to do with the presentation layer of your site. You're now free to pick from a multitude of frameworks available to use (CFWheels, FuseBox, ColdBox, Mode-Glue) to port over the presentation layer.
Or you could just say "the heck with it" and rewrite the whole thing in CFWheels from the start :)
If you are not using version control get that set up before you do anything else. Being able to back out of broken refactoring is a serious life saver. After that I agree with what has been posted. You will want to take on small chunks at a time - divide and conquer.