Web application implementation step 4: Copying is not reusing
RT @thibauld Web application implementation step 4: Copying is not reusingIt is often said that "good coders code, great reuse" (see an example here). I definitely agree with this... unfortunately, too often, developers think that reusing code means copying code. How often did you see developers looking for code snippets on google to find a way to implement any given functionality, convinced that it will save them time... Unless the code snippet you're looking for is yours (= one you developed and, by extension, master), this behaviour will not help you much... Worse, it will even slow you down and here's why:
- you spend time on google, blogs, groups, forums... trying to find the code snippet that fits your needs
- you find something that is supposedly doing what you want but how to know exactly if it's ok ? It would require to carefuly examine the code... but it takes time... and you wanted to find a code snippet to save time so you decide it must be ok.
- you include the snippet in your own code but you have to spend some time adapting it because it can't be included "as is".
- finally you think it's ok and test your code. Not bad but it's not exactly what you expected so you're back hacking the snippet. As it is not your code, you're reluctant to study it in depth (and you're a bit lazy) so you treat it as a black box: you change a value here, a value there... "it should do it". And you spend time fine tuning it.
- you finally have the functionality you wanted. Too bad, the guy who wrote the snippet was not an expert and you're now facing crashing, security and/or performance issues with this code. You now have to spend time trying to fix a code that is not yours.
Now did you really save time ? To make things worse, you did not learn anything in the process... This method looks sexy at first sight but beware as it's a trap! When facing a new problem, you'll be better off understanding it and tackling it on your own and now! You have several solutions:
- Find a library, a webservice... which adresses the issue you're facing. What's the difference between this solution and using code snippets ? Simple: library, webservices etc... is code that is meant to be reused! They are tested, documented and maintained pieces of code... not a piece of code coming out of nowhere pasted on a blog around 2 photos from flickr.
- Use a code snippet you wrote. It is an issue you already tackled in the past and you coded something to address the issue. In this case, there is no problem in reusing your own code. You wrote it, you know it, know how it works, in which context it has been developed and which exact problem it solves.
- Code a solution by yourself. You can look for inspiration in others' code snippets but you should code the solution yourself. This way, you are sure to code something that adress your exact issue and you're improving your knowledge and skills. Plus, next time you'll be facing the problem, you'll be able to solve it in a few minutes.
It is often said that "good coders are lazy". This is true, but it's hard becoming a lazy coder and lazy coders are most of the time hard working people
Web application implementation step 2: build on solid foundations!
RT @thibauld Web application implementation step 2: build on solid foundations!In a previous post, I wrote about choosing the right tools to build your website. For Freelance Business Club, we chose to use the following stack: Linux (Ubuntu 8.04) / MySQL5 / Apache2 / PHP5 (with Smarty). One of the thing that influenced us in our choice was the study of Flickr.com's architecture. We knew that, provided we did things well, the chosen stack could perform well in a production environment and that it could scale.
But obviously, using the rights tools is necessary but not sufficient to build a great app. The next step is to setup your code architecture. A good code architecture / organization features:
- Reusability. You should not have to duplicate your code (unless you want to). It will make bug fixing and maintenance a lot easier.
- Flexibility. Modifying or enhancing something in your web application should be as easy as possible: adding new feautres, changing graphical chart, database engine, underlying hardware architecture... Having a great code architecture will help you make your web application evolve smoothly and quickly over time.
- SEO friendly. Unless you're working on a private web application, you'll have to deal with SEO, in particular with Google. This is why it is really important that your code architecture let you master your URLs so that it doesn't block you in your SEO strategy.
- Simplicity. It should be easy to dive into your code architecture. It should be easily comprehensible. This will help you boost the productivity of your employees and interns and will save you valuable time. Note: documentation is not the answer here. It's probably part of the answer but I tend to believe that the more obfuscated your code and architecture, the bigger the documentation...
- Performance. All the above is futile if your web application responsiveness is ridiculous. You should make sure that your code architecture does not structurally lower your application's performance. It will not prevent your developers to write bad code that will bloat your app but, at least, they will not be able to hide behing your architecture and you'll know who to blame
In short, a good code architecture should provide coding agility and application robustness. Now let's see concretely how to you achieve this result.
First, it is crucial to separate the various logic layers which compose a web application. The principle is dead simple: a layer only needs to know about its adjacent layers (above and below him). Here's a schema representing the different layers involved in a web application:
Client layer. This layer is located in the webbrowser itself. It displays to the user what has been transmitted by the Presentation layer. The only code that gets executed in this layer is Javascript.
Presentation layer. This layer's role is to:
- handle the requests coming from the client
- call the adequate business methods to fetch the results corresponding to the client request
- prepare the business variables for rendering
- build the output (consisting of HTML and CSS)
- pass the final result to the client layer
I'd like to emphasize that this is generally a good idea to separate this layer in 2 in order to separate the gathering and formatting of business variables from the final output building process. I personally like to use Smarty for this 'output building process'.
Business layer. This is the layer where real business specific code is implemented. All the application logic lies in here. Business functions are called by the Presentation layer. In most cases, they interact with the Data layer to fetch/update/insert/delete data. To minimize variable entropy, it is important at this stage that the values returned by the Business layer to the Presentation be normalized.
Data layer. All interactions with the database are concentrated in this layer. It isolates the Business code from the underlying database. All SQL queries are located in this layer.
Provided you organized your code in layers, you already made a huge leap forward in your attempt to build a maintainable web application. Layers help achieve reusability and flexibility. Now, to build a SEO friendly code architecture, you'll have to deal with Apache URL Rewriting module. No, you should NOT organize your files on the filesystem to match your URLs
Now, I know what you're going to tell me... given what I said, it's clear that one should try as much as possible to use a framework to build his web app. Indeed, frameworks help you structure your code well by giving you guidelines and conventions. Right but only partly true...The problem is that, even if code architecture is important, it's only (little) part of the problem of building a great web app. Too many people tend to rely on the framework, thinking that having the right framework will maximize their chance of building a successful web app. This would be great but it is unfortunately a wrong reasoning... Frameworks may help you code quicker and structure your code well but to build a great web application, all you need is a methodology. This will be the subject of my next post... stay tuned!
PS: My friend Arnaud started to blog (in french) about creating an identity for your web application.