This document discusses test-driven development (TDD) and refactoring in JavaScript. It begins with an introduction to TDD and refactoring, then defines common code smells like long methods, duplicated code, and bad names. It also discusses refactoring techniques like extracting methods and renaming variables. Test smells are covered as well, such as obscure tests, conditional test logic, and dependent tests. Overall, the document provides an overview of code smells and refactoring best practices to write cleaner, more maintainable JavaScript code.
Thinking of Documentation as Code [YUIConf 2013]evangoer
As a software engineer, one of the best things you can do for your documentation is to take the principles of code construction that you already know and apply them to your writing. We'll demonstrate how thinking about documentation as code will help you avoid many of the classic high level mistakes people make when launching documentation projects. This is a companion piece to last year's talk, which focused on how to optimize English prose at the micro level.
Jennifer Rondeau and Margaret Eker presentation from Write The Docs Prague, 2016:
Treating docs as code, an approach that more and more teams and companies are moving toward, involves more than putting the two together in a source repository. We discuss some of the details that often get lost in as dev and docs learn to work together in new ways. Because if all we do is put doc files next to code files in source control, or use parts of the same workflow for code and docs, we're still isolating docs as a separate sort of responsibility, free from the obligations of systematic review and testing without which code would never be accepted into production.
We want code that is easy to understand, re-usable, and flexible. But we are always up against deadlines, so we rush, and end up with code that is messy, buggy, hard to maintain, and makes us go slower even though we’re trying to go faster.
What is clean code? In this talk I’ll provide some answers to this question, and introduce you to 10 good habits that will help keep your code clean, such as the use of meaningful names for your variables and functions, and following the “Boy Scout Rule” (leave the code cleaner than you found it). I will even try to persuade you that using a lot of code comments is a sign that there are problems with your code.
The Basic Over of Swift as a new programming language.
This presentation is general look at Swift, please disregard the fact and references to the Swift scripting language which at the time thought to similar or same.
In this whitepaper, LearnItFirst founder Scott Whigham talks about how you can become a good (or better) C# programmer. This whitepaper is long - 15 pages - but it includes both a step-by-step system to follow as well as an in-depth discussion of each step.
If you follow this 13-step system (with a bonus 14th step), you can’t help but become a good C# developer!
Thinking of Documentation as Code [YUIConf 2013]evangoer
As a software engineer, one of the best things you can do for your documentation is to take the principles of code construction that you already know and apply them to your writing. We'll demonstrate how thinking about documentation as code will help you avoid many of the classic high level mistakes people make when launching documentation projects. This is a companion piece to last year's talk, which focused on how to optimize English prose at the micro level.
Jennifer Rondeau and Margaret Eker presentation from Write The Docs Prague, 2016:
Treating docs as code, an approach that more and more teams and companies are moving toward, involves more than putting the two together in a source repository. We discuss some of the details that often get lost in as dev and docs learn to work together in new ways. Because if all we do is put doc files next to code files in source control, or use parts of the same workflow for code and docs, we're still isolating docs as a separate sort of responsibility, free from the obligations of systematic review and testing without which code would never be accepted into production.
We want code that is easy to understand, re-usable, and flexible. But we are always up against deadlines, so we rush, and end up with code that is messy, buggy, hard to maintain, and makes us go slower even though we’re trying to go faster.
What is clean code? In this talk I’ll provide some answers to this question, and introduce you to 10 good habits that will help keep your code clean, such as the use of meaningful names for your variables and functions, and following the “Boy Scout Rule” (leave the code cleaner than you found it). I will even try to persuade you that using a lot of code comments is a sign that there are problems with your code.
The Basic Over of Swift as a new programming language.
This presentation is general look at Swift, please disregard the fact and references to the Swift scripting language which at the time thought to similar or same.
In this whitepaper, LearnItFirst founder Scott Whigham talks about how you can become a good (or better) C# programmer. This whitepaper is long - 15 pages - but it includes both a step-by-step system to follow as well as an in-depth discussion of each step.
If you follow this 13-step system (with a bonus 14th step), you can’t help but become a good C# developer!
Code we've written once has to be kept readable, maintainable, understandable and extensible for many years. Good code is not self-serving but the foundation for working together.
Refactoring can help you to keep the quality of the relevant parts of our systems high.
The technique is really easy (almost too easy) - improve the naming, structure, and responsibility in small steps that don't change behavior and run your tests after each step.
18 years ago I got hooked on Refactoring when Martin Fowler's first book came out. I've been using it since then on a daily basis on many different projects. Since then a lot has changed, especially with the help of modern IDEs with their automated refactorings and intentions.
Now he asked me to help review the 2nd edition. Our discussions reminded me that each generation of developers should be taught this crucial skill. That's why I want to give an overview of core refactorings and code-smells but also demonstrate the tips and tricks of today's tools that make this task so much easier.
Plus a sneak preview of the upcoming book.
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!
A quick overview of the most important latest things about refactoring, lots of it based on Martin Fowler's excellent: http://martinfowler.com/articles/workflowsOfRefactoring
A short introduction to the more advanced python and programming in general. Intended for users that has already learned the basic coding skills but want to have a rapid tour of more in-depth capacities offered by Python and some general programming background.
Execrices are available at: https://github.com/chiffa/Intermediate_Python_programming
Writing code that works and writing code that other people can read and understand are two different skills. And writing code that other people can read and understand became more and more essential skills as the project grows larger, and more people start working on it.
But because it is a skill, you need to train it consciously. It's a lot like writing essays and books. Everybody can write letters and words; many can also connect them in grammatically correct sentences. But not everybody is a J. R. R. R. Tolkien and have their books read by everyone.
An essential part of learning this skill is reading and analyzing other people's code on the one hand. And making other people read your code and give you feedback about it.
The speaker will talk about different methods of how to make programmers better writers and how to work out the skill of writing code that other people will want to read.
Code smells and Other Malodorous Software OdorsClint Edmonson
A code smell, also known as bad smell in computer programming code, refers to any symptom in the source code of a program that possibly indicates a deeper problem. Join us in this lively session where we will get a whiff of some aromas encountered in the field and how we can neutralize them.
Talk given at Plone Conference 2014 about code analysis and how to make your life better.
Discusses the current status of plone.recipe.codeanalysis and its future.
See recorded talk at: http://vimeo.com/110364146
Organizing Your PHP Projects (2010 ConFoo)Paul Jones
By using a few simple organizational principles, developers can make their project structure predictable, extensible, and modular. These techniques make it easy to de-conflict and share code between multiple projects. They also make it easy to automate project-support tasks such as testing, documentation, and distribution. This talk will discuss these principles, how they can be discovered from researching publicly available PHP projects, and how they are used (or not used) in popular applications and frameworks.
It has been said that one should code as if the person maintaining the code is a violent psychopath who knows where you live. But why do we work with psychopaths? That question unfortunately cannot be answered in this presentation. However, we can shed some light on how to code for readability hopefully avoiding the problem altogether.
Readable code is about a lot more than producing beautiful code. In fact, it has nothing really to do with the beauty of the code and everything to do with the ability to quickly understand what the code does.
In this presentation we will discuss why readable code is so important. We will cover six commonly reoccurring patterns that made code hard to read, why they occur, and how they can easily be avoided:
* Deep Nesting
* Unnecessary Generalization
* Ambiguous Naming
* Hard to Follow Flow of Execution
* Code Style vs. Individualism
* Code Comments
These concepts may be applied to any programming language.
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.
How I Learned to Stop Worrying and Love Legacy Code - Ox:Agile 2018Mike Harris
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.
https://www.youtube.com/watch?v=qRP45l5UugE
JavaScript The Language Meetup - Async functionswolframkriesing
"JavaScript The Language" #jslang is a hands-on meetup just about the language JavaScript (as specified). Not about any library, framework or the latest programming techniques.
This time we focused on async functions (also known as async+await).
Code we've written once has to be kept readable, maintainable, understandable and extensible for many years. Good code is not self-serving but the foundation for working together.
Refactoring can help you to keep the quality of the relevant parts of our systems high.
The technique is really easy (almost too easy) - improve the naming, structure, and responsibility in small steps that don't change behavior and run your tests after each step.
18 years ago I got hooked on Refactoring when Martin Fowler's first book came out. I've been using it since then on a daily basis on many different projects. Since then a lot has changed, especially with the help of modern IDEs with their automated refactorings and intentions.
Now he asked me to help review the 2nd edition. Our discussions reminded me that each generation of developers should be taught this crucial skill. That's why I want to give an overview of core refactorings and code-smells but also demonstrate the tips and tricks of today's tools that make this task so much easier.
Plus a sneak preview of the upcoming book.
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!
A quick overview of the most important latest things about refactoring, lots of it based on Martin Fowler's excellent: http://martinfowler.com/articles/workflowsOfRefactoring
A short introduction to the more advanced python and programming in general. Intended for users that has already learned the basic coding skills but want to have a rapid tour of more in-depth capacities offered by Python and some general programming background.
Execrices are available at: https://github.com/chiffa/Intermediate_Python_programming
Writing code that works and writing code that other people can read and understand are two different skills. And writing code that other people can read and understand became more and more essential skills as the project grows larger, and more people start working on it.
But because it is a skill, you need to train it consciously. It's a lot like writing essays and books. Everybody can write letters and words; many can also connect them in grammatically correct sentences. But not everybody is a J. R. R. R. Tolkien and have their books read by everyone.
An essential part of learning this skill is reading and analyzing other people's code on the one hand. And making other people read your code and give you feedback about it.
The speaker will talk about different methods of how to make programmers better writers and how to work out the skill of writing code that other people will want to read.
Code smells and Other Malodorous Software OdorsClint Edmonson
A code smell, also known as bad smell in computer programming code, refers to any symptom in the source code of a program that possibly indicates a deeper problem. Join us in this lively session where we will get a whiff of some aromas encountered in the field and how we can neutralize them.
Talk given at Plone Conference 2014 about code analysis and how to make your life better.
Discusses the current status of plone.recipe.codeanalysis and its future.
See recorded talk at: http://vimeo.com/110364146
Organizing Your PHP Projects (2010 ConFoo)Paul Jones
By using a few simple organizational principles, developers can make their project structure predictable, extensible, and modular. These techniques make it easy to de-conflict and share code between multiple projects. They also make it easy to automate project-support tasks such as testing, documentation, and distribution. This talk will discuss these principles, how they can be discovered from researching publicly available PHP projects, and how they are used (or not used) in popular applications and frameworks.
It has been said that one should code as if the person maintaining the code is a violent psychopath who knows where you live. But why do we work with psychopaths? That question unfortunately cannot be answered in this presentation. However, we can shed some light on how to code for readability hopefully avoiding the problem altogether.
Readable code is about a lot more than producing beautiful code. In fact, it has nothing really to do with the beauty of the code and everything to do with the ability to quickly understand what the code does.
In this presentation we will discuss why readable code is so important. We will cover six commonly reoccurring patterns that made code hard to read, why they occur, and how they can easily be avoided:
* Deep Nesting
* Unnecessary Generalization
* Ambiguous Naming
* Hard to Follow Flow of Execution
* Code Style vs. Individualism
* Code Comments
These concepts may be applied to any programming language.
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.
How I Learned to Stop Worrying and Love Legacy Code - Ox:Agile 2018Mike Harris
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.
https://www.youtube.com/watch?v=qRP45l5UugE
Similar to Day2 - Refactoring (Lecture SS 2015) (20)
JavaScript The Language Meetup - Async functionswolframkriesing
"JavaScript The Language" #jslang is a hands-on meetup just about the language JavaScript (as specified). Not about any library, framework or the latest programming techniques.
This time we focused on async functions (also known as async+await).
TDD for Kids - VLCjs (Valencia Spain, July 2015)wolframkriesing
In order to get hooked by TDD it sometimes seems too much effort to setup things, but that should not be the barrier. Along came Google Spreadsheets and I had a no-setup environment, at least for doing katas and showing of the magic of being rewarded with a red box switching to green once I implemented the right thing. I will tell you the story of how I tried to make TDD as simple as possible and how I ended up with Google Spreadsheets and also how this inspired me to build tddbin.com for use at our JSCodeRetreats. I believe it's the red-green cycle that got them hooked. I did it with students and also kids even a manager asked me "why does not everyone program like that?".
Presented at this event: http://www.meetup.com/de/ValenciaJS/events/223760927/
ES6Katas.org - an introduction and the story behindwolframkriesing
We at uxebu created ES6Katas.org. Our TDD background made it feel natural to explore the new language features using katas. So we developed some katas, so others can do too. I will show you why TDDBin was an essential part of it and how you can have fun with it and learn while doing so.
In order to get hooked by TDD it sometimes seems too much effort to setup things, but that should not be the barrier. Along came Google Spreadsheets and I had a no-setup environment, at least for doing katas and showing of the magic of being rewarded with a red box switching to green once I implemented the right thing. I will tell you the story of how I tried to make TDD as simple as possible and how I ended up with Google Spreadsheets and also how this inspired me to build tddbin.com for use at our JSCodeRetreats. I believe it’s the red-green cycle that got them hooked. I did it with students and also kids even a manager asked me “why does not everyone program like that?”.
One of the hardest thing I re-learned way too late again was thinking in small steps. Baby steps. They are a very helpful concept for developing with working in code esp. when refactoring or TDDing. Why do baby steps make sense? And how can you get into the mind set?
A coding dojo style talk - where the audience drives me, tells me what to do. Each person gets three minutes to drive me towards the result. On the way we discover, discuss and try to figure out some details about how to best approach a solution. We do some refactoring and in the end a quick retrospective of what we have applied, where we could improve and what take away might be worth to apply in the day job when back in real life.
In order to get hooked by TDD it sometimes seems too much effort to setup things, but that should not be the barrier. Along came Google Spreadsheets and I had a no-setup environment, at least for doing katas and showing of the magic of being rewarded with a red box switching to green once I implemented the right thing. I will tell you the story of how I tried to make TDD as simple as possible and how I ended up with Google Spreadsheets and also how this inspired me to build tddbin.com for use at our JSCodeRetreats. I believe it’s the red-green cycle that got them hooked. I did it with students and also kids even a manager asked me “why does not everyone program like that?”.
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
8. Design is hard.
The design of
reusable software
is especially hard.
Reusable software usually is the
result of many design iterations.
William F. Opdyke, 1992
it’sallaboutdesign
9. Books, papers
• „REFACTORING OBJECT-ORIENTED FRAMEWORKS“
William F. Opdyke, 1992
http://www.ai.univ-paris8.fr/~lysop/opdyke-thesis.pdf
• „Refactoring: Improving the Design of Existing Code“
Martin Fowler, 1999
• „Working Effectively with Legacy Code“
Michael Feathers, 2004
• „31 Days of Refactoring“
http://lostechies.com/wp-content/uploads/2011/03/31DaysRefactoring.pdf
• „Subjective evaluation of software evolvability using code smells: An
empirical study“
http://www.soberit.hut.fi/~mmantyla/ESE_2006.pdf
48. Conditionals
Combinatorial Explosion
Type embedding
Data Clumps
sets of variables that are always together, get passed in, etc. => extract into class
avoid placing types in method names; it's not only redundant, but it forces you to
change the name if the type changes
You have lots of code that does almost the same thing
watch out for large conditional logic blocks
particularly blocks that tend to grow larger or change significantly over time
49. Feature envy
a method making more use of another class than the one it is in
Speculative Generality
write code to solve today's problems
and worry about tomorrow's problems when they actually materialize
52. Obscure test
it is difficult to understand the test at a glance
Conditional test logic
• tests take too long to run
• make developers not run the tests
• leads to untested code
• demotivates continuous testing
• make code rot
55. General fixture
a setUp method contains code only used by some tests
Lazy test
using the same fixture for multiple tests
Test run war
test can only be run by one person at a time, due to use of same external ressource
