Recommandé
Contenu connexe
Tendances
Tendances (19)
En vedette
Similaire à Code sense
Similaire à Code sense (20)
Dernier
Dernier (20)
Code sense
- 1. Nasir Jamal (a.k.a. nas) LCN.com
- 2. Code Sense Writing better Code
- 3. Ruby
- 5. Disclaimer I am talking about how to write good quality code but that does not mean that I always write perfect code. I do slip to the dark side sometimes.
- 6. How would you measure the quality of code?
- 8. Some ruby code What do you think about this code?
- 10. Add new functionality or change the flow of the same code
- 12. Refactoring Change internal structure of the code without changing it's observable behaviour.
- 13. Why refactoring? Any code that is difficult to understand and restricts adding new functionality to it or extending, needs refactoring.
- 17. Thank you Q? twitter.com/_nasj nasir.wordpress.com github.com/nas stackoverflow.com/users/200486/nas
Notes de l'éditeur
- I am going to talk about some common sense approach to code quality, ie. Code sense . How we can take some basic measures to make sure that the code we write is of sufficiently good quality and that makes sense to us when we come back to it after a week, month or even to any one new to that code.
- And I will be using ruby to demonstrate that because I use ruby to code and I think it is an elegant, very flexible and pure object oriented language. Everything in ruby is an object even the integers. What that means is you can pass messages to integers, i.e. call methods on them for exampe
- Integer 12 is an instance of class Fixnum. I can pass it messages like class to find out what type of object it is, modulo, to_s and to_f to convert it to string or float. This looks and sounds very simple but if you think of it then this becomes very powerful when it comes to do metaprogramming i.e. programs that can generate programs dynamically. Thats enough for ruby, if you want to know more about ruby then catch me after the talk
- I am gonna talk about how to write good quality code but that doesnt mean that I always write perfect code. I do slip to the dark side but every good programmer knows that they rarely write good code in the first instance. I will come back to this later during my talk.
- Measuring code quality is very subjective because the code that is of sufficiently good quality for me may be of very bad quality for someone else. You can only measure code in relative terms. Though there are tools available to check the cyclomatic complexity, code duplication, test coverage, structural similarity, etc. For instance, in ruby world we have a library/gem available called metric_fu that people who care about code quality use to get some metrics on code. Can anyone give me some idea like given some code how would you measure its quality I think the image on the next slide shows the best way to measure code quality.
- Show code I will show you some code that has been used on an ecommerce site for subscriptions.
- The moment you see any of the above in a code then that is a target rich environment for bad code.
- However bad, a code is, If it is in production then no one would touch it unless there is a requirement to change its functionality. And the rules of economy dont permit that as well but it shouldn't have been there in the first place So this code has been working fine doing automatic renewals of user services but now lets say we want to add auto renewals for some new products that have slightly different requirements or process flow.
- If you don't care about your code quality then what you are gonna do is bodge in another if / switch statement somewhere in the run method and job done. DBAD = Don't be a dick
- Number of time people say that they are refactoring but they are actually changing the code while adding new functionality which is a bit dangerous because you might introduce bugs while doing that. So hold on your new functionality and first refactor the code. The main ingredient of refactoring is to have unit and integration tests. If you already have them then go ahead changing test as well as code else first add the tests so you know when you break anything,
- Once I found some bad code that I thought needed refactoring. That code started doing something very simple about few months ago about showing different messages to users when a user request is complete. Sounds simple but it became a bit complicated after we added a background worker that will process the queues. Sometimes queues get held up due to some reason or the other. And then you need to show different messages to the users. So we passed different parameters to the redirected page and on the controller action of that redirected pages we ended up adding so many if / else statements to show different messages based on the presence of different parameters I was about to modify something and I saw that and said to myself F*UGLY. - discussed, lunch,back, got an idea, show n tell, discussed about the schedule, implemented
- So I refactored the code and one of my colleague also pitched in during final stages of refactoring that basically led to this,
- Should be small Named appropriately Do onlly one thing Should be at the same level of abstraction Should use minimum number of parameters