Productivity to a grinding hault
-
Hi everyone, I have been developing C# applications for about a year now and I am starting to grasp the more advanced topics. The problem is, I know enough about the C# language to write code for ADO.NET and other technologies, but not skilled enough to write code adhering to design patterns and encapsulation (i.e all my code is written in codebehind in my form class). I am now stuck in a bind because I don't want to write code in code behind, since I have been reading it is hard to maintain, etc, etc but I am not yet good enough to properly setup inheritence and good design in my code base! Is it ok to develop a large application all in code behind and then try to refactor it out later? I am just completely stuck! Any help appreciated :) Dave
-
Hi everyone, I have been developing C# applications for about a year now and I am starting to grasp the more advanced topics. The problem is, I know enough about the C# language to write code for ADO.NET and other technologies, but not skilled enough to write code adhering to design patterns and encapsulation (i.e all my code is written in codebehind in my form class). I am now stuck in a bind because I don't want to write code in code behind, since I have been reading it is hard to maintain, etc, etc but I am not yet good enough to properly setup inheritence and good design in my code base! Is it ok to develop a large application all in code behind and then try to refactor it out later? I am just completely stuck! Any help appreciated :) Dave
DavidKiryazi wrote:
Is it ok to develop a large application all in code behind and then try to refactor it out later?
Absolutely not. if you to do so,you will find the workload is far beyond your imagination. did you read any article about "Object-oriented design patterns"?
-
Hi everyone, I have been developing C# applications for about a year now and I am starting to grasp the more advanced topics. The problem is, I know enough about the C# language to write code for ADO.NET and other technologies, but not skilled enough to write code adhering to design patterns and encapsulation (i.e all my code is written in codebehind in my form class). I am now stuck in a bind because I don't want to write code in code behind, since I have been reading it is hard to maintain, etc, etc but I am not yet good enough to properly setup inheritence and good design in my code base! Is it ok to develop a large application all in code behind and then try to refactor it out later? I am just completely stuck! Any help appreciated :) Dave
DavidKiryazi wrote:
Is it ok to develop a large application all in code behind and then try to refactor it out later?
How about a lot of small applications, calling them prototypes and have an intern make some nice OO code of it in their own pace? :) I've seen quite some applications with business-rules embedded in the form-events - some of those started as mere Access-databases, with the same copy-and-paste code all over each form. Over time, requirements and complexity grew, and programmers got added. Bad code is often better than no code at all, but it also has some predictable drawbacks;
- Refactoring
- "Hunting" for bugs
- Security holes
- Actual undetected errors that mess with user-data without the user detecting it (!)
"You still have $10.000 in your account" or "All files safely backupped! (Total: 0 files)" - A messed up taborder
I are Troll :suss:
-
DavidKiryazi wrote:
Is it ok to develop a large application all in code behind and then try to refactor it out later?
Absolutely not. if you to do so,you will find the workload is far beyond your imagination. did you read any article about "Object-oriented design patterns"?
thanks for response Alegria. I haven't read any books about design patterns. I have mentioned it to a couple of work colleagues but they insist that the best way to learn is just to write code. I disagree because I guess my opinion is that if you learn to write bad code, then it will be harder to change your ways later on. I guess I might need to read a good book on object oriented design and design patterns. I know the GOF is a must, but apart from that is there any you can recommend to get me up and going? Basically I need something that teaches me OOD that does not use the simple examples like Cars. I am also considering the purchase of Code Complete 2 and I have stated reading "The Pragmatic Programmer" Dave
-
DavidKiryazi wrote:
Is it ok to develop a large application all in code behind and then try to refactor it out later?
How about a lot of small applications, calling them prototypes and have an intern make some nice OO code of it in their own pace? :) I've seen quite some applications with business-rules embedded in the form-events - some of those started as mere Access-databases, with the same copy-and-paste code all over each form. Over time, requirements and complexity grew, and programmers got added. Bad code is often better than no code at all, but it also has some predictable drawbacks;
- Refactoring
- "Hunting" for bugs
- Security holes
- Actual undetected errors that mess with user-data without the user detecting it (!)
"You still have $10.000 in your account" or "All files safely backupped! (Total: 0 files)" - A messed up taborder
I are Troll :suss:
Thanks for response Eddy.
Eddy Vluggen wrote:
How about a lot of small applications, calling them prototypes and have an intern make some nice OO code of it in their own pace?
The only problem is that I am somewhat of an intern lol :) I guess I am trying to develop my skills in the right direction, rather than developing bad habits and having to break out of them late (which is always harder). I will play around with some prototyping of smaller applications and maybe post some results of what I have acheived. Dave
-
thanks for response Alegria. I haven't read any books about design patterns. I have mentioned it to a couple of work colleagues but they insist that the best way to learn is just to write code. I disagree because I guess my opinion is that if you learn to write bad code, then it will be harder to change your ways later on. I guess I might need to read a good book on object oriented design and design patterns. I know the GOF is a must, but apart from that is there any you can recommend to get me up and going? Basically I need something that teaches me OOD that does not use the simple examples like Cars. I am also considering the purchase of Code Complete 2 and I have stated reading "The Pragmatic Programmer" Dave
Code Complete is a great book. I own it and I make it a point to re-read through it every year just as a reminder/refresher. That and 'Software Requirements' by Karl Wiegers is great too. GOF is important from a high level conceptual point, but in reality I think you will find that thinking in OOP is clearly more important than learning a bunch of patterns. Not that they don;t give some great advice, but I personally think that learning to think in layers is more important that focusing on learning a set of specific patterns. Don't get hung up so much on the simple examples that most book use as much as making sure you get the higher level ideas behind them. Remember that authors have to not only write so the reader can understand a complicated concept but often times the 'editors' at the book companies can have a huge impact on the content of a book and cause it to be dumbed down a bit too much. You want to read some great stuff on OOD grab yourself a membership to ACM (or IEEE if you happen to be independently wealthy) and read some of the papers submitted there. Some good reads. If you really want to get used to thinking in a detached manner (IE: code implementation separate from UI and data layers, take a look at doing some work in SilverLight. It FORCES you to NOT put code in your UI layer at all, simply because you really can't. It makes you think in layers and that is a good thing that you can end up leveraging even in the regular application world.
-
thanks for response Alegria. I haven't read any books about design patterns. I have mentioned it to a couple of work colleagues but they insist that the best way to learn is just to write code. I disagree because I guess my opinion is that if you learn to write bad code, then it will be harder to change your ways later on. I guess I might need to read a good book on object oriented design and design patterns. I know the GOF is a must, but apart from that is there any you can recommend to get me up and going? Basically I need something that teaches me OOD that does not use the simple examples like Cars. I am also considering the purchase of Code Complete 2 and I have stated reading "The Pragmatic Programmer" Dave
-
Hi everyone, I have been developing C# applications for about a year now and I am starting to grasp the more advanced topics. The problem is, I know enough about the C# language to write code for ADO.NET and other technologies, but not skilled enough to write code adhering to design patterns and encapsulation (i.e all my code is written in codebehind in my form class). I am now stuck in a bind because I don't want to write code in code behind, since I have been reading it is hard to maintain, etc, etc but I am not yet good enough to properly setup inheritence and good design in my code base! Is it ok to develop a large application all in code behind and then try to refactor it out later? I am just completely stuck! Any help appreciated :) Dave
don't want to write code in code behind, since I have been reading it is hard to maintain, etc
Business logic and most of code is generally written in code behind. you must not refrain from it.
Is it ok to develop a large application all in code behind and then try to refactor it out later?
Refactoring costs high if not done properly and many times its tough decision in large projects. 'Refactoring: Improving the Design of Existing Code' by Martin Fowler is a good book, you can refer.
-
Hi everyone, I have been developing C# applications for about a year now and I am starting to grasp the more advanced topics. The problem is, I know enough about the C# language to write code for ADO.NET and other technologies, but not skilled enough to write code adhering to design patterns and encapsulation (i.e all my code is written in codebehind in my form class). I am now stuck in a bind because I don't want to write code in code behind, since I have been reading it is hard to maintain, etc, etc but I am not yet good enough to properly setup inheritence and good design in my code base! Is it ok to develop a large application all in code behind and then try to refactor it out later? I am just completely stuck! Any help appreciated :) Dave
Yes, it may not be as maintainable and extensible as you would like but the answer is Yes. When I asked for a peer review with the first team lead I ever worked for, a Russian, his response was "It works? it's good" Great advice. In fact if it works, it's great.
-
Yes, it may not be as maintainable and extensible as you would like but the answer is Yes. When I asked for a peer review with the first team lead I ever worked for, a Russian, his response was "It works? it's good" Great advice. In fact if it works, it's great.
Have to disagree I'm afraid. Software that 'works' is not good enough. Good software meets the following criteria - Performs its function with minimal bugs - Code Easy to understand by any average developer that may work on it in the future (if advanced techiniques are used that the average developer would not understand they should be commented to at least provide a jumping off point to learn that technique) - Designed in such a way that changes to requirements can be applied with minimal impact (loose coupling) - Designed in such a way that any single modification need only be made in a single location (DRY principle) - Designed in such a way that any fairly generic bit of functionality can be re-used without too much hassle - Exhibits reasonable performance in terms of speed and memory usage (according to requirements) - Future proof to a fair degree (in terms of scalability and according to requirements) and thats not to mention the little nuances such as naming conventions and comment styles