I am currently working on an application in WPF/C# for personal use. I am not a "classically trained" programmer. Simply a hobbyist that likes to code in his spare time. Is there any accepted approach to the progression of application development? I. E.; Make it work, add fault tolerance, create a gui, then performance optimization. Or maybe should I design the entire GUI first? Basically I am going to start a new project soon and would like to have some sort of "every program needs this" checklist.
There's really no "every program needs this" list, because there's absolutely nothing that every program needs.
Some advice, though: don't "make it work", then "add fault tolerance". Defensive programming and accounting for errors should be a continuing part of development. It's much simpler (and usually more effective) if you account for errors and unexpected input when you're writing a piece of code rather than after it's done.
As far as whether or not to make the GUI first, answer this question: is the most important aspect of the program what it does or what it looks like? That's a serious question that, honestly, can vary from application to application (though it's usually the former that's more important).
If functionality is more important, model your information in code and get some basic "business logic" (a term of art that represents the non-visual logic in the application that carries out the rules and operations that are fundamental to the purpose of the program) in place, then create a GUI that interacts well with it.
If the GUI is genuinely more important, create it first and model data objects and business logic around the GUI.
I would advise you to peruse this Wikipedia article. It's pretty heady (as most technical Wikipedia articles are), but it provides some good links and will give you a rough idea of how the progression of software development and maintenance moves in the "real world".
I'd say first of all, as simple as it sounds, write (either on paper or in your head) what the app is actually going to do. (Most businesses can't even do this part!)
Knowing that, sketch on paper what you think the screens will look like.
For example, say you're writing a home budget program and you want a drop down for accounts, and a grid for transactions, etc. Knowing what the GUI looks like will help tremendously.
Then fill in the details.
If this is something you're doing as a hobby, you can choose any development methodology you want.
Typically, for commercial development, there's some form of prototype made first (for WPF, SketchFlow with Blend is fantastic for this). This is typically required since you most often need to "sell" the concept, either to a client, management, etc.
However, if you're doing this on your own, you have the freedom to do things any way you wish. One comment, however. I would, personally, not thing of "fault tolerance" as separate from "making it work", however, since "fault tolerance" comes with testing, and unit testing as you go is much more effective...
I try and take a look at my audience for the application. Then I'll create some use cases where I try and figure out what and why my application should even be built. Sometimes evaluating what you're writing and why you stumble across a lot of ideas that might shape the way you architect the application.
From there you can do as others suggest and put more importance on areas of focus.
This is a huge topic that will probably garner a lot of opinions, so I'll chime in with this: Test-driven development. Try reading about it, and make the effort to incorporate it into your development strategy as soon as possible. TDD is the one thing I wish I had known when I started writing software years ago. It makes a world of difference in the quality of the stuff you put out.
What has worked for me in the past is the following (high level) sequence:
Understand and record the requirements (who, what and when) - use-cases, feature list, flowcharts, service level requirements - whatever works for you (I am partial to use-cases though).
Understand and record the design (how) - class diagrams, sequence diagrams, screen designs, API specifications - start high level and drill down (could start development before complete drill down)
Implement - start with API/stubs and unit tests, then fill in the code, update unit tests and execute unit tests as you go.
System test - test the components operating together and fix defects. Don't forget about performance testing (check that you have met your service level requirements from step 1).
Package, deploy and enjoy.
The development lifecycle varies a lot. Variance is due to project size, team size, timeline, etc...
For small hobby projects, I usually follow this approach:
Specs: this could be a half page typed about what I think I'm doing, and maybe some diagrams to make it more clear.
Plan: Usually a document where I outline what I think major milestones will be, such as "complete proof of concept", "basic gui", "system logging", "successful CRUD operations"
Code: Try to meet the first milestone in 2., then possibly re-evaluate 2. Continue until project is done, or I get bored / distracted by something else (usually shinier than whatever I'm working).
This last step may also involve sub-steps such as data modelling (if it's a database app) or graphics design for icons (if the GUI needs fancy icons).
Related
Recently, our Development team came up with an idea of reorganizing our processes. Aside from the new methodology that needs to be implemented, our consultant suggested that we should start our development from UI layer and release it weekly for user testing even if the backbone is not yet completed. His idea is that, we need to release a module as quickly as possible in weekly bases. According to him, the users do not really mind what's behind the application, their concern is only about the output of the application (i totally agree with Him on this). Although I am not totally convinced with the idea of starting from UI Layer as I tend to start coding either from the application's domain or the Database instead of doing the UI Design. I don't know if I am just being bias here.
Any thoughts, ideas or suggestions would be very much appreciated.
This is a very broad question, not knowing your development/sale structures.
I've expierienced this kind of points very often, resulting in a not-maintainable whatever (The result had nothing to with software anymore)
Modern development will mostly fail without an strategy like Scrum or Agile.
Consultants and sales-department often push in that direction because they want to sell stuff and get therefore money in their own pocket due to provision. Usually they have nothing bad in their mind. They simply just dont know it better and probably have never heard about Softwarearchitecture before.
Anyway, following some points on pros and cons:
Pro
Sales-Dudes can sell products better because they have something to show to the customer
Users/Customers can get an early feel for the Application and can point out what they like and what you have to improve
Cons
Hardly you will be able to follow architectonical patterns (MVVM just to name one)
Mosty you produce non-maintainable-code
In most cases your application will not be extensible (Plugins)
Sales-Dudes and Users usually dont know what they even want, ending up in applications like this
Your code will be really hard to test. So TDD will not be possible
These are only a few examples stuck in my mind. I could extend this list to 4 pages why it is NOT a reasonable idea to develop by UI-First.
I know this is mostly based on my opinion, but its also full of Expierence i made by myself, resulting in developing the same Application over and over again.
In our company we develop and sell a VB6 application and we think it's about time to migrate it to .NET.
The main reasons are:
We expect VB6 runtime support to end at some point in time, and we do not want to start the migration just then since it's probably gonna be a lengthy process.
There is just 1 1/2 VB6 developers left. The half one being me.
More and more customers asking for features like cloud and mobile device support.
I know that rewriting an application from scratch is the least recommended way for migrating to .NET. I totally aggree with that! Throwing away over a decade of code feels just wrong and would be such a waste of money spent, that I have a hard time recommending and justifying it towards our management.
But right now I don't see another way to do it.
Let me tell you a little bit about the application:
Like I said it has been developed for over a decade. There have been numerous developers working on it, most of them rather unexperienced at that time. We have one developer left from the initial team. That application has been his first and biggest software project and by now he realizes that many of the architectural decisions made over last 15 years have been horribly wrong, others were right at that time but have not been refactored to meet changes made in other parts of the application and so have become wrong at some point in time. This application seems to be a showcase example of code rot.
We are talking about an application of about 150 KSLOC, all in one single executable. It uses about 15 external DLLs, some of them third party ActiveX controls, some of them are our own .NET assemblies.
Adding new features to the application is still possible and being done, but takes ages compared to our other .NET applications. The reason is that every little change in the codebase requires changes all over the place. The only reason why changes are possible at all is because that one developer simply knows most the dependencies and quirks of the application. As you might have guessed the rate of unexpected side effects and bugs is quite high.
My first thought about migrating that application was to first clean up and refactor, then migrate/convert possibly using tools from Artinsoft/Microsoft/WhoEver and then refactor again to get a nice and clean .NET application.
But I see some problems:
There seems to be no way of refactoring the old application. There is no automated testing whatsoever, not even a formal method for manual testing. Every little change requires manual testing by experienced users who just know where defects might hide.
on the other hand I have established a process and set of tools for testing of our .NET applications which gives us a solid base for making refactorings
Converting that code to .NET without major refactoring feels like: Garbage in, garbage out. Even though I hate calling the old application garbage because somehow it works and has proven itself useful.
Our management has a habit of explicitly demanding quick and dirty solutions, disregarding the effects it has on the productivity and against all recommendations from the development team which has at some point started to deny the existence of quick and dirty solutions in order to be able to do things right. That does not mean that we polish features, but we do include the time to write tests and do refactoring in our estimates. So knowing this, I suspect that once the code is converted to .NET and fixed to the point where the application starts and seems to work, the refactoring-phase will be canceled and the application will be shipped to some customers.
So. What I think is that, despite the fact that rewriting from scratch will take a lot of time and resources, it might still be our only option.
Am I missing an option? Do you see possibilities of not having to rewrite that application?
I suggest that you take a step back and read this paper by Brian Foote & Joseph Yoder (University of Illinois). It provides some architectural insight into the problem you have and options to solve it. It's titled 'Big Ball of Mud' (please don't laugh, it is a serious paper). Here is the abstract:
While much attention has been focused on high-level software
architectural patterns, what is, in effect, the de-facto standard
software architecture is seldom discussed. This paper examines the
most frequently deployed architecture: the BIG BALL OF MUD. A BIG BALL
OF MUD is a casually, even haphazardly, structured system. Its
organization, if one can call it that, is dictated more by expediency
than design. Yet, its enduring popularity cannot merely be indicative
of a general disregard for architecture.
These patterns explore the forces that encourage the emergence of a
BIG BALL OF MUD, and the undeniable effectiveness of this approach to
software architecture. In order to become so popular, it must be doing
something right. If more high-minded architectural approaches are to
compete, we must understand what the forces that lead to a BIG BALL OF
MUD are, and examine alternative ways to resolve them.
A number of additional patterns emerge out of the BIG BALL OF MUD. We
discuss them in turn. Two principal questions underlie these patterns:
Why are so many existing systems architecturally undistinguished, and
what can we do to improve them?
BTW, I think your best option is to use the current application as your Requirements and rewrite everything in VB.NET or C# using a proper design.
There are four main options when you have an application like this:
Do nothing: this is always an option, as everybody knows, if it ain't broke don't fix it. However this might not be an option for several reasons such as needing to comply with some security requirements at the company, or simply because one of the components doesn't work in new platforms.
Rewrite: This would be the dream, right? being able to get rid of all the bad practices and duplicated code and so on? Well, it might be that way, however you have to think all the risks involved in developing a new application from scratch. Do you have all the formal requirements? what about test cases? do your team know every little detail in the code or would you need to go line by line trying to figure out how why that if is there? Also, how many bugs do
Buy something off-the-shelf: Since you are an ISV this won't be an option.
Migrate: Of course you'll be bound by the programming practices you used for the original development but you'll get to a new platform faster, all your business logic will be automatically migrated, you can actually hire developers for the new platform and you can get rid of the legacy elements. From here you can also take advantage of all the tools available to refactor code, continuous integration, unit testing, etc.
Also, with an automatic migration you can actually go further than just WinForms. There are also tools that can take your C# code all the way to the web using a modern architecture.
Of course, I work for Mobilize.Net (previously Artinsoft) and this is my biased perspective.
We've been working on this for around 15 years and have seen dozens of clients who come to us after trying to re-write their application and fail after months or even years of struggling without being able to deliver a working application.
I am responsible for a team of developers who will are about to start development of a light weight insurance claims system. The system involves a lot of manual tasks and business workflows and we are looking at using Windows Workflow (.NET 4.0).
An example of the business domain is as follows:
A policy holder calls the contact centre to lodge a claim. This “event” fires two sub tasks which are manually actioned in parallel and may take a lengthy time to complete;
Check customer for fraud – A manual process whereby an operator calls various credit companies to check and assess the potential of a fraudulent customer. From here the sub task can enter a number of sub-statuses (Check in progress, Failed Reference Check, Passed Reference Check, etc)
Send item to repairs centre – A manual process where the item for which the policy holder lodged the claim is sent the repairs centre to be fixed. From here the sub task can enter a number of sub-statuses (Awaiting Repair, In Progress, Repaired, Posted, etc).
The claim can only proceed once the status of each sub task has reached a predefined status (based on the business rules).
On the surface it seems that Workflow is indeed the best technology choice; however I do have a few concerns in using WF 4.0.
Skill set – Looking at the average developer skill set I do not see many developers who understand or know Workflow.
Maintainability – There seems to be little support within the community for WF 4.0 projects and this coupled with the lack of skill set raise concerns around maintainability.
Barrier to entry – I have a feeling that Windows Workflow has a steep learning curve and it’s not always that easy to pick up.
New product – As Workflow has been completely rewritten for .NET 4.0 I see the product as a first generation product and may not have the necessary stability.
Reputation – Previous versions of Workflow were not well received, considered difficult to develop with and resulted in poor business uptake.
So my question is should we use Windows Workflow (WF) 4.0 for this situation or is there an alternative technology (e.g., Simple State Machine, etc) or even a better workflow engine to use?
I have done several WF4 projects so lets see if I can add any useful info to the other answers.
From the description of your business problem it sounds like WF4 is a good match, so no problems there.
Regarding your concerns you are right. Basically WF4 is a new product and is lacking some important features and has some rough edges. There is a learning curve, you do have to do some things differently. The main point is long running and serialization, which is something the average developer is not used to and requires some thought to get right as I hear far too often that people have problems serializing an entities framework data context.
Most of the time using workflow services hosted in IIS/WAS is the best route when doing these long running type of workflows. That makes solving the versioning problem not to hard either, just have the first message return the workflow version and make that a part of each subsequent message. Next put the WCF router in between that routes the message to the correct endpoint based on the version. The basic is never to change an existing workflow, always create a new one.
So what is my advise to you?
Don't take a big gamble on a unknown, and for you unproven, piece of technology. Do a small, non critical, piece of the application using WF4. That way if it works you can expand on it but if it fails you can rip it out and replace it with more traditional .NET code. That way you get real experience with WF4 instead of having to base a decision on second hand information and you learn a new and powerful technology in the process. If possible take a course on WF4 as that will save you a lot of time in getting up to speed (shameless self plug here).
About the Simple State Machine. I have not used it but I was under the impression it was for short running, in memory, state machines. One of the main benefits of WF4 is the long running aspects.
I have come to this dilemma couple of times and I had chosen not to use Work Flow foundation. Some of considerations (similar to yours) were
Involved work flows were lot simpler (a combination of state machine and sequential actions) and doing it in WF seems to overkill for efforts involved.
Learning curve for developers to understand and to use WF effectively was considered high. Status transition table describing valid transitions and actions to be taken are used for additional flexibility and developers were comfortable with it, easily understanding the concept and purpose.
Chances of business process changes were slim and rudimentary changes were easily possible with help of transition table. A change in transition would mean a database script while change in actions would result in new release/patch. However, probability of such occurrence was deemed to be low.
Looking back after 13-14 months, I still think that decision of not using WF was correct. IMO, WF makes sense where there is strong likely hood that work flow can change and/or business rules can change. WF allows to isolate workflow in separate file and so making it configurable by users will be simpler.
We have been using WF 4.0 the last couple of months. I have to say it's challenging to think the Workflow way. However, I can tell you it's worth it. We knew very little when we started. We've bought a beginner and professional book for WF 4.0 that helped. I, myself, watched many videos online and followed PDC 2009 for their breaking news about WF 4.0 and how it's different from the previous somewhat sucky versions.
One major thing that we had to propose a solution for is the way we can deal with In/Our Arguments in a workflow without bounding our custom activities to certain data types and how to pass parameters between activities. I have come up with a good solution for that, and the workflow experience that we have so far is not bad at all. Actually, we have a workflow-intensive application that is getting bigger and bigger and I really cannot imagine myself solving it in a different environment. I love the visual effect that it has: it keeps me away from the details of if/else etc constructs and makes the business rules apparent in a way that doesn't make you forced to dive into lines of code to know what's going on or how to fix some bug.
By the way, the project that we worked on is very similar to what you described and it's a medium-sized project.
You can tell from my words that I like it and I do recommend it although is incorporates some risks as it's a new technology and you have to come up with some innovative ideas.
my 2 cents...
I did three projects in WF 3.5 and I have to say it is not easy. It force you to think in the whole new way especially when persistance is used. Updating the application which contains hundreds of incomplete persisted workflow is challenging. Single breaking change in serialization crashes them all. Introducing multiple versions of the same library to support new and old running workflows is common. It was challenging.
I haven't tryed WF 4.0 yet but based on experience from BizTalk and WF 3.5 I think it will be similar.
Anyway the best approach you can take is to do Proof-of-Concept. Take single WF from your requirments and try to implment it in WF 4.0. You will spend some time with it but you will prove if you are able to do that in WF 4.0 and if there are any visible benefits.
If you decide to use WF 4.0 I insist that you check possibility to run WF as WCF service hosted in Windows AppFabric. AppFabric provides some out of the box functionality for hosting WFs.
I think it does not really make sense today to talk about Workflow in WF4 as a technology choice for this kind of problem. What is really appropriate, as mentioned by Ladislav Mrnka above, is WCF WF Services hosted in AppFabric.
My experience with this is that it pays great dividends and is very enjoyable, but problems arise in the beginning because it is not properly appreciated that for many programmers this is a methodology shift more than a technology shift. On the other hand, generalists and those with a problem-solving mindset saw WCF WF AppFabric as a set of exciting opportunities. So if the mix of people on the project are fairly conservative C# devs attached to their daily set of OO and patterns, it will be hard to introduce. If the team is more innovative, then adoption will be much easier because the potential and new doorways multiply with each discovery.
Two main conceptual problems programmers had in moving to this technology was:
a) Message correlation and messaged exchange patterns
b) Workflows and unit testing
In standard systems in C# for example a workflow is rarely explicit and therefore rarely unit tested. The overall workflow is left for testing by acceptance scenarios or integration. Introduce an explicit WF as a software artifact and suddenly standard devs want to try and unit test it, which is usually not worth doing.
The message correlation aspect of it is a bit of mindset shift for those not familiar with message exchange patterns. Most devs have dealt with in process and remote calls, web service and SOAP, and usually focussed on one or two of those. To abstract above it all and work with a general message based system can be confusing at first.
On the positive side though, the end result is something that saves a lot of time and creates a lot of opportunities. One main thing is that the worfklow, if visually clear, is something that can be worked on by end user, developer and analyst together, eliminating unnecessary steps in the development lifecycle and focusing the parties on one artifact. Further, it discourages islands of functionality in dedicated apps, with dedicated glue layers, by encouraging a suite of business processes in WF per business domain. Further, with AppFabric, the plumbing for persistence, logging, and waking up scheduled activities is all done for you. WF4 performance is outstanding too.
My recommendation would be to find the most innovative or explorative team member do the initial scouting to discover the tricky parts, get the core functions working, and have that initial person be responsible for then compartmentalising the remaining work.
In order to do an insurance claim system of any complexity that involves roles and "sub-tasks" you really need an BPM solution, not just workflow. Workflow Foundation 4.0 is slick but it really doesn't not come close to the functionalities of a BPM product.
BPM solutions, like Metastorm BPM, Global360, and K2.NET, provide human centric workflow, tasks, roles, and system integration that can model and streamline the business processes like your insurance claim system. Use ASP.NET to build the interface that integrates with the BPM workflow engine as their built in designers are usually limited and force you to use their custom built web control which usually are not as full featured as the ASP.NET web controls.
Go with the technology your team knows and feels comfortable with. Workflow Foundation is not a product that you can use straight away - it's rather a set of pieces you can embed in your application in order to build a workflow system. IMHO the workflow logic is the least important piece of technology, first of all you have to concentrate on the GUI because business owners will not see anything but the GUI. But if your system is a success then you have to be prepared for neverending change requests and new requirements so you have to implement your business logic so that it's easy to change and easy to divide into separate processes to suit different user needs (sometimes contradicting). BPM helps in this task because it allows you to have separate, multiple versions of business processes suiting various business needs. You don't need full fledged BPM engine for that but it's useful to code your business logic so that it can be versioned and divided into individual business processes - the worst thing to have is an unmantainable and intertangled blob of code that handles 'everything' and that no one can understand. There are many ideas for that - state machines, DSLs (domain specific languages), scripts etc - you decide what the implementation should be. But you should always think in terms of business processes and organize your logic accordingly so that it reflects these processes.
And be prepared for coexistence of many variants of business logic and data structures - this is the most difficult design task imho.
I'm in a situation where I have to use 4.0 as .NET 4.5 isn't accredited for use in our prod environment yet. I had major pain understanding generally how to get long running workflows going to suit our business need but eventually found an elegant solution. It's not something which just anyone coming later to support can just pick up with ease because there's so much to think about, but I do believe in WF as a tool for managing workflow states.
One big thing I take issue with WF 4.0 though is Maurice's comment:
The basic is never to change an existing workflow, always create a new one
That's great if you just want a new version, but what if you have 50,000 persisted workflows and realise at some point that there's a bug in the workflow? You need to be able to update the xamlx and still be coupled to the existing instances. I've tried ungzipping the various metadata columns in the SQL Server instances table to find something that ties the instance to the workflow definition without any luck.
I did write a synchronisation application for importing data from an old system into our new WF 4.0 driven one. We basically load the data into the system, then run the process which goes about automatically calling into the workflow steps and calling validation methods, essentially mocking user interaction. This only really worked well with us due to the architecture we implemented for access to the workflow service host. It's great as a one off, where after running you can go through and do checks to ensure consistency of the data migration process, but having to use this approach for potentially hundreds of thousands of cases once a system is live isn't really an approach that instills confidence and over burdens the process of integration simple bug fixes.
My recommendation is that you avoid WF 4.0 altogether and just go straight to 4.5 if you're environment supports it. The Dynamic Updates and Side by Side Versioning it provides caters for bug fixing and WF versioning all out of the box. I've still yet to investigate exactly how as 4.5 still isn't accredited for use by our client, but eagerly awaiting this opportunity.
What I'm desperately hoping for is that our client doesn't request changes to policy (and therefore workflow adjustments) and that the current workflows hold up without any bugs. The latter being a vain and empty hope as bugs always pop up.
I really can't understand what was going through the WF dev team's heads to release a system where out of the box you can't fix bugs easily. They should have developed a technique for re-binding an instance to new xamlx.
I am in the last year of undergraduate degree and i am stumped by the lack of example in c++ and c# large project in my university. All the mini project and assignment are based on text based database, which is so inefficient, and console display and command, which is frustrating.
I want to develop a complete prototype of corporate software which deals in Inventory, Sales, Marketing, etc. Everything you would usually find in SAP. I am grateful if any of you could direct me to a books or article or sample program.
Some of the question are :
How to plan for this kind of programming? should i use the concept of 1 object(such as inventory) have its own process and program and have an integrator sit for all the program, or should i integrate it in 1 big program?
How to build and address a database? i have little bit knowledge in database and i know SQL but i never address database in a program before. Database are table, and how do you suppose to represent a table in a OOP way?
For development type, which is better PHP and C++ or C# and ASP.NET? I am planning to use Web Interface to set form and information, but using a background program to handle the compute. .NET is very much integrated and coding should be much faster, but i really wonder about performance if compared to PHP and C++ package
thank you for the info
This may not answer your question directly, but I thought this might help you get started in some way. So here it goes: I would say, "think through the process". This means, think through the software development process:
Gather requirements
Identify and define the problem.
Get as much information/facts as you can. (turn on green light, think about everything that you want to go into your software)
Come up with a baseline (turn on red lights, what you really want? the minimum functionality your software "must have" - cant live without)
Analyze
Know what you don’t know, what are the missing facts?
Evaluate your information or lack of it/reliability of information source.
Infer facts that you don’t know.
Form an assumption, opinion, or possible solutions.
Consider alternatives and implications of each solution.
Form an action plan.
Identify technology pros/cons.
Decide technology
Comeup with a functional specs.
Research
Dig into stuff that you would want to know (Best database, ORM, design practices, code samples - gather everything, read about inventory systems that are already there)
Design
Develop
Test
Fix
Prepare deployment plan
Release the product
Gather user feedback
Analyze user feedback
Plan for items in next release.
Repeat steps
And Enjoy!
Before I start this is a shallow answer to a deep question.
1) It looks like you have a reasonable grasp of the major components of your target application. As a .net developer I'd build assemblies that matched broad areas of functionality (not sure what the equivalent is in PHP) and then you can use those assemblies together as a single large app, or seperately as required. It's unlikely you'll get it right first time, so build it how it feels right, and then do some ruthless refactoring to make it better once you've got a handled on the problem.
2) This whole area is covered by Object Relational Mapping - ORM, NHibernate is the best of the bunch in the .Net world. BTW if you learn that you'll be way ahead of the game come graduation/work time. Raw sql is so last decade. I guess you know that Sql Server Express is a free download?
3) For development go with the languages/environment you feel most comfortable in. My preference is .net, and the integrated coding is much faster. Performance is definitely good enough, especially as this is learning project - SO runs on .Net and that supports a gazillion users pretty well.
Enjoy
I don't have any good recommendations for SAP-like projects in particular, but in general the best examples to use for things like this are well-established open-source projects. Anything else is going to be a "toy" example in one way or the other, and will be simplified and cleaned up. It's the "cleaned up" that makes it most unrealistic -- one of the really key things that makes real-world large software projects different from university examples is that the real world is messy, and real-world requirements are messy, and collaboration between lots of people with not quite the same priorities is messy, and real-world software projects have to adapt to and thrive in this messiness.
In answer to your specific questions, though:
1.) Do things in a modular way. This means you have something you can test and work with as soon as you get the first module done. That's especially important when you're learning, because (a) you probably won't have time to actually finish the whole thing, (b) you'll learn a lot from writing the first bit that you'll want to apply in future bits and then you'll probably want to rewrite the first bit, and (c) you'll learn even more from using the first bit.
2.) There are many views on this, and many online articles and books. I can't answer that in an answer here (except to note that in some cases trying to represent it in an OOP way is the wrong programming paradigm -- be careful about overconstraining the answer by the question you ask!); the right answer is to find things to read and spend some days reading them.
3.) You do not care about that sort of performance issue here. Successful programs have been written in both forms. You care about what will teach you the most, and what you are comfortable working with. Either one should be fine. You'll probably find more open-source pieces to look at with PHP and C++.
Your question pretty much covers the whole gamut of planning for a project; a whole thesis might be written (+:
Keep in mind what your team and your teaching-staff want out of the project.
1) Modular is my choice. It'll force you to address the application one module at a time and keep you focussed, but that is subject to
The familiarity of your team with the preferred/recommended language for this project.
Time in hand
Remember that modular means you will necessarily have to provide for module integration too.
2) C++ or C# ? Whichever offers the more learning experience. My own experience with both mentioned technologies is limited, but I remember there used to be a Database Template Library (DTL). C# on the other hand will probably be faster to develop. I could be wrong. There are any number of free DBMS engines available on the net. Unless the assignment explicitly recommends using a text, opt for one of these.
3) I concur w/Brooks up there ^^^
Good Luck!
You are a university undergraduate. And you are talking about complete inventory system.
I suggest building a blog application first with all the best practices (like blogengine), then move to e-commerece sites (nopcommerce, dotcommerce). And then do whatever you like.
This is a common problem with undergrads like you, of jumping way higher without building any simple projects first.
As a full time PHP developer, PHP sucks! ASP.net is okay (mmm... no it sucks too), but it locks you into proprietary licenses.
If you're starting from scratch, go for node.js. It's c++ and server-side javascript. Yes, it's new, but it has engineering promise. It'll be more commonplace in a few years.
And if you're worried about performance, don't. Javascript in V8 is extremely fast.
http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php
Here are some node.js links to get you started:
http://www.delicious.com/homer6/nodejs
Enjoy.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I wanted to see what folks thought were the best way to help junior members gain confidence in their ability to refactor code. I find that often junior developers simply follow the existing patterns and sense an aversion to break anything due to the perceived risk. I am trying to get them to look at the requirements (new and existing) and have the code map onto the domain model versus "tweaking" or "bending" the existing code base to support new functionality. Just wanted to see if there were any folks who have success here. We are currently thinking about pushing more pair programming, TDD, code reviews etc., but wanted to check if there were other success stories...
The only reliable answer will be unit tests IMHO. Not necessarily TDD -- just get them to write tests for the existing methods/classes they want to refactor, make sure they're doing what they're doing, then allow them to refactor like crazy while relying on the tests to make sure the methods are still valid.
The confidence level and flexibility unit tests allow are immensely valuable in these kinds of activities.
It seems that pair programming with a senior developer in combination with writing tests would be the optimal situation. If the more experienced developer in the pair is leading, the testing will just be part of it.
Writing tests alone leaves room for improvement. Writing tests in a pair environment is the best of both worlds and therefore should build the confidence quicker.
I recommend you to have Unit Tests before start a heavy refactoring, if you have a good code coverage, by simply running the tests you'll be able to see if some test fail, which refactoring affected the desired program behavior.
Basically Unit Testing can give you the confidence your team needs to refactor.
No matter what, you should push for "more pair programming, TDD, code reviews etc". You should also make sure that your programmers (both Junior in years and in habits) are skilled in the fundamentals.
I reccomend suggesting that they read McConnell's Code Complete and Fowler's Refactoring.
I agree - unit tests, and pair programming.
The first step would be to have them write tests for whatever they want to refactor FIRST and then refactor. I also think there is some merit in code reviews with more senior developers as well as pair programming.
My suggestion would be to take a system that will change quite a bit over time and let a junior developer give a plan of what basics they want to apply to it, e.g. are unit tests missing, what design pattern may make sense to use to add the new functionality, do you feel this is "good" code and if not, what changes would you make to it? Part of this is getting them into the code and comfortable with it as when a developer doesn't know what anything within the system does, chances are they want to make minimal changes for fear of breaking something and the subsequent negative fall out. If there can be a senior member that can act as a mentor and guide what junior developers suggest into something that better matches what is being sought, this may be the big thing to get in there.
Note that for the above that senior member may have to have a good deal of familiarity and in a way already done the planning of how to make the changes that the junior developer will do, but the idea is to get the juniors more into the code is how I'd see it. If the junior developers can get in the habit of jumping into things and be encouraged to do that, then I can see some success there. The key is to have the idea of how to correct what the junior developer suggests and yet encourage them to give more into the overall process rather than be told what to do.
Some people are more likely to stand out and take a chance, the key is for the group to see how this turns out as what you want in the end is a group of junior developers all working on various solutions where the senior developer may have originally built the system or integrated various products together and thus can give an input on what should be done but act as a guide rather than a parent in getting stuff done.
Another way to view this is to simply visualize things from the junior developer's view. If they suggest something and get something, e.g. praise or better assignments, then this may get things rolling, though one has to be careful on what is given as to keep taking things up a notch can run into problems if it grows too high.
Ask them to write or investigate existing test cases
Run the those test cases, record the result
Ask them to refactor the code
review the refactor code
Run the test cases match the previous observations
Also, try doing some coding dojo's. One pair sits and programs at the beamer, rotating one developer every five minutes. Have them talk about how they refactor, and why.
See: http://www.codingdojo.org/
I believe the question is not specific to C#, so I'll suggest giving it a try with Java using Eclipse. Eclipse has the best refactoring tools I have ever seen so far (although I never tried IntelliJ IDEA or Resharper). I have benefited a lot by learning refactoring through Eclipse, especially using the Preview window before performing any change.
I would recommend a combination books, tools, coding and mentoring.
Before anything else - get the candidate to buy or borrow Refactoring by Martin Fowler and read it.
If you have a good source control system - it should be trivial to create a separate branch to play with. Also if the end result of the exercise is useful you can easily merge it into the trunk.
Next, pick a specific task that you know would require them to comprehend the application structure. For example, ask them to instrument a part of the system. This provides a task within which to work instead of general directives (like read the framework documentation or read this code)
The next part is to ask that tests be written to support the functionality touched by this task. Review the tests and encourage writing of comprehensive tests. It is important to use a tool for this like NUnit or if your IDE supports unit testing, use that. Encourage the person to ask questions and find out why things are the way they are.
If you are using an IDE that supports it introduce the refactoring tools in the IDE and encourage them to refactor the code. Use pair programming or regular code reviews to mentor the person. The tests can be used to show how unit tests are a vital part of a good refactoring effort. Start small - may be change the names of things or extract fields into properties and then move to more complex ones.
Hopefully, by the end of the exercise, not only will the person be comfortable enough to question, tweak and change the application and you would have some useful functionality out of it as well :-)