This document discusses refactoring code to improve its quality. It begins by explaining that refactoring is about fixing code by improving its structure and design while maintaining its external behavior. It then discusses what makes code good or bad, focusing on qualities like robustness, simplicity and being easy to change. Common code smells that make code hard to understand and modify are identified, such as duplicated code, large classes and long methods. Refactoring is defined as changing code without changing its external behavior but improving its internal structure. Reasons for refactoring include improving maintainability and making code easier to understand and modify. The document outlines a refactoring cycle of selecting a code smell to address, choosing a refactoring technique,
The core idea of lean is to eliminate/reduce non-value-added activities (termed "wastes") and thus increase customer value. The Agile itself is a lean for the software development life cycle, and I am sharing a couple of Agile best practices adopted by my teams to make the Scrum methodology more extra lean.
The presentation contains the best agile practices and their benefits in terms of Lean in an agile methodologies
Second "code school lesson" for Eurosport's developers.
1. Refactoring : when? why? how?
2. Single Responsability
3. Practical case : clean architecture.
The process of changing a software system in such a way that it does not alter the external (observable) behavior of the code yet improves its internal structure, to make it easier to understand and cheaper to modify.
Cucumber is a tool which supports development via behavior realization (BDD - Behavior-Driven Development). It is considered to be utilized for creating the tests which can be understood by each and all, even without special technical knowledge.
(by QATestLab)
Respond to What Your Code & What Your Business are Saying When the business is asking for more features, the developers respond by simply adding to that cute little function and it gets bigger and messier. Although it gets harder to understand, well-meaning developers still work with that design. It creaks like a rotting floor, no one does anything different and keeps adding more and more. In this workshop, Lance will show how to componentize so we stop being code-zombies, and where adding new features would mean adding new objects.
The core idea of lean is to eliminate/reduce non-value-added activities (termed "wastes") and thus increase customer value. The Agile itself is a lean for the software development life cycle, and I am sharing a couple of Agile best practices adopted by my teams to make the Scrum methodology more extra lean.
The presentation contains the best agile practices and their benefits in terms of Lean in an agile methodologies
Second "code school lesson" for Eurosport's developers.
1. Refactoring : when? why? how?
2. Single Responsability
3. Practical case : clean architecture.
The process of changing a software system in such a way that it does not alter the external (observable) behavior of the code yet improves its internal structure, to make it easier to understand and cheaper to modify.
Cucumber is a tool which supports development via behavior realization (BDD - Behavior-Driven Development). It is considered to be utilized for creating the tests which can be understood by each and all, even without special technical knowledge.
(by QATestLab)
Respond to What Your Code & What Your Business are Saying When the business is asking for more features, the developers respond by simply adding to that cute little function and it gets bigger and messier. Although it gets harder to understand, well-meaning developers still work with that design. It creaks like a rotting floor, no one does anything different and keeps adding more and more. In this workshop, Lance will show how to componentize so we stop being code-zombies, and where adding new features would mean adding new objects.
Improve your development skills with Test Driven DevelopmentJohn Stevenson
A talk at the Graduate Developer community on test driven development. Helping students and graduates understand the point of a test first approach, demonstrate the tools and show how easy it is to start.
It is a software testing tool which works of the Glass testing technique. In this presentation people will get to know that how this tool work and help the tester.
Journey with XP a case study in embedded domain by Pradeep Kumar NRXP Conference India
Journey with XP a case study in embedded domain @XP conference 2016 Through this presentation, Pradeep will share his learning experience and describe his journey with XP that has been part of his life since 2 yrs. This talk also unfolds some aspects of how to adopt XP in embedded space with multiple layers involved and when there is a dependency on hardware
We have all bought into the idea of writing tests for our code. But are we writing our code in a way that make our tests better?
The full deck from Andrew Trebble's DrupalCamp Ottawa Presentation July 2016.
Improve your development skills with Test Driven DevelopmentJohn Stevenson
A talk at the Graduate Developer community on test driven development. Helping students and graduates understand the point of a test first approach, demonstrate the tools and show how easy it is to start.
It is a software testing tool which works of the Glass testing technique. In this presentation people will get to know that how this tool work and help the tester.
Journey with XP a case study in embedded domain by Pradeep Kumar NRXP Conference India
Journey with XP a case study in embedded domain @XP conference 2016 Through this presentation, Pradeep will share his learning experience and describe his journey with XP that has been part of his life since 2 yrs. This talk also unfolds some aspects of how to adopt XP in embedded space with multiple layers involved and when there is a dependency on hardware
We have all bought into the idea of writing tests for our code. But are we writing our code in a way that make our tests better?
The full deck from Andrew Trebble's DrupalCamp Ottawa Presentation July 2016.
Kort præsentation af Arlas brug af blogs og sociale medier. Præsentation i forbindelse med It-Forum netværksmøde d. 17/6 2010. Anden taler på mødet var Anders Colding-Jørgensen.
Presentation for the Nordic Sensory Workshop in Iceland, May 2010. Focus on how to use blogs and social media in relation to consumer communication and research illustrated through cases from Arla and other examples.
Refactoring: Improve the design of existing codeValerio Maggio
Refactoring: Improve the design of existing code
Software Engineering class on main refactoring techniques and bad smells reported in the famous Fawler's book on this topic!
Presentation on writing clean and maintainable good. I have present really simple steps to write high quality code and share many more benefit of writing clean code.
”In general programmers are pretty smart people. Smart people sometimes like to show off their smarts by demonstrating their mental juggling abilities. One difference between a smart programmer and a professional programmer is that the professional understands that clarity is king. Professionals use their powers for good and write code that others can understand.”
How I Learned to Stop Worrying and Love Legacy Code.....Mike Harris
Legacy Code. I never wrote it; everybody else did!
How many times have you waded through an ageing, decaying, tangled forrest of code and wished it would just die?
How many times have you heard someone say that what really needs to happen is a complete rewrite?
I have heard this many times, and, have uttered that fatal sentence myself.
But shouldn’t we love our legacy code?
Doesn’t it represent our investment and the hard work of ourselves and our predecessors?
Throwing it away is dangerous, because, before we do, we’ll need to work out exactly what it does, and we’ll need to tweeze out that critical business logic nestled in a deeply entangled knot of IF statements. It could take us years to do, and we’ll have to maintain two systems whilst we do it, inevitably adding new features to them both. Yes we get to reimplement using the latest, coolest programming language, instead of an old behemoth, but how long will our new cool language be around, and who will maintain that code, when it itself inevitably turns to legacy?
We can throw our arms in the air, complaining and grumbling about how we didn’t write the code, how we would never have written it the way it is, how those that wrote it were lesser programmers, possibly lesser humans themselves, but the code still remains, staring us in the face and hanging around for longer that we could possibly imagine. We can sort it out, we can improve it, we can make it testable, and we can learn to love our legacy code.
Refactoring for Rails - using deodorant to prevent code smells and a shower from time to time to eliminate the most persistent ones.
Slides used for my presentation at #rubyconfth 2022
code refactor strategy ruby on rails project
controller concerns
model concerns
polymorphic model
service-oriented design
meetup ruby geneva
gang of four in ruby
Clan code is extremely essential to build scalable application which can be maintained quite easily and improved further
Slide was prepared with contribution to my colleague
and i thank them for the help!
Bye Bye Cowboy-Coder days! by Vytautas Dagilis.
„Working Effectively with Legacy Code“- one of the best books which talks about Unit testing and TDD. Presentation covers best practices listed in the book as well as shows which of them were successfully implemented in practice. You will find out how to commit changes and be sure that they work even without running and testing application itself.
Improving the Quality of Existing SoftwareSteven Smith
Given at DogFoodCon 2016 in Columbus, Ohio
As developers, most of our time is spent working on existing software – even if it’s just the software we wrote ourselves, yesterday. And over time, software rots. If were not diligent, our beautiful code can degrade into a worthless mess. Keeping our code in working condition is no different than changing the oil in our car “ its preventive maintenance. In this session, Steve will cover some common places to look for signs of degradation in existing applications, and describe the steps we can take to improve our code. Examples will use C# and primarily ASP.NET.
Art of refactoring - Code Smells and Microservices AntipatternsEl Mahdi Benzekri
Refactoring is the process of improving the code without creating new functionality or changing an existing functionality.
Writing simple and avoiding complexity is the key to a good software design, changing the code become easier.
Code smells are undesired patterns that negatively affect software.
A survey about bad smells in Microservices architecture is presented with relevant examples and solutions.
Lesson 9 - Resisting Temptation Along the Way.pptxCelso Napoleon
Lesson 9 - Resisting Temptation Along the Way
SBs – Sunday Bible School
Adult Bible Lessons 2nd quarter 2024 CPAD
MAGAZINE: THE CAREER THAT IS PROPOSED TO US: The Path of Salvation, Holiness and Perseverance to Reach Heaven
Commentator: Pastor Osiel Gomes
Presentation: Missionary Celso Napoleon
Renewed in Grace
The PBHP DYC ~ Reflections on The Dhamma (English).pptxOH TEIK BIN
A PowerPoint Presentation based on the Dhamma Reflections for the PBHP DYC for the years 1993 – 2012. To motivate and inspire DYC members to keep on practicing the Dhamma and to do the meritorious deed of Dhammaduta work.
The texts are in English.
For the Video with audio narration, comments and texts in English, please check out the Link:
https://www.youtube.com/watch?v=zF2g_43NEa0
Exploring the Mindfulness Understanding Its Benefits.pptxMartaLoveguard
Slide 1: Title: Exploring the Mindfulness: Understanding Its Benefits
Slide 2: Introduction to Mindfulness
Mindfulness, defined as the conscious, non-judgmental observation of the present moment, has deep roots in Buddhist meditation practice but has gained significant popularity in the Western world in recent years. In today's society, filled with distractions and constant stimuli, mindfulness offers a valuable tool for regaining inner peace and reconnecting with our true selves. By cultivating mindfulness, we can develop a heightened awareness of our thoughts, feelings, and surroundings, leading to a greater sense of clarity and presence in our daily lives.
Slide 3: Benefits of Mindfulness for Mental Well-being
Practicing mindfulness can help reduce stress and anxiety levels, improving overall quality of life.
Mindfulness increases awareness of our emotions and teaches us to manage them better, leading to improved mood.
Regular mindfulness practice can improve our ability to concentrate and focus our attention on the present moment.
Slide 4: Benefits of Mindfulness for Physical Health
Research has shown that practicing mindfulness can contribute to lowering blood pressure, which is beneficial for heart health.
Regular meditation and mindfulness practice can strengthen the immune system, aiding the body in fighting infections.
Mindfulness may help reduce the risk of chronic diseases such as type 2 diabetes and obesity by reducing stress and improving overall lifestyle habits.
Slide 5: Impact of Mindfulness on Relationships
Mindfulness can help us better understand others and improve communication, leading to healthier relationships.
By focusing on the present moment and being fully attentive, mindfulness helps build stronger and more authentic connections with others.
Mindfulness teaches us how to be present for others in difficult times, leading to increased compassion and understanding.
Slide 6: Mindfulness Techniques and Practices
Focusing on the breath and mindful breathing can be a simple way to enter a state of mindfulness.
Body scan meditation involves focusing on different parts of the body, paying attention to any sensations and feelings.
Practicing mindful walking and eating involves consciously focusing on each step or bite, with full attention to sensory experiences.
Slide 7: Incorporating Mindfulness into Daily Life
You can practice mindfulness in everyday activities such as washing dishes or taking a walk in the park.
Adding mindfulness practice to daily routines can help increase awareness and presence.
Mindfulness helps us become more aware of our needs and better manage our time, leading to balance and harmony in life.
Slide 8: Summary: Embracing Mindfulness for Full Living
Mindfulness can bring numerous benefits for physical and mental health.
Regular mindfulness practice can help achieve a fuller and more satisfying life.
Mindfulness has the power to change our perspective and way of perceiving the world, leading to deeper se
The Chakra System in our body - A Portal to Interdimensional Consciousness.pptxBharat Technology
each chakra is studied in greater detail, several steps have been included to
strengthen your personal intention to open each chakra more fully. These are designed
to draw forth the highest benefit for your spiritual growth.
The Book of Joshua is the sixth book in the Hebrew Bible and the Old Testament, and is the first book of the Deuteronomistic history, the story of Israel from the conquest of Canaan to the Babylonian exile.
The Good News, newsletter for June 2024 is hereNoHo FUMC
Our monthly newsletter is available to read online. We hope you will join us each Sunday in person for our worship service. Make sure to subscribe and follow us on YouTube and social media.
HANUMAN STORIES: TIMELESS TEACHINGS FOR TODAY’S WORLDLearnyoga
Hanuman Stories: Timeless Teachings for Today’s World" delves into the inspiring tales of Hanuman, highlighting lessons of devotion, strength, and selfless service that resonate in modern life. These stories illustrate how Hanuman's unwavering faith and courage can guide us through challenges and foster resilience. Through these timeless narratives, readers can find profound wisdom to apply in their daily lives.
What Should be the Christian View of Anime?Joe Muraguri
We will learn what Anime is and see what a Christian should consider before watching anime movies? We will also learn a little bit of Shintoism religion and hentai (the craze of internet pornography today).
In Jude 17-23 Jude shifts from piling up examples of false teachers from the Old Testament to a series of practical exhortations that flow from apostolic instruction. He preserves for us what may well have been part of the apostolic catechism for the first generation of Christ-followers. In these instructions Jude exhorts the believer to deal with 3 different groups of people: scoffers who are "devoid of the Spirit", believers who have come under the influence of scoffers and believers who are so entrenched in false teaching that they need rescue and pose some real spiritual risk for the rescuer. In all of this Jude emphasizes Jesus' call to rescue straying sheep, leaving the 99 safely behind and pursuing the 1.
2. WHAT IS THIS TALK ABOUT?
Large apps are a completely different beast than small apps
• Domain complexity
• Tight code coupling across domain concepts
•…
This talk is about working with large apps.
… it’s about fixing code.
3. WHAT IS THIS TALK ABOUT?
…it’s about responsibility
fixing bad and improving
code.
4. WHAT IS GOOD CODE?
There is no one
?
right answer
8. WHAT WE WANT?
• Robustness
• Simplicity
• Softness
“Software must be soft: it has to be easy to change because
it will change despite our misguided efforts otherwise.”
The Pragmatic Programmers
9. WHAT WE FREQUENTLY SEE?
• Fragility
• Complexity
• Rigidity
As a result we have code that hard to
understand and modify.
10. WHAT IS REFACTORING???
“…process of changing a software system in such
a way that it does not after the external behavior of
the code yet implemented its internal structure.”
Martin Fowler
11. WHY REFACTOR??
• Improve code structure and design
• More maintainable
• Easier to understand
• Easier to modify
• Easier to add new feature
• Understand code better and sometimes it helps to
find bugs.
• Helps you develop better code, faster
To get better code!!!
12. WHEN REFACTOR
• You add new features and the code is hard to
understand
• You fix bug
• During code review
[!!!] Do not add new features during refactoring
… and sometimes you should throw things out
and start again.
13. WHAT DO WE NEED?
• If you want to refactor, the essential
precondition is having solid tests
• Knowledge of full context
14. THE REFACTORING CYCLE
• Chose the worst smell
• Select a refactoring
• Apply the refactoring
• Run all the tests
!!! Do it using a little steps…
15. TYPICAL CODE SMELLS
• Duplicated code
• Large classes
• Long methods
• Long parameters list
• Feature envy
• Improper naming
• Comments
• Magic numbers
• etc…
16. CLASSES
• Long classes
• Code that isn’t executed
• Too many responsibilities
• Different abstraction level
• Variables and function should be defined close
to where they are used
• Using deprecated methods
• Useless comments
17. METHODS
• Long methods
• Deeply nested method
• Different abstraction level
• Method doesn’t perform
• one identifiable task
• Long parameters list
• Many conditional statements
• Local variables should be declared just above
their first usage
18. VARIABLES
• Instance variables are an implementation
not an interface
• Bad variables name
• Magic numbers
• Several instances
19. COMMENTS
• Obsolete comments (Old comments that have lost their
meaning)
• Redundant comments
• Version History
• Commented out code
• Repeating the variable name or condition in the comment
• Repeating the called method name in a comment after the call
• Comments related to structure
20. TYPICAL REFACTORINGS
Class Method Variable
add (sub)class to add method to class add variable to class
hierarchy
rename class rename method rename variable
remove class remove method remove variable
push method down/push push variable down
method up pull variable up
add parameter to create assessors
method
move method to abstract variable
component
extract code in new
method
RearchitectingAs you increase your knowledge of the code, making it more comprehensible and better factored, you'll inevitably find some bits you don't like. When you started this project, you weren't really capable of changing much, but now you've played with the code, and it's not as damaged as it once was. Along the way, you have seen some bad things and had some ideas on how to fix them. It's time to make some serious changes. Rewrite code you don't understandIf you know what the code should do, and it seems to do it, but you can't figure out quite how, it's bad code. If the original author did something tricky, some comments should have been provided. More likely though, the author was clueless and the code really is a disaster. Rewrite it. By rewriting the code, you have the opportunity to do it the easy way, and to include useful comments. Start by writing down in Javadoc comments what the new code does (just to make sure that you know). Then you can take advantage of the byproducts of your refactoring: call this new method that does that, use that new data structure to store this. The new code will make more sense to everybody and will probably run faster as well. Your unit tests will tell you whether your new code works. Go into your bug tracking system and close all the bugs you have fixed. Move to a layered architectureLet's hope that your inherited, formerly bad code now looks better. It's time to look at the bigger picture: how the packages relate to each other. Using some sort of tool that tells you what classes invoke what methods (that information can be extracted from the class files), find out the interclass dependencies. From those dependencies, infer the interpackage dependencies. If you can't draw a hierarchy (without any loops!) of what packages depend on what other packages, you have some architectural work to do. Using your instincts, a code browser, and a great deal of guesswork, figure out what such an architecture might look like one fine day. Then identify the particular problem spots. A particular class that frequently refers to other packages or a particular constant referred to from other packages hints that classes or parts of classes reside in the wrong package. Ask yourself whether it would make sense to move that code to another package. After a lot of consideration, you can derive a package hierarchy that looks sensible. Although it may require a lot of work to achieve the clean architecture, it gives you a goal to work toward. Your unit tests have clarified what the code should do, and now the architecture allocates the responsibility to do it to packages and classes. All you have to do is fill in the code.
Break up big methodsJust as big classes prove difficult to understand, so do big methods, whose usual causes include:Too many options, causing the method to do too many thingsNot enough support from other methods, causing the method to do tasks at a lower level than it shouldOverly complicated exception handlingMy rule of thumb for methods: If I can't fit the entire thing on one screen, it's too long. It's an entirely practical rule with no theoretical basis, but it seems right and works for me. Remember though, when you read a method of 100 statements for the first time, it looks like 100 unrelated statements, and it is only after some study that you can see the internal structure. Life would be easier for you and for others if you made that internal structure explicit.
Fix the Javadoc commentsYou never realize a comment's importance until you need to read it. Even if nobody else reads it (and usually, they don't), Javadoc comments are important for the code authors to help them remember what the code/class/parameter should do. Pieces of information particularly important to include are: Whether an object parameter may be null, and what it means if it isWhether a parameter needs to be mutable or notWhether a return value is mutableWhether a return value may be nullWhether changes to the return value affect the returner's internal stateFixing the Javadoc comments doesn't mean just adding them where there were none before. You should also delete misleading and trivial comments (such as documenting setters and getters) as they engender a false sense of security. Important information exists for inclusion in Javadoc comments, so there's no point wasting the time of potential readers. When you write new methods and classes, try to include some Javadoc comments (just a few) to explain what they do. Even if it's obvious to you, the next person to get the code might thank you for the effort. If you don't know what to write in the Javadoc comments, you have no business writing the code. Javadoc comments can also serve as a record of what you learned about the code. When you figure out what a particularly tricky, clever, or ugly method does (especially a private or protected method with no implied contract), write a comment to record it for posterity. This expands the amount of the code under your control and helps you later when you're trying to decipher something related. Of course, Javadoc comments should only explain the effect of a method, never the implementation (because you might change that). If code within a method needs explanation, use standard code comments. A school of thought exists that says with good enough identifiers you don't need code comments at all. I'm not that extreme, but I take the point. Indeed, many code comments don't tell you anything new. I urge you to leave those uninformative comments out, as they only serve to make simple code verbose and intimidating.