Code quality
Download as PPTX, PDF1 like1,147 views
Code quality is important to ensure code is easy to understand, maintain and extend. Key aspects of code quality include having high test coverage, following design principles like SOLID, and using metrics like maintainability index and technical practices such as pair programming, code reviews, refactoring and test-driven development. Tools like Visual Studio and Resharper can help analyze code quality metrics and identify areas for improvement.
Ad
More Related Content
What's hot (20)
Viewers also liked (17)
Ad
Similar to Code quality (20)
Ad
Code quality
- 1. Code Quality And Modern Technical Practices 1
- 2. Code Quality • What is code quality • Code quality Metrics • How to improve code quality – Practices – Design Principles – Tools 2
- 3. Quality code is • Easy to understand • Simple to maintain • Easy to extend • Reuse in the future • Code must have unit test CodeQuality 3
- 4. Why we need to bother for code quality ? 4
- 5. Cost of change One of the universal assumption of software engineering is that cost of changing a program rises exponentially over time . 5
- 8. Code Quality Metrics • Lines of code • Depth of Inheritance Tree • Coupling Between Object Classes • Lack of Cohesion in Methods • Maintainability Index 8
- 9. Lines Of Code • Function • Classes 9
- 10. Function • Function should be small • Functions should not have too many arguments • Avoid flag arguments • Command query separation • Should follow SRP and OCP 10
- 11. Classes • A class is a collection of data and routines that share a cohesive, well-defined responsibility. • A class might also be a collection of routines that provides a cohesive set of services even if no common data is involved. 11
- 12. Classes • Classes should be small So How many lines ? • Instead of lines we count responsibilities . • Classes should have one responsibility – one reason to change 12
- 13. Depth of inheritance tree • Deeply nested type hierarchies can be difficult to follow, understand, and maintain • Types where Depth Of Inheritance is higher or equal than 6 might be hard to maintain. • However it is not a rule since sometime your classes might inherit from third-party classes which have a high value for depth of inheritance. 13
- 14. Coupling • Coupling among classes or subsystems is a measure of how interconnected those classes or subsystems are. • Tight coupling means that related classes have to know internal details of each other • Changes ripple through the system, and the system is potentially harder to understand. • It is a good practice to have types and methods that exhibit low coupling and high cohesion • Types and methods that have a high degree of class coupling can be difficult to maintain. 14
- 15. Removing Coupling • Factories • Dependency Injection 15
- 16. Cohesion 16
- 17. Cyclomatic complexity • The number of decisions made in our source code • We use cyclomatic complexity to get a sense of how hard any given code may be to test, maintain, or troubleshoot as well as an indication of how likely the code will be to produce errors. 17
- 18. Maintainability Index • Maintainability Index –An index value between 0 and 100 that represents the relative ease of maintaining the code. A high value means better maintainability. • 0-9 = Red • 10-19 = Yellow • 20-100 = Green Maintainability Index = MAX(0,(171 - 5.2 * ln(Halstead Volume) - 0.23 * (Cyclomatic Complexity) - 16.2 * ln(Lines of Code))*100 / 171) 18
- 19. Halstead Program Volume • Halstead Program Length N = N1 + N2 • Halstead Program Volume V = N * log2(n1 + n2) N1 The total number of operators present. N2 The total number of operands present. n1 The number of distinct operators present. n2 The number of distinct operands present. 19
- 20. Duplicate Code • Identical code at different place – Extract method • Switch/case or if/else chain that appears again and again in various modules , always testing for the same set of conditions - Replaced with polymorphism • Same algorithm , but that don’t share similar lines of code – Template method or Strategy pattern • Same code in two sibling classes 20
- 22. Practices Design Principals Tools Coding Standard Pair Programming Code Review Test Driven Development Continuous Integration Agile Extreme Programming Refactoring Mentorship Acceptance test driven development BDD SOLID Design Principal GOF Design Patterns Visual Studio 2012 Resharper FxCop Stylecop Ncover Ndepend Sonar Small cycle feedback Communication & Collaboration Collective Ownership Unit testing Code Coverage GRASP 22
- 23. 23
- 24. SOLID • Single responsibility principle • Open/closed principle • Liskov substitution principle • Interface segregation principle • Dependency inversion principle 24
- 25. Single responsibility principle Class should have only one reason to change 25
- 27. Open/closed principle Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. 27
- 28. public void DrawAllShapes(IList shapes) { foreach(Shape shape in shapes) shape.Draw(); } 28
- 29. Liskov substitution principle Subtypes must be substitutable for their base types 29
- 30. LSP Example public class Rectangle { private double width; private double height; public virtual double Width { get { return width; } set { width = value; } } public virtual double Height { get { return height; } set { height = value; } } } public class Square : Rectangle { public override double Width { set { base.Width = value; base.Height = value; } } public override double Height { set { base.Height = value; base.Width = value; } } 30
- 31. void g(Rectangle r) { r.Width = 5; r.Height = 4; if(r.Area() != 20) throw new Exception("Bad area!"); } 31
- 32. Dependency inversion principle • High-level modules should not depend on low-level modules. Both should depend on abstractions. • Abstractions should not depend upon details. Details should depend upon abstractions. 32
- 33. DIP Example • Consider a Button and Lamp object Button Lamp +Poll() +TurnOn() +TurnOff() 33
- 34. Public class Button { Private Lamp lamp; Public void poll() { If(/*some condition */) lamp.TurnOn(); } } 34
- 36. 36
- 37. 37
- 38. Interface segregation principle Clients should not be forced to depend upon interfaces that they do not use 38
- 39. Coding standards Programmers write all code in accordance with rules. 39
- 40. Code Review Problems are found later, when they are more expensive to fix It is well documented that the later a bug is found the more expensive it is to fix. Before submitting something for a code review, a conscientious developer will have designed a solution, coded it, written unit and integration tests for it, and probably done some manual acceptance testing as well, all in preparation for checking in. If a problem is found in a subsequent code review, that whole process has to start again, at least to some degree. By contrast, pair programming finds those problems earlier on in the life cycle, thereby requiring less rework to fix. Pair programming is defect prevention. You find problems earlier, when they are cheaper to fix. Context switching is required, which lowers productivity Code reviews don't happen instantly. They take time. Other developers are busy. What are you going to do while you are waiting for the review to complete? Hopefully you are not going to sit around doing nothing - you are going to start on the next story. Then the next day (or after several days, in some situations I have been in) you are going to receive feedback from the review. In general you can respond in one of two ways: you can defend the code the way it is, or you can agree to make the suggested change. Either way, you need to get back to the state the code was in at the time of the review. But you have since moved on; you have made other changes to the code. Sure, there are strategies for handling this. You can create a patch file for your current changes and revert them. You can create and work in a separate branch for each story. But there is overhead in these approaches. In addition to the context switching of the actual code, there is the mental context switching in your head. You have moved on to other problems, but now have to get your brain wrapped around the previous issues again. I suspect that of the two types of context switching, this one (the mental one) has the greater cost. With pair programming, on the other hand, you are finding and addressing problems right while you are in the midst of them - no context switching required. Quality is lower, because of resistance to changing working, tested code When asked what he thought of code reviews, I heard one developer say "It just feels like it's too late". In talking further, what he was getting at was that by the time the code review happens, all this work of coding and testing has already been done. To suggest that we tear it all up and rework it doesn't seem all that productive at that point. Sure, if something is really broken it will have to be addressed, but otherwise, people tend to want to leave it as is. Another aspect of this is that even if some changes are made to fix a problem, they often tend to be band-aid solutions, because you are now retrofitting existing code; the end result won't be of the same quality as a pair working together from the beginning. It's like the difference between building a house, then having an inspection, and then fixing the problems the inspector found, versus building a house with an inspector alongside you the entire time. No band-aids placed over things, just quality code from the ground up. Bad feelings can arise between team members This one is less common than the others, but I have seen it happen. While we would like to think that we are all objective-minded and don't become emotionally invested in our code, that isn't always the case. And after designing, coding, and testing it we are more invested in it than if it was still just in the idea phase. In a code review, it is our working, tested, finished product that is being critiqued. When pairing, there is still a lot of critiquing going on (probably even more than in a code review), but it is happening earlier in the process; usually in the idea phase when we are less invested in a specific solution. Overall, code reviews can feel more adversarial than pair programming (which feels very collaborative). It's all about collaboration - don't just write something and throw it over the wall for a code review. Pair program! 40
- 41. Agile 41
- 42. Scrum • Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time. • It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month). • The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features. • Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint 42
- 43. Scrum 43
- 45. Test Driven Development Create a failing test – Red Make the test pass – Green Refactor – Improve the internal implementation without changing the external contract or behavior 45
- 46. 46
- 47. Pair Programming All production code is written with two programmers at one machine. If people program solo they are more likely to make mistakes, more likely to overdesign, and more likely to blow off the other practices, particularly under pressure. 47
- 48. 48
- 49. 49
- 50. 50
- 51. 51
- 52. Economics of pair programming Pair programming will double code development expenses 52
- 53. 53
- 54. 54
- 55. Extreme Programming Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, courage, and respect. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation. • Core Practices – Whole Team – Pair Programming – Incremental Design – Continuous Integration – Test-First Programming – Weekly Cycle – Ten-Minute Build 55
- 56. ATDD Drive implementation of a requirement through a set of automated , executable acceptance tests About – Communication – Collaboration – Process improvements – Better Specification
- 57. Acceptance test driven development 57
- 58. Code Coverage 58
- 59. Refactoring Programmers restructure the system without changing its behaviour to remove duplication, improve communication, simplify, or add flexibility. 59
- 60. Refactoring • Improves the design of Software • Makes software easier to understand • Helps you find bugs • Helps you program faster 60
- 61. When we should refactor All the time 61
- 62. Tools • Visual Studio 2012 • Stylecop • FxCop • Resharper • Ncover • Ndepend • Sonar 62
- 63. Visual Studio 2012 • Maintainability Index • Cyclomatic Complexity • Depth of Inheritance • Class Coupling • Lines of Code • Duplicate Code • Code Coverage 63
- 64. Exercise Revisit your previous coding efforts, try to find ways you can improve the old code. 64
- 66. ? 66
Editor's Notes
- #4: Programming in many ways a conversation with a computer . We write code that tells the computer what to do , and respond by doing exactly what you tell it . In time you close the gap between what you want it to do and what you tell it to do . Programming in this mode is all about saying exactly what you want . But there is another user of your source code . Someone will try to read your code in a few month’s time to make some changes . We easily forget that extra user of the code , yet that user is actually the most important . Who cares if the computer takes a few more cycle to compile something ? It does matter if it takes a programmer a week to make change that would have taken only an hour if she had understood your code .
- #7: Defects fixing are highly unpredictable .
- #11: Avoid flag arguments – passing a boolean into a function is truly terrible practice . Loudly proclaiming that this function does more than one thing . It does one thing if the flag is true and another if the flag is false .Command query separation – Function should either do something or answer something , but not both . Doing both often leads to confusion.
- #13: Trying to identify responsibilities (reasons to change) often helps us recognize and create better abstraction in our code .Every sizable system will contain a large amount of logic and complexity . The primary goal in managing such complexity is to organize it so that a developer knows where to look to find things and need only understand the directly affected comlpexity at any given time . In contrast ,a system with larger , multipurpose classes always hampers us by insisting we wade through lots of things we don’t need to know right now .
- #19: Halstead Program Volume V = N * log2(n1 + n2)
- #21: Dave Thomas And Andy Hunt – DRYKent Beck – Once and only once
- #27: It says “Things changed for the same reason should be grouped together”For example : in MVVM -> View needs to be changed if we update view Model -> model needs to changed if we need to update some business ruleIf we have Module separated on the basis of “SRP” than deployment will be always easierDisadvantage Maintenance will be difficult
- #35: This solution violates DIP . The high-level policy of the application has not been separated from the low-level implementation . The abstraction have not been separated from the details .
- #36: Finding the Underlying AbstractionWhat is the high-level policy? It is the abstraction that underlies the application, the truths that do not vary when the details are changed. It is the system inside the system it is the metaphor. In the Button/Lamp example, the underlying abstraction is to detect an on/off gesture from a user and relay that gesture to a target object. What mechanism is used to detect the user gesture? Irrelevant! What is the target object? Irrelevant! These are details that do not impact the abstraction.The model in Figure 11-3 can be improved by inverting the dependency upon the Lamp object. In Figure 11-4, we see that the Button now holds an association to something called a ButtonServer, which provides the interfaces that Button can use to turn something on or off. Lamp implements the ButtonServer interface. Thus, Lamp is now doing the depending rather than being depended on.
- #42: Agile provides opportunities to write quality code . Reliable estimates benefit developers by allowing them to work at sustainable pace . This leads to higher quality code and fewer bugs .
- #48: The idea is two developers work on the same machine. Both have keyboard and mouse. At any given time one is driver and the other navigator. The roles switch either every hour, or whenever really. The driver codes, the navigator is reading, checking, spell-checking and sanity testing the code, whilst thinking through problems and where to go next. If the driver hits a problem, there are two people to find a solution, and one of the two usually has a good idea.Other advantages include the fact that where two people have differing specialities, these skills are transferred. Ad-hoc training occurs as one person shows the other some tricks, nice workarounds, etcetera.The end result is that both developers are fully aware of the code, how it works, and why it was done that way. Chances are the code is better than one developer working alone, as there was somebody watching. It's less likely to contain bugs and hacks and things that cause maintenance problems later.In a bigger team, the pairing can change each week so each team member is partnered with somebody different. This is a huge advantage, as it gets developers talking and communicating ideas in the common language of code.We found this to be as fast as working separately. The code got written quicker and didn't require revisiting. And when it did need to change, more than one person was familiar with the code.