Propeople Blog

A regular dose of fresh news, events, products, Drupal development resources and more.

January 15, 2013

Using frameworks to fight with “crutches” and “reinventing the wheel”

Hello. If you are a programmer, and your job is boring and dull, if you write the same code from day to day, if the code for fixing bugs commensurate with application code - then this post is for you.

For people who are not familiar with development, I made some explanations to simplify the material presented. This is my first post about frameworks. I want to tell you about my personal attitude to “reinventing the wheel” and “crutches”.

Let's start with the fact that I am writing code more than seven years. I am usually working on different projects and have to choose a particular style of programming. For example, for nimble spiders and multi-thread grabbers I prefer to use a functional approach and no more. For implementing web services and "active" web applications I use event-driven approach. And of course do not disdain meta-programming when working on complex client-side javascript applications. And no matter what I'm working on and what is my current project, I always get a kick out of the work. Why? Because I try to not “reinvent the wheel” , regularly getting rid of the “crutches” and understand what I should be doing, and what should not be doing.

The wheel
Reinventing the wheel - is the process of solving the problem, which is already has the optimal solution. Reinventing the wheel - a disease to be combated immediately after its detection. "Reinventing the wheel" fraught:
- a waste of time for the invention of the "reinventing the wheel",
- loss of time to implement it,
- deterioration of mood after realizing that the “wheel” is imperfect and there is more elegant wheels,
- an increased likelihood of errors,
- loss of vigor the project.

So it’s hard to overestimate the influence of "reinventing the wheel" in the process of creating the project.

Crutches - a temporary solution of the problem (often quickly produced), which does not coincide with the general application ideology and unclear for the other developers. Unfortunately the appearance of "crutches" on the project is inevitable, because of incomplete understanding of the problem by the developer, manager, and sometimes even the customer, or the emergence of new requirements which were not covered in the main spec. Increasing “crutches” count in the project may produce following problems:
- a complete or partial loss of the base architecture,
- fault tolerance,
- development slowing,
- increasing complexity of the application.

"Crutches" are not as frightening as "reinventing the wheel" but they must be treated very, very carefully. And get rid of them as soon as found presence "crutches" and you found a more appropriate solution.

Frameworks and “reinventing the wheel”.
Frameworks will help to getting rid of from "Reinventing the wheel", since the frameworks can be called "the warehouse of ready wheels". Some frameworks has more “ready wheels”, the other - less, but somehow they save you from unnecessary movements , errors, and loss of precious time. It is difficult to underestimate the ability to create applications from ready-made parts, which are created by several developers (sometimes by big commands), tested and have a good documentation. There is another big "buns" for PHP developers, which is not used by all developers. It is the open source, of the most available frameworks. Open source makes it possible not only to solve the problem quickly, but also to understand the solution by reading the source code. If it turns out that framework you are using does not have a functionality that solves your problem, it is likely that this functional has another framework that would like to share part of it (hubrids of Zend, Symfony, YII are commonly used ) with you, and it's all the same will be better, faster and easier than "reinventing the wheel." Thus the use of frameworks as a set of predefined functional relieves the developer from the loss of time, excessive mental stress and losing of mood. This is a great advantage.

Frameworks and the “crutches”
To understand the essence of "crutches", you need to understand from what they appear. They appear for the following reasons:
- When you need to quickly solve a problem that does not allow the project to function.
- When there is understanding of architecture and use uncharacteristic for the basic architecture solution.

In framework terms it's very simple: either the customer requires immediate attention or you do not fully understand the ideology of the framework. It is permissible under active development and in small quantities does not affect the overall development process. "Crutches" must exist only in small count, and to control "crutches" count you need to use the re-factoring. In general does not even matter what type of re-factoring to choose, any one of them will not allow you to build your project on "crutches" and make project stable and fault tolerant. Way, if you do not get a grasp of the theory of re-factoring, and just when meeting another "crutch" you make it "beautiful" and then return to the task, within a few weeks you can to turn a big pile of crutches into good project with single ideology. It should also be noted that re-factoring crutches should do only the developers who understand the ideology and the scheme of interactions in project, otherwise the project may end up as big bunch of "crutches". Using a framework does not eliminate the "crutches", but opens the way for re-factoring. In the case of the "crutches", frameworks undoubtedly improve mood and self-esteem of the developer, as with an understanding of the ideology of the framework comes the understanding that there is a "crutch", how to remove this "crutch" and do not allow this in the future. And what could be more interesting than the process of self-improvement with visible results in the form of a "pure" code more consistent and clear a running application, with significant increase in the speed of development? (Only sudden salary bonus :) )

Summarizing, I want to say that frameworks are not a panacea for all ills, their implementation is fraught with significant inhibition at the stage of framework learning , but frameworks usage almost completely get rid of "reinventing the wheel", will produce minimum number of "crutches" and will make the work more interesting for every developer, and will improve overall command mood. And finally I'll tell you a little secret: the use of the framework essentially eliminates the routine work and gives a lot of free work time for developers to become someone bigger. But this will be my next post topic. So try to use framework and have fun!

0 Responses to this post