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 5 years ago.
Improve this question
I have been learning about TDD and BDD and using this as much as I can at work but in an environment that really isn't agile.
I want to try it out properly on a pet project at home. So, going with the agile approach, and the principle of having working software, what should I write first? Should I create some forms first (this will be WPF / WinForms), linked to some dummy model? Or should I work ground-up. Any advice would be great!
EDIT
I know that I will be writing tests first. The question is at a higher level. Should I aim to put a working model and business layer together first or start with a form and a dummy model.
You are looking at it from a wrong perspective.
You are separating the application into components horizontally - UI component, backend component and so on.
Instead, you should look at it vertically - what are the different features - it could be login/logout, display list of users, display some other data and so on. Sort those slices into a priority order - which one needs to be done first, which needs to be done second and so on.
Then you concentrate on the most important slice until it works, whatever it takes - if it needs UI you add UI, if it needs backend logic you add backend logic and so on. Only after it is finished and fully working you go back to your list of slices, reevalute them, select the most important one again and concentrate on it.
Repeat until you are done.
This is basically what always working software means.
It allows you to stop at any point and say - this is good enough, and ship it.
If you work horizontally you will not have anything working until you finish all the work.
I usually start with the feature and area that is most important. Take a look at this SO answer.
If you want to do TDD/BDD you do start with tests.
In my humble opinion it is always good to start with model tests unless they are totally based on framework's functionality.
As for checking Controller/View part I prefer to have 'blackbox' tests which check if i get response I expect from an http request (for web applications). It allows to remove brittleness from the tests.
Even if I do full TDD test I often throw tests away if they are about nitty gritty parts of implementation, because otherwise very when refactor implementation at the end user experience is the same, so my application works fine, but I am spending hours fixing the tests. I don't to train myself to avoid refactoring just because I know the pain it would give by redoing a large body of testing code.
I would advice to test only things that really matter to you and ignore the rest till it bites.
When I do get a bug from something I was ignoring, I do write a test to document the bug even it it is about low level implementation.
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 4 years ago.
Improve this question
I am currently writing my bachelor thesis about process optimization for creation of XML rendering Stylesheets for another application.
Therefore I am writing a very small and super basic software tool which displays XML structures in tree views. It enables the user to change those (add and delete nodes) and to do some simple application specific stuff.
For doing that, I use Windows Forms.
My question is if I should use a specific architecture or design pattern like MVC or if it would be sufficient to only stick to basic patterns like factory method, command, observer etc.
I am afraid that MVC would be overkill. But on the other hand I am afraid that I should make use of it as it is for a thesis...
The tool should only run on desktop. I don't think there will be any update after initial development.
Hoping for some toughs...
Most answers here will involve opinion. I lean towards suggesting you don't worry too much, but rather try writing it in a way that makes sense to you then once you've got it working, take a look at whether there are any patterns out there that would improve your implementation.
Many of these patterns only make sense once you hit a certain scale with your program.
I'll add that WinForms has its own way of working that pre-dates much of modern MVC. You can shoe-horn it in, but it's not going to feel totally natural. This also factors into my suggestion that you first get your solution working, then explore options to tidy it up.
WPF might be a better fit for the kind of application you're building (HierarchicalDataTemplate), but the learning curve for WPF is very steep.
Of course if the people grading your work are looking for usage of patterns, then that's a different thing.
Good luck!
There are arguably two primary reasons for using a specific design pattern in this context:
You feel it it makes it easier for you to develop and maintain the code base (this is the main reason for using a design pattern in any context).
You feel it would reflect well on you and potentially improve your grade.
Regarding the first point, I assume the code you are writing is not a long term project. There are some exceptions to this rule (for example this one), but in general most thesis project codebases aren't maintained as long term software projects, even if concepts from them are re-used.
Regarding the second point, if you feel you can easily integrate the design pattern without writing more plumbing code for it than the code you are writing for your thesis, then it may help you express your concepts more clearly. However, if you feel it will be a larger distraction, and that you can build a high quality codebase without it, I would avoid being so opinionated, especially on a research project where the concept between inception and completion could change so drastically, and your professor may not care for "over-engineering".
If you have time, I would say the best thing to do is get the thing working first, and then decide if you could get value out of refactoring it into a specific design pattern.
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 5 years ago.
Improve this question
I am writing a software suite which is essentially composed of two separate applications in C# .Net using WPF. Although they may look a little bit different they essentially work like a lite version and a full version of the same software package. The full version contains all of the functionality of the lite version.
I had previously done this by creating two separate applications which share a class library where all the common user controls go. But i am now wondering if there is any better design for this kind of architecture.
I was even thinking of creating one application and at runtime let it decide which version it was going to work as.
Could anyone with any experience with this type of problem please point me in the right direction.
Keep it Simple
My rule of thumb is whenever possible keep solution as simple as possible. That being said I would use the same composition you are using.
Usually break up projects like this:
Application Logic: CompanyPrefix.ProjectPrefix.Core, CompanyPrefix.ProjectPrefix.Data...etc.
Applications : CompanyPrefix.ProjectPrefix.ApplicationType.App, so some examples :
CompanyPrefix.ProjectPrefix.Web.App
CompanyPrefix.ProjectPrefix.Console.App
CompanyPrefix.ProjectPrefix.Wcf.App
Since you have two Wcf Apps might want to do something like
CompanyPrefix.ProjectPrefix.Wcf.Lite.App
CompanyPrefix.ProjectPrefix.Wcf.App
So in this example both CompanyPrefix.ProjectPrefix.Wcf.App and CompanyPrefix.ProjectPrefix.Wcf.Lite.App point back to CompanyPrefix.ProjectPrefix.Core or wherever your business logic is.
About Dynamically Loading Assemblies
There is a way to dynamically load your libraries at runtime, but unless you're dealing with a modularized system of independent components would recommend against it.
If your heart is set on it there are a lot of resources on MSDN, would probably start here. Article about loading assembly into current application domain.
Come Up with a Checklist
One thing I find helpful is to come up with a checklist to help me make decisions in case I ever get stuck. Usually ends up being something like:
Does this have business value?
Does this make debugging harder?
What are the Pros and Cons of doing it a new way versus the way I have done this in the past?
This isn't my exhaustive list but explains the point. This can really help too when you have a group of people that are largely sticking with choices for personal reasons that don't have any grounding, as well as a tool to use when you get stuck to make a decision and go with it
Dealing with Application Logic Changing (Write Clean Code)
Coming up with an over-complicated "never need to recompile entire application again" is a mistake I have made in the past. You're still going to need to deploy and compile something.
Most important thing about dealing with changes in application is to
Have Code on Source Control (most important)
Write Clean Code
Write Tests
Write Documentation ( I know no one likes to do this )
Write some more Tests
What will consume most of your time when dealing with application changes is debugging so focus on reducing the amount of time you spend debugging not a amount of time you spend compiling and deploying
For Deployment setup Continuous Integration
If you have the ability to setting up CI would eliminate 99% of the hassle of changing the application. You lose a day or two setting things up for the first time, but it is well worth it.
Check out TeamCity and Travis CI
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
Looking for design pattern where-in my requirement keeps on changing or in another word i can say the requirement is not very clear.
I need to develop stand-alone Windows Forms App using C#. UI design of app may be changed as and when required as per requirement. Not sure from which design pattern shall i start.
Thanks,
Unclear requirements are the #1 reason for software project failure and delay! You simply can't build something as long as you don't know what to build. No 'design pattern' will help you here!
Facing uncertainty, you should generally go with agile programming methods and small components which are as loosely coupled as possible.
The best pattern for a project in which you know the requirements are going to change is SIMPLICITY.
Don't construct big systems to make your life easier now because they will make your life hard in the future. Not only will you have a new feature to put in, but you will have to unpick the system that is already there as it may not even support the feature.
I have been burned by this a few times - I was lazy (which is not always bad!) so i designerd a big, fun-to-code system to do the boring job for me. The requirements then changed and everything was now more complicated to debug and test.
There is no substitute for simplicity. For windows forms, consider an established pattern like model-view-presenter but don't burden yourself with it. Patterns are a means, not an end
Generally if something keeps changing it normally only effects 1 layer of your application, like the back end, the front end, the database etc.
If you can at least come up with the most constant constraints you can make your framework using dependency injection and loose coupling to allow you to change implementations at various layers quite easily. Its an open ended question so there is no 1 correct answer, however you want something which will let you swap out COMPONENTS easily, so design at the component level, not the the code level.
If you want a project management model which copes well with change look at Agile... or just be pragmatic...
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 9 years ago.
Improve this question
I want to build a management system using Windows Presentation Foundation. I know there's Expression Blend for Graphics design and VS for C# code.
my question is, should i build all UI first using Blend (Buttons, Windows, other elements) and then writing all code (Data bindings, database connections, etc.) or should i build it one step at a time ?
It's my first time using this tech, I've used Windows forms in the past and i want to implement some good-looking graphics in my app.
WPF is intended to make following either UI-first, code-first, or parallel approaches possible - particularly with an MVVM architecture.
However, I suggest starting by putting together a vertical slice through all layers of your application. Reality tends to bite, and depending on how you put your architecture together you will undoubtedly come across many issues that impact your chosen approach.
Since UI is important to you, "Blendability" (the ability to use blend alongside a VS solution) is likely to be a requirement. In this case, you'll want to research carefully how to create a solution structure that will support this.
I think you should take it one step at a time. Don't worry about too many frills in the UI, you can always add to it more later. Keep in mind how you want it to look, and afterwards you can create better looking styles etc. in Blend.
I personally use Visual Studio for most of my development, even the UI. I use blend for creating templates or styles mostly. It used to be that blend was superior to Visual Studio in the designer support, but with VS2012 it has gotten quite good. Also, Blend has a learning curve, it would take some time to get used to. Since you are new, I would suggest not overcomplicating things for you.
The number one thing you need to know about WPF vs. Winforms is complete separation of UI/App logic. It is often much easier to create "ViewModels" with properties and bind those properties to the GUI. If you try to get too involved manipulating GUI elements from code, you'll start digging yourself into a deep hole. The GUI should be databindings, triggers, behaviors, templates, etc.
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 5 years ago.
Improve this question
I'm involved in a project where we are using a Continuous Integration server and NUnit for unit testing and integration testing.
A customer asked us the other day if we were writting the tests before the code... Well, were are not doing it this way always. Specially when there are complex technology issues that we would like to test to understand the problem and the possible solution first.
I would like to know if we could still considered our development process as following Agile Development, say it to customers and don't lie.
I think you are mixing up things here.
Test-Driven-Development (TDD) does not necessarily mean you are using an agile approach. Surely, it is a best practice that many of us who do agile use, but TDD can also be used in a Waterfall process, replacing/supplementing the specification.
Continous-Integration on its own means having the code your team produces integrated on an at least daily basis. This does not only force every member of the team having to merge/checkin continously, but also assures you actually can do a release of every build.The unified build process forces you to overcome the "works on my machine syndrom". Because you could do a release everyday this supports an agile process, even though it is not absolutely necessary in the strict sense.
Using tests and integrating them into the build process is a way to enrich your buildprocess with automated Quality Assurance and deepen the level on which integration (integrity) is actually tested.
As long as you are developing in small iterations, focus on getting a working product rather than on getting extensive documentation, and the customer is continuosly involved in the project, it is agile development. Unit testing, TDD and integration testing are of course good and very advisable practices, but they do not decide whether your project is agile or not.
In the absence of Automated tests, CI only verifies that the code under source control is maintained in a compilable state between revisions and that the single-step build works properly. While this is useful, it isn't as useful as the automatic verification that the correctness of the code has been maintained between revisions.
With that said, I'd rather have some verification of code between check-ins than none. I'd rather have partial code coverage or an incomplete set of functional tests than nothing. Or worse.