Sometimes during development you find obstacles or challenges you don't know how to tackle. Features you've never coded before or situations due to already written code that just make sense. You can count on a little bit of pressure here. You need to get the implementation done by Friday but you know it wouldn't take you that long if you only had done it before. Or there is a certain mysterious piece of code that somehow eludes you. Maybe the situation is one where you can't figure out exactly why a function isn't working the way you had expected or you had thought it did things that it does not do or handle situations that it wasn't written to handle. In these types of situations your best option is to just simply plunge right into trying things and looking at their result.
Many times API or programmers on your project simply overlook certain situations. There is always a reason why they didn't handle situation x or y. Usually it comes down to purpose they didn't intend the code to be reusable for a different purpose. This is can also be the reason for performance problems where the code was written using reusable principles and designed to be generic but it was never optimized for the situations that it allows. You end up either rewriting it altogether as a separate piece of code that looks a little similar or you deal with the ramifications of reusing it. This usually happens more often than not when the code is part of your project rather than 3rd party code. Though a lot of times its directly related to the misuse of 3rd party of external APIs where the programmer using those APIs didn't understand how to use the API the way it was intended.
Again just plunge right in attempt to use the code you have and look at the results. Almost all the time the code could use refactoring if it is to properly handle what you want but you must know that if you decide to use it and not refactor it but instead use work-a-rounds to get it to do what you want rather than changing it you will inevitably be building performance or maintenance problems in the future. Reuse can be a crutch, more on that later, the main piece of advice I can say for productivity is to just start changing it find that better way swap out the current implementation for something that handles the existing situations as well as your new one.
Many times in programming you can feel trapped and get yourself into a loop of inactivity while you stew over how to hack around structural issues presented by poor design from the past. More often than not it is a lack of redesign activities which are causing your frustrations. Depending on which path you choose you could end up feeding the beast and mangling the code breaking consistency. It's usually readily apparent in any codebase to recognize learning code from real functional code. You can notice subtle programming mistakes brought on by unconstrained use of misinterpreted patterns. If you know what I am talking about and have witnessed coding atrocities feel free to recount your painful experiences here as each new situations presents the opportunity to learn ways to mitigate the overlooked risk of poor design.
Many times API or programmers on your project simply overlook certain situations. There is always a reason why they didn't handle situation x or y. Usually it comes down to purpose they didn't intend the code to be reusable for a different purpose. This is can also be the reason for performance problems where the code was written using reusable principles and designed to be generic but it was never optimized for the situations that it allows. You end up either rewriting it altogether as a separate piece of code that looks a little similar or you deal with the ramifications of reusing it. This usually happens more often than not when the code is part of your project rather than 3rd party code. Though a lot of times its directly related to the misuse of 3rd party of external APIs where the programmer using those APIs didn't understand how to use the API the way it was intended.
Again just plunge right in attempt to use the code you have and look at the results. Almost all the time the code could use refactoring if it is to properly handle what you want but you must know that if you decide to use it and not refactor it but instead use work-a-rounds to get it to do what you want rather than changing it you will inevitably be building performance or maintenance problems in the future. Reuse can be a crutch, more on that later, the main piece of advice I can say for productivity is to just start changing it find that better way swap out the current implementation for something that handles the existing situations as well as your new one.
Many times in programming you can feel trapped and get yourself into a loop of inactivity while you stew over how to hack around structural issues presented by poor design from the past. More often than not it is a lack of redesign activities which are causing your frustrations. Depending on which path you choose you could end up feeding the beast and mangling the code breaking consistency. It's usually readily apparent in any codebase to recognize learning code from real functional code. You can notice subtle programming mistakes brought on by unconstrained use of misinterpreted patterns. If you know what I am talking about and have witnessed coding atrocities feel free to recount your painful experiences here as each new situations presents the opportunity to learn ways to mitigate the overlooked risk of poor design.
No comments:
Post a Comment