How to get applicable OOP / software structure knowledge

qkhanhpro

Hello everyone. For the past 3 years I have been a full time web developer that work in a corporate RnD team I do know how to solve a problem or you can say the one that "just make things work" but most of the time, my solution is not very extensible or clear for whoever else that is also working on It I would like to ask you guys how you goes through that phase in software development world and is there any specific things I could do rather than reading some articles? Just some additional info : I use C# / Angular

OriginalGriff

It doesn't matter what languages or framework you use, it's the mindset you need. Start by thinking about the past projects. How did they change? How did they evolve, what happened to the specification? What would have made it simpler to add those changes? I work on a simple principle: design for change, design for maintenance. The maintenance portion of a project is generally much longer than the "coding" part - and is normally done when the original project is no longer "familiar code" (either because it's been a year since you last looked at it, or you aren't the guy who wrote it) so design for that, rather than the immediate moment. Don't do "clever code": it's a PITA to modify (or even understand six months down the line) Do design for generic use instead of specifics: test it, add it to a library of "useful code" and use it again, and again for multiple projects. Do design for problems: for example when I do a switch on an enum I always write this:

switch (myVariable)
{
default: throw new ArgumentException($"The value \"{myVariable}\" is not handled");
case MyEnum.First: ...
...
case MyEnum.Last: ...
}

So if you add an option to the enum it is detected and you have to deal with it instead of doing nothing because it isn't in the switch list. Do check your inputs: make sure data is correct as far as you can before you try to process it. Defensive programming helps you to prevent problems. But ... the biggest helper here is experience. Three years isn't that much, not really - keep thinking about what you are coding, why, and who for: you'll get there!

Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!

Lost User

10,000 hours.

The Master said, 'Am I indeed possessed of knowledge? I am not knowing. But if a mean person, who appears quite empty-like, ask anything of me, I set it forth from one end to the other, and exhaust it.' ― Confucian Analects

Benktesh Sharma

I agree with the points mentioned by fellow members. I just wanted to convey my thoughts on OOP/Software Structure Knowledge and how experience can or in some cases cannot bring that knowledge. If I am working on a product continuously, I am getting better at the same software I am working on, but not necessarily becoming better at OOP/Software Design because I would not know what's outside. You are lucky if you get to work on a variety of projects that have different development stages or framework etc on a daily basis then the experience working with diverse software will be invaluable to OOP/Software Design. But if you get to work on the same software (such as maintaining and minor enhancement), you could look at completely different language/framework and start making side projects. I find this approach very useful because when I start to learn new language/framework then I have to set my mind at '0' and then I get the way that I have not been working with. For example, working with Android Development in Java made me better at background tasks and multithreading which I rarely use in my regular .Net work and I started to use the techniques I learn in Android/Java in my .Net/C# development.