DRY applied to web development
Autor: Gabriel Ricci | Publicado: 2011-11-11T20:01:00-02:00

  "Remember that feature that we've used on the other screen? We'll need to use it on this screen too, okay?"  Every developer encountered this situation or a similar one at least once , what to do to avoid this problem? Obviously this type of situation would not occur (or at least should not occur) in well-designed systems, where there is a previous survey of requirements, where there is prototyping the screens and so on, but we all know that in real life the planning does not always occur, and that even in the most well planned projects, there are always last minute changes, so how do we minimize changes? How to avoid writing code twice? How to not repeat yourself?  My answer is that as frontend programmers, developers, designers, regardless of the situation, we should always look for ways to avoid reinventing the wheel and create reusable components. This can be done in different ways, let's start with the simplest of them.  You can be a great frontend programmer, you can know javascript like the palm of your hand, but still you can delegate some of the features of your project to some framework. For example, just doesn't make sense to write a function to show or hide a element in an HTML page when you can use a framework like jQuery for this. I'm not saying you can't implement all these features if you wanted, what I mean is that it makes no sense to reimplement features that have already been implemented by other frameworks, frameworks that support all browsers in the market and will be supporting them for a long time.  The same thing happens with CSS, but in a more delicate way because typically designers who focus on CSS are usually a little bit skeptical about using CSS frameworks (such as the Blueprint), many of them think that creating a good CSS style sheet is almost artisanal, a thing that must be done by hand, like a painting, but if we have a framework that resets the browser's style to maintain a standard, if this framework provides helper classes for columns, clearfix and several other resources to expedite our work, why not use it and focus our time on the particular features of the system or site that we're working?  Thinking this way we can use the same approach even to the particular features of each system, those who have to be developed manually. For example, suppose you are working on a video management system, and you have to load a list of videos on two screens. I have seen situations in which developers write JavaScript code on both screens, and this code was pretty much the same in both screens. The code made the request to the backend, which returned a list of videos in JSON or XML, and the list was treated to be displayed in the frontend, the problem here is that we have two different codes to treat the same data structure returned by the server.  A different approach to solve the above issue would be to create a unique script for the video's management, this script would have a standard data structure that would be used on both screens, and would have methods for persistence and management of the videos:      function Video(id){  &nbsp; &nbsp; this.id = id;&nbsp; &nbsp; ...attributes...  &nbsp; &nbsp; this.save = function(successCallback, errorCallback){alert('saving');};&nbsp; &nbsp; this.delete = function(successCallback, errorCallback){alert('deleting');};&nbsp; &nbsp; this.insert = function(successCallback, errorCallback){alert('inserting');};&nbsp;&nbsp; &nbsp; ...business methods...}  &nbsp;Video.getByID = function(){alert('getting by id');}Video.getAll = function(){alert('getting all videos');}      This class would be included by the two screens and would be responsible for the management and persistence of the videos and turn them into a standard data structure for all the screens that require this feature, that way, the scripts of each screen can be focused only on how to display the elements in the screen.  DRY concepts can also be used in other areas. Besides a frontend programmer, I also work in the backend, and beyond the backend frameworks (wich help as much as the frontend frameworks), also have seen relatively simple solutions that prevent you reinvent the wheel, for example, assuming you have a single table of customers in your database and also have two or more distinct systems that can manage this table in your database, all systems have connection to this database, so if you change a column of your customer table, you'll have to update the source code on all systems that work with that column, to solve this problem we have two solutions.  Depending on the size of your database, a good approach is to use procedures for updating, inserting or deleting data, and views for displaying data, making the tables virtually transparent to the application.  Another approach is to use webservices, you create a service to manage the customer base and all applications make calls directly to this service. In this case, this service is the only one who have access to the database, and applications have access only to the service in question, this architecture is called SOA (Service Oriented Architecture).  Today, for everything you need, you almost always find ways of not having to reinvent the wheel from project to project, if you work together with a large number of developers and designers, shares CSS, javascript or any other language's code, a framework can help and can also make the collaboration between the project members easier, moreover, sometimes even a single component can become a complex component that can be used in various parts of the same project in the future, so writting reusable components is paramount today, give some thought to the future is the key to your DON'T REPEAT YOURSELF.