Hey guys! Does anyone have an tips on how to pre-plan a library or a program in general?
4 plus ones
Shared publicly•View activity
- Write down the things you want the program / library to haveOct 24, 2013
- Just some general ideas:
- Consider what you want it to provide
- Consider best architecture/language/audience for purpose
- Develop use cases
- Abstract from the concrete as much as possible
- Consider reusability
- Consider objects, properties, methods
- Consider the relationship between objects
- Consider the limitations of your choices
- Build logging/debugging/messaging in from the beginning
- Prototype and validate your ideas before implementing
For myself, I like to head out to a coffee shop and draw my app, the UI, the classes and relationships, and messaging between components. It looks a bit like a UML diagram.
I recently built a first release Excel add-in for a portfolio manager to retrieve somewhat large data sets (50K rows by 85 columns). The PM's requirements were speed, query flexibility, and small UI footprint. This size is not normally a problem, but there are limitations in .NET when dealing with Excel. I have separate libraries for threaded SQL execution, desktop logging - there are better off-the-shelf products like Log4Net - , and query table management. The architecture is Model-View-Presenter since that both works well for this kind of app, but also provides an upgrade path to a Web UI. The Excel UI is a mixture of Ribbon groups and a separate task panel.
I searched to find best methods for dynamic SQL that avoided SQL injection, as well as experimented a bit to find a fast method for retrieving large data sets to Excel via .NET. I used a query table, native to Excel, which provided several requirements natively.Oct 24, 2013
- Interface, it's the first thing you want to think about, be it UI, CLI, or API, you need to think about how you want to use it, making the most common case a breeze, and the less common ones possible, and sacrifice the last common case for simplicity if needed.
Once you are happy about your api, i would start by implementing the smallest viable subset of it you can, and extend, refactoring if needed, thinking forward, but not too much or you get nothing done (and most of the time, you ain't gonna need it).Oct 24, 2013
- Thanks guys! This is exactly what I was looking for! :)
Oct 25, 2013
- Minor addition would be to Understand the broader context of what you are developing...Oct 25, 2013
Add a comment...