Combating software entropy 2-roc1-
•Télécharger en tant que PPTX, PDF•
0 j'aime•527 vues
my presentation at The First Riyadh Online Summit 2010.
Recommandé
Contenu connexe
Similaire à Combating software entropy 2-roc1-
Similaire à Combating software entropy 2-roc1- (20)
Dernier
Dernier (20)
Combating software entropy 2-roc1-
- 2. Microsoft MVP for Connected Systems (6+ yrs) Member of BusinessTechnology Platform Advisors Author I do: Blog +Twitter + PodCast www.hammadrajjoub.net Follow me onTwitter @HammadRajjoub Bing me http://www.bing.com/search?q=hammadr ajjoub
- 3. Why is Software Complex? What is bad design? How to Fix it? Summary References QnA
- 4. Writing new software Mandated to develop new systems Generally from scratch But still mostly relying on existing libraries and frameworks Real-world problems are sometimes complex Modifying Existing Software Find that ‘bug’ and ‘fix’ it Add a new exciting feature Review and refactor to a better design
- 6. Rigid Fragile Immobile Hard to change! A single change break lots of other code Can’t be ‘extended’
- 7. Using design principles and practices The Single Responsibility Principle The Open Closed Principle Liskov Substitution Principle Dependency Inversion Principle Using Software Design Metrics Using advanced tools likeVS 2010 Ultimate And yes a whole lot of refactoring
- 8. None but Buddha himself must take the responsibility of giving out occult secrets... E. Cobham Brewer 1810–1897. Dictionary of Phrase and Fable. 1898.
- 9. "A responsibility is a reason to change, a class or module should have one, and only one, reason to change."
- 10. Responsibility is a ‘Reason for change’ Each responsibility is an axis of change There should never be more than one reason for a class to change Dijkstra’s SoC: Separation of Concerns This helps us evaluate a class ‘s exposure to change
- 11. Example:
- 12. BusinessPartner Validator Trade DB What is wrong here: Changes if DB changes or Business Logic Changes
- 13. internal class BusinessPartnerValidator { public void AssertValid(Trade t) { var sql = "SELECT COUNT(*) FROM BusinessPartner WHERE name=@Name"; using (var conn = CreateOpenConnection()) { var cmd = new SqlCommand(sql, conn); cmd.Parameters.Add("@Name", SqlDbType.VarChar); cmd.Parameters["@name"].Value = t.BusinessPartnerName; var count = (Int32) cmd.ExecuteScalar(); if (count != 1) throw new InvalidBusinessPartyException(t.BusinessPartyName); } } ... Where is the business logic? Hidden by database code.
- 14. internal class BusinessPartnerValidator { private readonly BusinessPartnerValidator businessPartnersource; public BusinessPartyValidator(BusinessPartnerSource BusinessPartySource) { this.businessPartnerSource = BusinessPartnerSource; } public void AssertValid(Trade t) { if (BusinessPartnerSource.FindByName(t.BusinessPartnerSource) == null) throw new InvalidBusinessPartnerException(t.BusinessPartnerName); } } BusinessPartyValidator now has a single responsibility
- 15. BusinessPartner Validator Trade DB BusinessPartner Source What's its job? Classes must have an identifiable single responsibility.
- 17. -High level modules should not depend upon low level modules. Both should depend upon abstractions. -Abstractions should not depend upon details. Details should depend upon abstractions.
- 18. BusinessParty Validator Trade DB BusinessParty Source High Level (Less Stable) Low Level (More Stable) Introduce stability with abstraction
- 21. IoC is key part of Frameworks Interfaces, Closures & Events Hollywood Principal (Don’t call us, We will call you) IoC is a very general name and hence the Dependency Injection* SuitsTest Driven Development Number of dependencies indicate stability*http://martinfowler.com/articles/injection.htm l
- 23. Afferent Couplings - Ca The number of other packages that depend upon classes within the package is an indicator of the package's responsibility. BPackage APackage Package Class
- 24. Efferent Couplings – Ce The number of other packages that the classes in the package depend upon is an indicator of the package's independence.BPackage APackage Package Class
- 25. Instability – I = Ce / (Ce + Ca) This metric is an indicator of the package's resilience to change. The range for this metric is 0 to 1, 0 indicating a completely stable package 1 indicating a completely instable package.
- 26. Maintainability Index Cyclomatic Complexity Depth of Inheritance Class Coupling Lines of Code Code Coverage
- 27. • CodeVisualizations DGML • Layered Diagrams • Good Old UML
- 28. -DGML -Layered Architecture andValidations -UML Diagrams
- 29. ISP: Interface Segregation Principle Avoid fat interfaces REP:The Release Reuse Equivalency Principle The granule of reuse is the granule of release. CCP:The Common Closure Principle Classes that change together are packaged together. CRP:The Common Reuse Principle Classes that are used together are packaged together. SDP:The Stable Dependencies Principle Depend in the direction of stability.
- 30. No significant program can be 100% closed Closures cant be complete Closures must be ‘Strategic’ Stability metrics can indicate hotpots Designer must choose the changes against which her design should be closed
- 31. Remember your application will outlive your expectation Follow these design principles Be Agile! Refactor ++ Use Code Metrics
- 32. Uncle Bob http://butunclebob.com/ArticleS.UncleBob.Pri nciplesOfOod Agile Principles, Patterns and Practices in C# Martin Fowler’s Blog: http://martinfowler.com/bliki/
- 33. © 2010 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.
Notes de l'éditeur
- In this session we are going to talk about how to tackle inherently complex nature of a software. I am going to show you 'most important principles, tools and techniques you can use to 'combat software entropy'. Together, we will gain an insight in to the heart of the software design. We will talk about the heuristics associated with the software design and architectural patterns and practices. Intended audience of this session in-general includes all the stake holders in software development process i.e. from Developer to Architect to Project and Program Manager and even CTOs and CIOs. However I have focused specially on targeting Software and Solutions Architects, i.e. individuals or teams responsible for the overall design and architecture of the solution. So, if you consider yourself as a stake holder in Software development process then you have come to the right place. Before I proceed further I would like to request you that feel free to participate in the discussion. I am very keen to hear from you and answer your questions as we walkthrough the slides. However if we run out of time, which tends to happen a lot :), then I should be available at the community lounge to answer your questions.
- Lets get rolling then, shall we?Heres an agenda:
- Using the term software in its broadest possible sense.There are two broad categories that software development falls into. First and the foremost is the 'Writing new code' classification. - Use-Case 1: Writing new code In this scenario we are mandated to develop new systems, mostly from the scratch but usually using some existing pieces of code e.g. Class libraries, frameworks, services etc etc. In this scenario we have more freedom and control over design and we can implement patterns and practices the way we would like it to be. Generally speaking, we are trying to solve real world problems, like business automation, weather forecasting, algorithmic trading etc etc. There is an inherent disconnect between the real world and our software programming model and that very fact is at the heart of software complexity. - Use-Case 2: Now, how many time do we get to write new software? Lets do a show of hands here. I am guessing that most of the time we end up working on existing code bases, where we have to - find that tormenting bug and fix it. - add a new exciting feature - and if you are lucky or unlucky like me then review it and refactor it so that i can handle change in a better way This scenario is complex because. 1- We generally find it difficult to understand some one else’s code 2- We believe ‘we would have done it in a different/better way’ 3- 2 is true even if we ourselves were the author of that code few years back
- As Architects how do we identify the good, the bad and the ugly of Software Design.For that perhaps we need some metrics such that we can always measure and identify which side of the fence our software belongs to.
- How many times have you come across the code that you can qualify as a ‘bad design’? Or atlease and most commonly would have said, That’s not the way I would have done it.Before we move on. Lets agree on what's a bad design? Ok it’s a bit difficult to be exact about the metrics of bad design in software. But lets agree on some common aspects of bad design.Rigidity FragilityImmobilityCode that’s hard to change is bad… Rigid code is bad!Code that has lots of ripple effects.. A single change break lots of other code. Fragile code is bad!Code that cant be re-used… Code that cant be ‘extended’ is bad.. Immobile
- Now that we know what the bad design is. Lets see how we can fix it? Would you be interested in identifying the principles and practices that will help you make sure that your design, architecture and code is not rigid, your solutions are not fragile and your frameworks are not immobile.Wouldn’t you like to have flexibility in your design, resiliency in your architecture and agility in your frameworks such that they can adapt to the ever changing business requirements.Lets drill down to each of these principles and see what can we do to fix our bad design.
- If a class has more then one responsibility, then the responsibilities become coupled. Changes to one responsibility may impair or inhibit the class’ ability to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed.
- What is responsibility? … It is a reason for change.We should consider each responsibility as an axis of change. The more axis of changes the more dimension effected.As a right hand rule, there should never be more than one reason for a class to change.The term separation of concerns was probably coined by Edsger W. Dijkstra in his 1974 paper "On the role of scientific thought"[1].Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained --on the contrary!-- by tackling these various aspects simultaneously. It is what I sometimes have called "the separation of concerns", which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by "focusing one's attention upon some aspect": it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.
- BusinessPartner
- Example do demonstrate role based interfaces IVE examples
- Mention ronald’s session here.
- Classes should have a single responsibility or jobDevelopers should have that job in mind when they work on a classA developer should easily be able to write a block comment at the top of a class identifying its job.That comment should not have the word AND in it.As architects and leads we should be able to ask this question.. Whats the job of this class? a developer should always have this job in mind use intuitive and simple names remember! no conjunctions (ANDS)
- Add an example
- - “All systems change during their life cycles. This must beborne in mind when developing systems expected to last longer than the first version.” - SOFTWARE ENTITIES(CLASSES,MODULES,FUNCTIONS,ETC.) SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR MODIFICATION- Bertrand Myers in 1988It says that you should design modules that never change . When requirements change, you extend the behaviour of such modules by adding new code, not by changing old code that already works.When a single change to a program results in a cascade of changes to dependent modules,that program exhibits the undesirable attributes that we have come to associate with “bad”design. The program becomes fragile, rigid, unpredictable and unreusable. The openclosedprinciple attacks this in a very straightforward way. It says that you should designmodules that never change. When requirements change, you extend the behavior of suchmodules by adding new code, not by changing old code that already works.The modules that follow OCP have the following two characteristics:=-1. They are “Open For Extension”.This means that the behaviour of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.2. They are “Closed for Modification”.The source code of such a module is inviolate. No one is allowed to make source code changes to it.
- Composabilityvsinheritence
- Define degenrate methodsShow an example here.
- *Uml compatible.
- - Inversion of control is the basic feature of any framework in a way that frameworks are differentiated from libraries by offering the support for ‘Hollywood Principal’ (‘Don’t call us , we will call you’)- One important characteristic of a framework is that the methods defined by the user to tailor the framework will often be called from within the framework itself, rather than from the user's application code. The framework often plays the role of the main program in coordinating and sequencing application activity. This inversion of control gives frameworks the power to serve as extensible skeletons. The methods supplied by the user tailor the generic algorithms defined in the framework for a particular application.--Ralph Johnson and Brian Foote
- Afferent Couplings (Ca): The number of other packages that depend upon classes within the package is an indicator of the package's responsibility. -------------Show how visual studio does it.
- Efferent Couplings (Ce): The number of other packages that the classes in the package depend upon is an indicator of the package's independence.
- Instability (I): The ratio of efferent coupling (Ce) to total coupling (Ce + Ca) such that I = Ce / (Ce + Ca). This metric is an indicator of the package's resilience to change. The range for this metric is 0 to 1, with I=0 indicating a completely stable package and I=1 indicating a completely instable package.
- MI: http://blogs.msdn.com/fxcop/archive/2007/11/20/maintainability-index-range-and-meaning.aspx 0-100 range.20-100 is green.The maintainability index has been re-set to lie between 0 and 100. How and why was this done?The metric originally was calculated as follows (based on the work in Carnegie Mellon University although we modified the Halstead Volume calculation a little since we don't include comments anywhere in our calculation): Maintainability Index = 171 - 5.2 * ln(Halstead Volume) - 0.23 * (Cyclomatic Complexity) - 16.2 * ln(Lines of Code)This meant that it ranged from 171 to an unbounded negative number. We noticed that as code tended toward 0 it was clearly hard to maintain code and the difference between code at 0 and some negative value was not useful. I'll post some tech ed sample code showing very low maintainability or you can try on your own code to verify. As a result of the decreasing usefulness of the negative numbers and a desire to keep the metric as clear as possible we decided to treat all 0 or less indexes as 0 and then re-base the 171 or less range to be from 0 to 100. Thus, the formula we use is:Maintainability Index = MAX(0,(171 - 5.2 * ln(Halstead Volume) - 0.23 * (Cyclomatic Complexity) - 16.2 * ln(Lines of Code))*100 / 171)On top of that we decided to be conservative with the thresholds. The desire was that if the index showed red then we would be saying with a high degree of confidence that there was an issue with the code. This gave us the following thresholds (as mentioned in this blog previously):For the thresholds we decided to break down this 0-100 range 80-20 so that we kept the noise level low and only flagged code that was really suspicious. We have:0-9 = Red 10-19 = Yellow 20-100 = Green-----------------------------------------------------------------------------------------------------------------------------------------------CC: http://en.wikipedia.org/wiki/Cyclomatic_complexityCyclomatic complexity is computed using the control flow graph of the program: the nodes of the graph correspond to indivisible groups of commands of a program, and a directed edge connects two nodes if the second command might be executed immediately after the first command. Cyclomatic complexity may also be applied to individual functions, modules, methods or classes within a program.Limiting complexity during developmentOne of McCabe's original applications was to limit the complexity of routines during program development; he recommended that programmers should count the complexity of the modules they are developing, and split them into smaller modules whenever the cyclomatic complexity of the module exceeded 10.[2] This practice was adopted by the NIST Structured Testing methodology, with an observation that since McCabe's original publication, the figure of 10 had received substantial corroborating evidence, but that in some circumstances it may be appropriate to relax the restriction and permit modules with a complexity as high as 15. As the methodology acknowledged that there were occasional reasons for going beyond the agreed-upon limit, it phrased its recommendation as: "For each module, either limit cyclomatic complexity to [the agreed-upon limit] or provide a written explanation of why the limit was exceeded."[5]
- Since closure cannot be complete, it must be strategic. That is, the designer must choose the kinds of changes against which to close his design. This takes a certain amount of prescience derived from experience. The experienced designer knows the users and the industry well enough to judge the probability of different kinds of changes. He then makes sure that the open-closed principle is invoked for the most probable changes.So in a way its not just the language and the compiler and the ide itself. But the effort on the part of the designer to think and re think about these aspects and then do/refactor the design
- We believe we have given you an insight into the heart of the software complexity and stability in the face of change.Now, not only you can judge your design using these principals.you can measure them quality of your design using software design metrics. What are those metrics and how do they work is beyond the scope of this discussion but definitely worth looking at.Code metrics:Maintainability IndexCyclomatic Complexity Depth of InheritenceClass Coupling http://msdn.microsoft.com/en-us/library/bb385914(VS.100).aspx VS has it,