White paper recommends 11 best practices for efficient peer code review:
1. Review no more than 200-400 lines of code at a time and take 60-90 minutes or less per review for optimal effectiveness.
2. Aim for an inspection rate of less than 300-500 LOC per hour and spend at least 5 minutes on each review.
3. Have authors annotate source code before review to eliminate most defects beforehand and improve efficiency.
4. Establish quantifiable goals, collect metrics, and refine processes over time to continuously improve results.
Behavior Driven Development with AngularJS & JasmineRemus Langu
This document discusses Behavior-Driven Development (BDD) and how it can improve software development. BDD is a methodology that uses examples in natural language to define desired software behaviors and tests those examples throughout development. It aims to bridge communication gaps between developers, testers, and business stakeholders. The document outlines BDD processes and how they differ from traditional waterfall and test-driven development. It also provides an example template for writing BDD scenarios in Gherkin, a domain-specific language.
It was back in ‘97 when Brian Foote and I first opined that: while much attention had been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture had seldom been discussed: the Big Ball of Mud. A Big Ball of Mud is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems. Somewhat to our astonishment, since our original statement, no one has ever undertaken to dispute this premise. Still, this approach endures and thrives. Why is this architecture so popular? Is it as bad as it seems, or might it serve as a way-station on the road to more enduring, elegant artifacts? What forces drive good programmers to build ugly systems? Can we avoid this? Should we? How can we make such systems better?
This keynote will examine the paradoxes that underlie Big Balls of Mud, what causes them, and why they are so prominent. What Agile Practices help us avoid or cope with mud? Does Agile practices such as TDD really help minimize mud? What are we doing RIGHT? What Agile Practices contribute to the problem? Encourage mud? Is Mud really the best that Agile can do? Is Agility’s utilitarian focus on process rather than design its secret weapon, or its Achilles heel?
Do you already know what big ball of mud means?
And code smell?, Is your nose prepared to detect them?
Can you affirm that you are commited with the mantainability?
Do you have architectural sensibility to avoid these kind of situations? Or you are comfortable with the inertia of the day-to-day task of patching the holes. (it doesn't matter if it works..)
While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed.
This talk is intended to identify and summarize the causes that lead to misusing our time on complex maintenance, and give tips and best practices to avoid the big ball of mud and to achieve the best quality products.
Taming Big Balls of Mud with Diligence, Agile Practices, and Hard WorkJoseph Yoder
Big Ball of Mud (BBoM) architectures are viewed as the culmination of many design decisions that, over time, result in a system that is hodgepodge of steaming and smelly anti-patterns. It can be arguably claimed that one of the reasons for the growth and popularity of agile practices is partially due to the fact that the state of the art of software architectures was not that good. Being agile, with its focus on extensive testing and frequent integration, has shown that it can make it easier to deal with evolving architectures (possibly muddy) and keeping systems working while making significant improvements and adding functionality. Time has also shown that Agile practices are not sufficient to prevent or eliminate Mud. It is important to recognize what is core to the architecture and the problem at hand when evolving an architecture.
This talk will examine the paradoxes that underlie Big Balls of Mud, what causes them, and why they are so prominent. I’ll explore what agile practices can help us avoid or cope with mud. I’ll also explain why continuous delivery and TDD with refactoring is not enough to help ensure clean architecture and why it is important to understand what is core to the architecture and the problem at hand. Understanding what changes in the system and at what rates can help you prevent becoming mired in mud. By first understanding where a system’s complexities are and where it keeps getting worse, we can then work hard (and more intelligently) at sustaining the architecture. This can become a key value to the agile team. The results will leave attendees with practices and patterns that help clean your code (refactor) as well as keeping the code clean or from getting muddier.
Additionally, I’ll talk about some practices and patterns that help keep the code clean or from getting muddier. Some of these include: Testing, Divide & Conquer, Gentrification, Demolition, Quarantine, Refactoring, Craftmanship and the like.. The original Big Ball of Mud paper described some best practices such as SHEARING LAYERS and SWEEPING IT UNDER THE RUG as a way to help deal with muddy architectures. Additionally there are some other practices such as PAVING OVER THE WAGON TRAIL and WIPING YOUR FEET AT THE DOOR that can make code more habitable.
Professional Code of Ethics in Software EngineeringLemi Orhan Ergin
The document discusses the differences between craftsmanship and engineering in software development. It argues that software engineering is an idea whose time has come and gone, and that software development is more experimental in nature. The focus should be on software conception rather than strict engineering approaches, as control is ultimately illusory in software projects.
xUnit and TDD: Why and How in Enterprise Software, August 2012Justin Gordon
“A comprehensive suite of JUnit tests is one of the most import aspects of a software project because it reduces bugs, facilitates adding new developers, and enables refactoring and performance tuning with confidence. Test-driven development (TDD) is the best way to build a suite of tests. And the Dependent Object Framework is the best way to test against database objects.” This presentation covers the benefits of TDD along with practical advice on how to implement TDD in complex projects.
White paper recommends 11 best practices for efficient peer code review:
1. Review no more than 200-400 lines of code at a time and take 60-90 minutes or less per review for optimal effectiveness.
2. Aim for an inspection rate of less than 300-500 LOC per hour and spend at least 5 minutes on each review.
3. Have authors annotate source code before review to eliminate most defects beforehand and improve efficiency.
4. Establish quantifiable goals, collect metrics, and refine processes over time to continuously improve results.
Behavior Driven Development with AngularJS & JasmineRemus Langu
This document discusses Behavior-Driven Development (BDD) and how it can improve software development. BDD is a methodology that uses examples in natural language to define desired software behaviors and tests those examples throughout development. It aims to bridge communication gaps between developers, testers, and business stakeholders. The document outlines BDD processes and how they differ from traditional waterfall and test-driven development. It also provides an example template for writing BDD scenarios in Gherkin, a domain-specific language.
It was back in ‘97 when Brian Foote and I first opined that: while much attention had been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture had seldom been discussed: the Big Ball of Mud. A Big Ball of Mud is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems. Somewhat to our astonishment, since our original statement, no one has ever undertaken to dispute this premise. Still, this approach endures and thrives. Why is this architecture so popular? Is it as bad as it seems, or might it serve as a way-station on the road to more enduring, elegant artifacts? What forces drive good programmers to build ugly systems? Can we avoid this? Should we? How can we make such systems better?
This keynote will examine the paradoxes that underlie Big Balls of Mud, what causes them, and why they are so prominent. What Agile Practices help us avoid or cope with mud? Does Agile practices such as TDD really help minimize mud? What are we doing RIGHT? What Agile Practices contribute to the problem? Encourage mud? Is Mud really the best that Agile can do? Is Agility’s utilitarian focus on process rather than design its secret weapon, or its Achilles heel?
Do you already know what big ball of mud means?
And code smell?, Is your nose prepared to detect them?
Can you affirm that you are commited with the mantainability?
Do you have architectural sensibility to avoid these kind of situations? Or you are comfortable with the inertia of the day-to-day task of patching the holes. (it doesn't matter if it works..)
While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed.
This talk is intended to identify and summarize the causes that lead to misusing our time on complex maintenance, and give tips and best practices to avoid the big ball of mud and to achieve the best quality products.
Taming Big Balls of Mud with Diligence, Agile Practices, and Hard WorkJoseph Yoder
Big Ball of Mud (BBoM) architectures are viewed as the culmination of many design decisions that, over time, result in a system that is hodgepodge of steaming and smelly anti-patterns. It can be arguably claimed that one of the reasons for the growth and popularity of agile practices is partially due to the fact that the state of the art of software architectures was not that good. Being agile, with its focus on extensive testing and frequent integration, has shown that it can make it easier to deal with evolving architectures (possibly muddy) and keeping systems working while making significant improvements and adding functionality. Time has also shown that Agile practices are not sufficient to prevent or eliminate Mud. It is important to recognize what is core to the architecture and the problem at hand when evolving an architecture.
This talk will examine the paradoxes that underlie Big Balls of Mud, what causes them, and why they are so prominent. I’ll explore what agile practices can help us avoid or cope with mud. I’ll also explain why continuous delivery and TDD with refactoring is not enough to help ensure clean architecture and why it is important to understand what is core to the architecture and the problem at hand. Understanding what changes in the system and at what rates can help you prevent becoming mired in mud. By first understanding where a system’s complexities are and where it keeps getting worse, we can then work hard (and more intelligently) at sustaining the architecture. This can become a key value to the agile team. The results will leave attendees with practices and patterns that help clean your code (refactor) as well as keeping the code clean or from getting muddier.
Additionally, I’ll talk about some practices and patterns that help keep the code clean or from getting muddier. Some of these include: Testing, Divide & Conquer, Gentrification, Demolition, Quarantine, Refactoring, Craftmanship and the like.. The original Big Ball of Mud paper described some best practices such as SHEARING LAYERS and SWEEPING IT UNDER THE RUG as a way to help deal with muddy architectures. Additionally there are some other practices such as PAVING OVER THE WAGON TRAIL and WIPING YOUR FEET AT THE DOOR that can make code more habitable.
Professional Code of Ethics in Software EngineeringLemi Orhan Ergin
The document discusses the differences between craftsmanship and engineering in software development. It argues that software engineering is an idea whose time has come and gone, and that software development is more experimental in nature. The focus should be on software conception rather than strict engineering approaches, as control is ultimately illusory in software projects.
xUnit and TDD: Why and How in Enterprise Software, August 2012Justin Gordon
“A comprehensive suite of JUnit tests is one of the most import aspects of a software project because it reduces bugs, facilitates adding new developers, and enables refactoring and performance tuning with confidence. Test-driven development (TDD) is the best way to build a suite of tests. And the Dependent Object Framework is the best way to test against database objects.” This presentation covers the benefits of TDD along with practical advice on how to implement TDD in complex projects.
This document discusses 10 common myths about software testing in an agile environment. It argues that while test-driven development (TDD) is useful, a variety of testing techniques are still needed including manual testing, integration testing, system testing, and user acceptance testing. It also notes that as project size increases, test automation becomes necessary to efficiently run all the necessary test cycles. Overall, the document advocates for testers to be actively involved throughout the agile process to help ensure software quality.
This document discusses test-driven development (TDD) and its importance for software development. It notes that TDD is not just about unit testing code, but is a key part of software craftsmanship. When practicing TDD, tests should be written from the perspective of understanding by business analysts and customers, not just for code implementation. TDD promotes a short feedback loop to continually refine code through testing. Examples provided demonstrate how to use TDD for a FizzBuzz coding exercise by first writing tests to define requirements and then coding to pass those tests.
Slides for Houston iPhone Developers' Meetup (April 2012)lqi
The document discusses the importance of code quality and provides tips for improving code quality. It defines code quality as how well software is designed and implemented. It recommends code reviews, static analysis tools like Clang, AppCode, and OCLint to identify code smells and defects. It also discusses refactoring code to improve simplicity, clarity and reduce technical debt. Maintaining high code quality makes software easier to change and evolve over time.
Test driven development vs Behavior driven developmentGallop Solutions
Test driven development (TDD) is an evolutionary approach to development that relies on the repetition of short development cycle. Behavior driven development (BDD) is an amalgamation of practices stemming from test driven development.
This document provides an overview of test-driven development (TDD), including why it is important, perspectives on TDD, how to implement TDD, and recommended TDD tools. TDD involves writing tests before code to ensure requirements are met and drive the development process through repeated short cycles. Tests should be small, focused, repeatable, and independent to avoid side effects and keep code clean and working. Implementing TDD helps focus on required behaviors, improves quality, provides documentation, and allows for more confident changes and early defect identification.
Agile * Agile Principles * Agile Practices * Pair Programming * Extreme Programming * SOLID design principles * SDLC * Software Development
After working 10 years in multiple major "from-scratch" development projects, I finally got a chance to work in a truly Agile development project. Here is my take on how to make Agile work for your project.
The document discusses test-driven development (TDD) and provides guidance on how to implement TDD. It outlines the progression from manual testing to automated testing to test-first development. The benefits of TDD include less manual testing, faster feedback, safer code changes, and improved design. Good tests express intent, isolate areas under test, and provide clear failures. When starting TDD, automate tests for important features and bug-prone areas first, and use TDD for new features.
A quick paced introduction to "Test Driven Development" (TDD) in an agile environment. The TDD philosophy states that you should develop your tests and then write code to make your tests pass and satisfy user requirements.
Test drive on driven development process.
What we covered:
* Test Driven Development
* Behavior Driven Development
* Feature Driven Development
* Acceptance Test Driven Development
What are we not covered:
* Model Driven Development
* Domain Driven Development
Introduction to Test Driven DevelopmentMurphy Meng
TDD involves writing tests before code to ensure requirements are met and all tests pass. The TDD process is to first write a failing test, then code to pass that test, and refactor the code. TDD results in safe code modifications, obvious mistakes, self-documenting code through tests, solid design before coding, and decoupled code through short development cycles. Potential concerns are fully understanding requirements beforehand and whether TDD works for exploratory development.
BDD is a methodology where developers and stakeholders collaborate to build a clear understanding of desired behaviors through discussion. It defines behaviors using acceptance criteria in a Given/When/Then format and natural language test cases. Popular BDD tools include Cucumber, Lettuce
Agile and Agile methods: what is the most important to understand to succeedVaidas Adomauskas
This document discusses Agile methods and how to succeed using them. It begins with an overview of traditional "waterfall" software development practices versus Agile practices. It then defines some common Agile terms and methods like Scrum, Test-Driven Development, eXtreme Programming, and Kanban. The document emphasizes that the most important things for success are respecting people, using the right tools for the job, measuring the right metrics, getting external help when needed, having courage, and starting to use Agile practices now rather than later.
This presentation describes Agile development practices as well as the requirements for building secure applications. It examines ways that teams can incorporate security into Agile development projects to successfully meet the goals of both.
Test Driven Development (TDD) is a software testing methodology where developers write automated test cases before writing any code. It involves writing a failing test case for new functionality, then writing the minimum amount of code to pass that test, and refactoring the code. Key steps are to add a test, run all tests and see the new one fail, write code to pass the test, run tests to succeed, and refactor code while maintaining tests. Benefits include instant feedback, better code quality, and lower rework effort. Limitations include difficulty testing certain types of code like GUIs. Unit testing tests individual units of code in isolation through mocking of external dependencies.
One reasonable definition of good design is testability. It is hard to imagine a software system that is both testable and poorly designed. It is also hard to imagine a software system that is well designed but also untestable.
I'll talk you through how bad design may affect testability. We will learn how to design robust tests which are not just increasing code coverage but are bringing real value to your project.
Finally we will explore the best way to integrate these tests to your continuous integration environment so they will be acting as top class guards against sloppy commits.
Keywords : design principles, unit tests, integration tests, stress tests, java, spring, junit @Rule, junit @Category, @RunWith, @Parameters, surefire, maven, jenkins, quality metrics, selenium , tdd, mocks, stubs, etc...
Test Driven Development (TDD) is a software development technique where unit tests are written before functional code to verify functionality. The TDD process follows a "Red, Green, Refactor" cycle where tests fail initially ("Red"), code is written to pass tests ("Green"), and code is refactored to improve design. While TDD may improve code quality and catch errors earlier, studies have shown mixed results on productivity and quality improvements. Adopting TDD fully can be challenging in practice due to issues like incomplete test coverage and resistance to change.
The document discusses Test Driven Development (TDD). TDD is a software development process where test cases are written before implementation code to specify requirements, with code only written to pass newly created tests. The TDD cycle involves writing a test, running the test which fails with no code, writing minimum code to pass the test, running all tests which should now pass, and refactoring code before repeating. Examples like calculating prime number sums and FizzBuzz are provided. Benefits of TDD include improved code quality, reduced bugs, and faster development through continuous testing and feedback. Best practices include pair programming, test planning, and using testing frameworks.
Test-drevet utvikling er en hellig gral innen smidig utvikling og ofte hører man uttrykk som "TDD fører til bra design", "med TDD trenger man ikke tenke på arkitektur" og "TDD er meningen med livet" (okei, det siste der fant jeg muligens på selv). Men vil TDD automatisk føre til bra design? Eller er det noe de ikke har fortalt deg?
The document provides recipes for building CQRS architectures. It begins with an introduction and agenda. Lesson 1 discusses a basic layered architecture, noting its limitations in scalability and evolvability. Lesson 2 introduces n-layered architecture with dependency injection to improve decoupling but it also has scalability issues. Lesson 3 explains the Command Query Responsibility Segregation (CQRS) pattern, separating read and write operations for improved scalability and flexibility. It provides code examples of implementing CQRS. The document aims to help architects evolve monolithic systems to more scalable and maintainable architectures.
Talk given in DevFest Asturias 2019 (GDG Google Developer Group Asturias)
16.11.2019 Gijón (Spain)
The Legacy Code came to stay
(spanish)
El legacy vino para quedarse
RESUMEN
Es una charla que pone en relieve que los servicios que damos los agilistas, no están orientados a sustituir el trabajo de otros, sino que entre todos conseguimos mejorar nuestros productos y nuestra vida diaria en el trabajo.
ABSTRACT
Casi todos sabemos lo que es el Legacy Code, ese proyecto al que todos nos hemos enfrentado alguna vez y que cuesta trabajar con él.
Lo que era algo a evitar o a sustituir, en los últimos años por diversas razones, se ha convertido en algo que debe seguir existiendo durante mucho tiempo, por lo que se busca la manera de seguir manteniendolo con confianza.
Esta necesidad parece técnica, y a lo sumo se entiende que involucra a los equipos que lo mantienen, pero realmente es una estrategia empresarial en la que se busca además de mantener la funcionalidad existente, avanzar el producto y cubrir la necesidad actual, con la ayuda de un equipo al que hay que mantener motivado, practicando además, eso tan difícil que hoy se conoce como La Retención del Talento.
Explicaremos en esta charla los diferentes tipos de retos enmarcados en Código Legado, tantos técnicos como con los equipos a los que nos hemos enfrentado en Codesai y qué estrategias usamos para afrontarlos.
This document discusses 10 common myths about software testing in an agile environment. It argues that while test-driven development (TDD) is useful, a variety of testing techniques are still needed including manual testing, integration testing, system testing, and user acceptance testing. It also notes that as project size increases, test automation becomes necessary to efficiently run all the necessary test cycles. Overall, the document advocates for testers to be actively involved throughout the agile process to help ensure software quality.
This document discusses test-driven development (TDD) and its importance for software development. It notes that TDD is not just about unit testing code, but is a key part of software craftsmanship. When practicing TDD, tests should be written from the perspective of understanding by business analysts and customers, not just for code implementation. TDD promotes a short feedback loop to continually refine code through testing. Examples provided demonstrate how to use TDD for a FizzBuzz coding exercise by first writing tests to define requirements and then coding to pass those tests.
Slides for Houston iPhone Developers' Meetup (April 2012)lqi
The document discusses the importance of code quality and provides tips for improving code quality. It defines code quality as how well software is designed and implemented. It recommends code reviews, static analysis tools like Clang, AppCode, and OCLint to identify code smells and defects. It also discusses refactoring code to improve simplicity, clarity and reduce technical debt. Maintaining high code quality makes software easier to change and evolve over time.
Test driven development vs Behavior driven developmentGallop Solutions
Test driven development (TDD) is an evolutionary approach to development that relies on the repetition of short development cycle. Behavior driven development (BDD) is an amalgamation of practices stemming from test driven development.
This document provides an overview of test-driven development (TDD), including why it is important, perspectives on TDD, how to implement TDD, and recommended TDD tools. TDD involves writing tests before code to ensure requirements are met and drive the development process through repeated short cycles. Tests should be small, focused, repeatable, and independent to avoid side effects and keep code clean and working. Implementing TDD helps focus on required behaviors, improves quality, provides documentation, and allows for more confident changes and early defect identification.
Agile * Agile Principles * Agile Practices * Pair Programming * Extreme Programming * SOLID design principles * SDLC * Software Development
After working 10 years in multiple major "from-scratch" development projects, I finally got a chance to work in a truly Agile development project. Here is my take on how to make Agile work for your project.
The document discusses test-driven development (TDD) and provides guidance on how to implement TDD. It outlines the progression from manual testing to automated testing to test-first development. The benefits of TDD include less manual testing, faster feedback, safer code changes, and improved design. Good tests express intent, isolate areas under test, and provide clear failures. When starting TDD, automate tests for important features and bug-prone areas first, and use TDD for new features.
A quick paced introduction to "Test Driven Development" (TDD) in an agile environment. The TDD philosophy states that you should develop your tests and then write code to make your tests pass and satisfy user requirements.
Test drive on driven development process.
What we covered:
* Test Driven Development
* Behavior Driven Development
* Feature Driven Development
* Acceptance Test Driven Development
What are we not covered:
* Model Driven Development
* Domain Driven Development
Introduction to Test Driven DevelopmentMurphy Meng
TDD involves writing tests before code to ensure requirements are met and all tests pass. The TDD process is to first write a failing test, then code to pass that test, and refactor the code. TDD results in safe code modifications, obvious mistakes, self-documenting code through tests, solid design before coding, and decoupled code through short development cycles. Potential concerns are fully understanding requirements beforehand and whether TDD works for exploratory development.
BDD is a methodology where developers and stakeholders collaborate to build a clear understanding of desired behaviors through discussion. It defines behaviors using acceptance criteria in a Given/When/Then format and natural language test cases. Popular BDD tools include Cucumber, Lettuce
Agile and Agile methods: what is the most important to understand to succeedVaidas Adomauskas
This document discusses Agile methods and how to succeed using them. It begins with an overview of traditional "waterfall" software development practices versus Agile practices. It then defines some common Agile terms and methods like Scrum, Test-Driven Development, eXtreme Programming, and Kanban. The document emphasizes that the most important things for success are respecting people, using the right tools for the job, measuring the right metrics, getting external help when needed, having courage, and starting to use Agile practices now rather than later.
This presentation describes Agile development practices as well as the requirements for building secure applications. It examines ways that teams can incorporate security into Agile development projects to successfully meet the goals of both.
Test Driven Development (TDD) is a software testing methodology where developers write automated test cases before writing any code. It involves writing a failing test case for new functionality, then writing the minimum amount of code to pass that test, and refactoring the code. Key steps are to add a test, run all tests and see the new one fail, write code to pass the test, run tests to succeed, and refactor code while maintaining tests. Benefits include instant feedback, better code quality, and lower rework effort. Limitations include difficulty testing certain types of code like GUIs. Unit testing tests individual units of code in isolation through mocking of external dependencies.
One reasonable definition of good design is testability. It is hard to imagine a software system that is both testable and poorly designed. It is also hard to imagine a software system that is well designed but also untestable.
I'll talk you through how bad design may affect testability. We will learn how to design robust tests which are not just increasing code coverage but are bringing real value to your project.
Finally we will explore the best way to integrate these tests to your continuous integration environment so they will be acting as top class guards against sloppy commits.
Keywords : design principles, unit tests, integration tests, stress tests, java, spring, junit @Rule, junit @Category, @RunWith, @Parameters, surefire, maven, jenkins, quality metrics, selenium , tdd, mocks, stubs, etc...
Test Driven Development (TDD) is a software development technique where unit tests are written before functional code to verify functionality. The TDD process follows a "Red, Green, Refactor" cycle where tests fail initially ("Red"), code is written to pass tests ("Green"), and code is refactored to improve design. While TDD may improve code quality and catch errors earlier, studies have shown mixed results on productivity and quality improvements. Adopting TDD fully can be challenging in practice due to issues like incomplete test coverage and resistance to change.
The document discusses Test Driven Development (TDD). TDD is a software development process where test cases are written before implementation code to specify requirements, with code only written to pass newly created tests. The TDD cycle involves writing a test, running the test which fails with no code, writing minimum code to pass the test, running all tests which should now pass, and refactoring code before repeating. Examples like calculating prime number sums and FizzBuzz are provided. Benefits of TDD include improved code quality, reduced bugs, and faster development through continuous testing and feedback. Best practices include pair programming, test planning, and using testing frameworks.
Test-drevet utvikling er en hellig gral innen smidig utvikling og ofte hører man uttrykk som "TDD fører til bra design", "med TDD trenger man ikke tenke på arkitektur" og "TDD er meningen med livet" (okei, det siste der fant jeg muligens på selv). Men vil TDD automatisk føre til bra design? Eller er det noe de ikke har fortalt deg?
The document provides recipes for building CQRS architectures. It begins with an introduction and agenda. Lesson 1 discusses a basic layered architecture, noting its limitations in scalability and evolvability. Lesson 2 introduces n-layered architecture with dependency injection to improve decoupling but it also has scalability issues. Lesson 3 explains the Command Query Responsibility Segregation (CQRS) pattern, separating read and write operations for improved scalability and flexibility. It provides code examples of implementing CQRS. The document aims to help architects evolve monolithic systems to more scalable and maintainable architectures.
Talk given in DevFest Asturias 2019 (GDG Google Developer Group Asturias)
16.11.2019 Gijón (Spain)
The Legacy Code came to stay
(spanish)
El legacy vino para quedarse
RESUMEN
Es una charla que pone en relieve que los servicios que damos los agilistas, no están orientados a sustituir el trabajo de otros, sino que entre todos conseguimos mejorar nuestros productos y nuestra vida diaria en el trabajo.
ABSTRACT
Casi todos sabemos lo que es el Legacy Code, ese proyecto al que todos nos hemos enfrentado alguna vez y que cuesta trabajar con él.
Lo que era algo a evitar o a sustituir, en los últimos años por diversas razones, se ha convertido en algo que debe seguir existiendo durante mucho tiempo, por lo que se busca la manera de seguir manteniendolo con confianza.
Esta necesidad parece técnica, y a lo sumo se entiende que involucra a los equipos que lo mantienen, pero realmente es una estrategia empresarial en la que se busca además de mantener la funcionalidad existente, avanzar el producto y cubrir la necesidad actual, con la ayuda de un equipo al que hay que mantener motivado, practicando además, eso tan difícil que hoy se conoce como La Retención del Talento.
Explicaremos en esta charla los diferentes tipos de retos enmarcados en Código Legado, tantos técnicos como con los equipos a los que nos hemos enfrentado en Codesai y qué estrategias usamos para afrontarlos.
This document discusses Test Driven Development (TDD). TDD helps create clean, simple code designs with low coupling between components. Writing tests first allows developing code with confidence as tests accumulate. It helps avoid technical debt by refactoring code as needed. TDD produces documentation in the form of executable tests and enables continuous integration and delivery. The TDD process follows the "Red-Green-Refactor" mantra of writing a failing test first, then code to pass the test, and refactoring code as needed. Tests should be written to be fast, independent, repeatable, self-validating, and timely. Tools and coding dojos can help practice and improve TDD skills.
This document summarizes the agenda and key topics from a 4-day course on data science for finance. Day 4 focuses on deploying machine learning models in production and providing a recap of the overall course. The presentation discusses challenges in moving models from prototypes to production, and introduces QuSandbox as a platform for adopting data science and AI in enterprises. QuSandbox provides tools for model management, experimentation and deployment through a user portal and APIs.
This document provides an overview of refactoring legacy code. It discusses the importance of refactoring to maintain and reduce complexity as a system evolves. Refactoring improves code design without changing behavior. Tests are important for refactoring to preserve existing behavior and allow changing code safely. The document outlines a recipe for refactoring legacy code, including identifying change points, adding test points, making code testable, writing tests, and then refactoring and changing code. It emphasizes that legacy code is often not initially testable, requiring changes to break dependencies before adding tests.
This document discusses JavaScript tools and continuous delivery. It begins with context around design thinking, lean startup, and agile principles. Continuous delivery is introduced as the technical response to needs of process, product, and market. Key aspects of continuous delivery include ensuring every change initiates feedback and receiving feedback as quickly as possible. When Node.js arrived, it changed everything by enabling server-side JavaScript. The document then discusses potential tools and frameworks for infrastructure/development, testing, applications, and utilities to organize the recent explosion of JavaScript technologies into a coherent toolkit. It provides examples for areas like bundling, dynamic loading, testing, and more.
This is take two of the presentation, some things added, some removed, but still the regurgitation is best..
The purpose is to raise your awareness of software architecture in light of modern day agile development. Disciplines to incorporate and reconsider
Technical Excellence Doesn't Just Happen - AgileIndy 2016Allison Pollard
This document summarizes a presentation about igniting a craftsmanship culture through technical excellence. It introduces the presenters and defines technical excellence as both delivering value today and building an adaptable product. It discusses how technical debt occurs and how continuous attention to quality enhances agility. Several practices are discussed that were tried to improve quality, such as test-driven development training, code clinics, and code reviews. It emphasizes that technical excellence requires ongoing learning and discipline to achieve long-term viability.
Cleaning Code - Tools and Techniques for Large Legacy ProjectsMike Long
This document discusses techniques for cleaning and restoring large legacy software projects. It begins by defining what constitutes a large legacy project and restoration project. It then discusses how codebases can become messy over time due to factors like explosive growth and lack of quality processes. The document outlines some of the tools and techniques that can be used for identifying and removing waste from large legacy code, including tools for visualizing code quality, detecting duplicate code, and identifying unused code. It stresses that legacy restoration requires managing culture change. The document concludes that prevention is better than cure, legacy software is still valuable, and there is always a business case for restoration if it can be properly quantified and proven.
Software quality is critical to consistently and continually delivering new features to our users. This talk covers the importance of software quality and how to deliver it via unit testing, Test Driven Development and clean code in general.
This is the deck from a talk I gave at Desert Code Camp 2013.
Being Test-Driven: It's not really about testingRaj Indugula
This document discusses test-driven development (TDD) and behavior-driven development (BDD). It describes how BDD uses conversations to discover requirements and build shared understanding. BDD captures conversations as executable specifications expressed in a common language. TDD follows the "Red-Green-Refactor" process of writing a failing test, adding code to pass the test, and refactoring code. TDD drives better design through incremental development guided by tests and prevents overdesign. While TDD can improve design, it also risks overly complex test code and dependencies if not kept simple. The document advocates starting with examples to guide development and testing in a test-driven manner.
This document provides an overview of key topics related to quality in software projects from a project manager's perspective. It discusses definitions of quality, different approaches to software development like agile and iterative development, design quality, code quality, security quality, and things project managers can do to focus on quality. Anti-patterns that should be avoided are also covered, such as tolerating long feedback cycles or isolating teams from end-users. The document aims to give project managers insights on how to produce good quality software.
Based on my observations, in IT we suffer from continuous collective amnesia and we are even proud of it.
For at least 50 years meanwhile, we struggle how to build systems, that are easy to understand, to maintain, to change and to operate in a reliable way. Each time we hit the wall again, we start to look for a new silver bullet on the horizon, strongly believing that it will solve the problem for good.
The key word is "new": "New" is good in our community, while "old" is bad, worthless, crap. We suffer from youthism, not only in recruiting, but in all areas. This way we discard any "old" knowledge, no matter if it is valuable or not. We separate by age, not by value.
Additionally we continuously lose our collective memory with every new generation that leaves university as they are also taught not to value anything old and instead only look for the new, shiny stuff.
While not all old knowledge is worth being preserved, admittedly, there is still a lot of valuable old knowledge available, offering answers to the problems that we face today - creating maintainable and reliable systems, dealing with distribution and tackling complexity, just to name a few of the challenges.
This presentation is a journey through some (very) old computer science papers that contain a lot of very valuable knowledge regarding the problems we face today. For each of the papers, some of the key ideas are presented and how they address our current challenges.
Of course, the voice track is missing and there are a lot more papers that would be worth being mentioned in this presentation. Still, I hope that also the slides alone will be of some value for you - and convince you a bit that not everything "old" in IT is automatically worthless ... ;)
Technical Excellence Doesn't Just Happen--Igniting a Craftsmanship CultureAllison Pollard
This document discusses igniting a culture of craftsmanship in software development. It argues that technical excellence is necessary for agility, as ignoring technical debt and quality will eventually slow a project. The document outlines some common causes of technical debt, such as cutting corners and overengineering. It also discusses how paying down technical debt through refactoring can improve both internal code quality and external customer outcomes. Overall, the document advocates for continuous attention to technical practices, automated testing, refactoring and simple designs in order to sustain agility in software development.
This workshop aims at discussing and sharing our experiences for effectively learning and applying Cloud Computing in building IT solutions. There are discussions on biggest Cloud Computing services: Amazon’s AWS, Microsoft’s Azure, IBM’s Bluemix.
CyberArk Engineering: Guilds - our journey to masteryDaniel Schwartzer
As any Agile development company, CyberArk's groups are built as autonomous cross-functional units, aimed at fast delivery.
On the downside, this means we are facing hard times moving forward cross-R&D initiatives or technology changes. Engineers from the same technical discipline in different groups often barely know one another, and have no systematic way of introducing and pursuing such initiatives.
In this talk, Daniel Schwartzer, CyberArk's R&D Chief Technologist, will explain how we came to realize that Professional Guilds are needed to help us gain better mastery and accelerate Engineering initiatives.
We all have seen our share of bad code. We certainly have come across some good code as well. What are the characteristics of good code? How can we identify those? What practices can promote us to write and maintain more of those good quality code. This presentation will focus on this topic that has a major impact on our ability to be agile and succeed.
Test Driven Development (TDD) is a core practice in the SDLC, especially ones that run using the agile mindset and leverage the practices of eXtreme programming. Since its inception and rediscovery by Kent beck in the late 1990s, it has gained popularity among many software development teams. However, like any popular software development practices, teams lose interest in TDD overtime and drop the practice all together. The main reason behind this is practicing it "the wrong way".
In this session, I present 7 anti-patterns that can ruin the TDD experience of a software development team. I also present how to counter these anti-patterns to fully leverage the benefits of TDD.
Similar to Growing Software and Growing Ourselves (20)
Taking AI to the Next Level in Manufacturing.pdfssuserfac0301
Read Taking AI to the Next Level in Manufacturing to gain insights on AI adoption in the manufacturing industry, such as:
1. How quickly AI is being implemented in manufacturing.
2. Which barriers stand in the way of AI adoption.
3. How data quality and governance form the backbone of AI.
4. Organizational processes and structures that may inhibit effective AI adoption.
6. Ideas and approaches to help build your organization's AI strategy.
TrustArc Webinar - 2024 Global Privacy SurveyTrustArc
How does your privacy program stack up against your peers? What challenges are privacy teams tackling and prioritizing in 2024?
In the fifth annual Global Privacy Benchmarks Survey, we asked over 1,800 global privacy professionals and business executives to share their perspectives on the current state of privacy inside and outside of their organizations. This year’s report focused on emerging areas of importance for privacy and compliance professionals, including considerations and implications of Artificial Intelligence (AI) technologies, building brand trust, and different approaches for achieving higher privacy competence scores.
See how organizational priorities and strategic approaches to data security and privacy are evolving around the globe.
This webinar will review:
- The top 10 privacy insights from the fifth annual Global Privacy Benchmarks Survey
- The top challenges for privacy leaders, practitioners, and organizations in 2024
- Key themes to consider in developing and maintaining your privacy program
Best 20 SEO Techniques To Improve Website Visibility In SERPPixlogix Infotech
Boost your website's visibility with proven SEO techniques! Our latest blog dives into essential strategies to enhance your online presence, increase traffic, and rank higher on search engines. From keyword optimization to quality content creation, learn how to make your site stand out in the crowded digital landscape. Discover actionable tips and expert insights to elevate your SEO game.
Have you ever been confused by the myriad of choices offered by AWS for hosting a website or an API?
Lambda, Elastic Beanstalk, Lightsail, Amplify, S3 (and more!) can each host websites + APIs. But which one should we choose?
Which one is cheapest? Which one is fastest? Which one will scale to meet our needs?
Join me in this session as we dive into each AWS hosting service to determine which one is best for your scenario and explain why!
Main news related to the CCS TSI 2023 (2023/1695)Jakub Marek
An English 🇬🇧 translation of a presentation to the speech I gave about the main changes brought by CCS TSI 2023 at the biggest Czech conference on Communications and signalling systems on Railways, which was held in Clarion Hotel Olomouc from 7th to 9th November 2023 (konferenceszt.cz). Attended by around 500 participants and 200 on-line followers.
The original Czech 🇨🇿 version of the presentation can be found here: https://www.slideshare.net/slideshow/hlavni-novinky-souvisejici-s-ccs-tsi-2023-2023-1695/269688092 .
The videorecording (in Czech) from the presentation is available here: https://youtu.be/WzjJWm4IyPk?si=SImb06tuXGb30BEH .
AI 101: An Introduction to the Basics and Impact of Artificial IntelligenceIndexBug
Imagine a world where machines not only perform tasks but also learn, adapt, and make decisions. This is the promise of Artificial Intelligence (AI), a technology that's not just enhancing our lives but revolutionizing entire industries.
Skybuffer SAM4U tool for SAP license adoptionTatiana Kojar
Manage and optimize your license adoption and consumption with SAM4U, an SAP free customer software asset management tool.
SAM4U, an SAP complimentary software asset management tool for customers, delivers a detailed and well-structured overview of license inventory and usage with a user-friendly interface. We offer a hosted, cost-effective, and performance-optimized SAM4U setup in the Skybuffer Cloud environment. You retain ownership of the system and data, while we manage the ABAP 7.58 infrastructure, ensuring fixed Total Cost of Ownership (TCO) and exceptional services through the SAP Fiori interface.
Fueling AI with Great Data with Airbyte WebinarZilliz
This talk will focus on how to collect data from a variety of sources, leveraging this data for RAG and other GenAI use cases, and finally charting your course to productionalization.
Your One-Stop Shop for Python Success: Top 10 US Python Development Providersakankshawande
Simplify your search for a reliable Python development partner! This list presents the top 10 trusted US providers offering comprehensive Python development services, ensuring your project's success from conception to completion.
Monitoring and Managing Anomaly Detection on OpenShift.pdfTosin Akinosho
Monitoring and Managing Anomaly Detection on OpenShift
Overview
Dive into the world of anomaly detection on edge devices with our comprehensive hands-on tutorial. This SlideShare presentation will guide you through the entire process, from data collection and model training to edge deployment and real-time monitoring. Perfect for those looking to implement robust anomaly detection systems on resource-constrained IoT/edge devices.
Key Topics Covered
1. Introduction to Anomaly Detection
- Understand the fundamentals of anomaly detection and its importance in identifying unusual behavior or failures in systems.
2. Understanding Edge (IoT)
- Learn about edge computing and IoT, and how they enable real-time data processing and decision-making at the source.
3. What is ArgoCD?
- Discover ArgoCD, a declarative, GitOps continuous delivery tool for Kubernetes, and its role in deploying applications on edge devices.
4. Deployment Using ArgoCD for Edge Devices
- Step-by-step guide on deploying anomaly detection models on edge devices using ArgoCD.
5. Introduction to Apache Kafka and S3
- Explore Apache Kafka for real-time data streaming and Amazon S3 for scalable storage solutions.
6. Viewing Kafka Messages in the Data Lake
- Learn how to view and analyze Kafka messages stored in a data lake for better insights.
7. What is Prometheus?
- Get to know Prometheus, an open-source monitoring and alerting toolkit, and its application in monitoring edge devices.
8. Monitoring Application Metrics with Prometheus
- Detailed instructions on setting up Prometheus to monitor the performance and health of your anomaly detection system.
9. What is Camel K?
- Introduction to Camel K, a lightweight integration framework built on Apache Camel, designed for Kubernetes.
10. Configuring Camel K Integrations for Data Pipelines
- Learn how to configure Camel K for seamless data pipeline integrations in your anomaly detection workflow.
11. What is a Jupyter Notebook?
- Overview of Jupyter Notebooks, an open-source web application for creating and sharing documents with live code, equations, visualizations, and narrative text.
12. Jupyter Notebooks with Code Examples
- Hands-on examples and code snippets in Jupyter Notebooks to help you implement and test anomaly detection models.
Threats to mobile devices are more prevalent and increasing in scope and complexity. Users of mobile devices desire to take full advantage of the features
available on those devices, but many of the features provide convenience and capability but sacrifice security. This best practices guide outlines steps the users can take to better protect personal devices and information.
4. 44
TODAY’S MISSION.
1. 40 MINS - PROVIDE A 10,000 FOOT VIEW OF:
● Code smells & refactoring
○ Technical debt
● Test-Driven Development
○ Classicist TDD
○ Outside-In TDD
● SOLID Principles
○ Some other important principles
● Clean Code & Clean Architecture
○ What is bad code?
○ Habitability
● Spiking & Walking Skeletons
○ Feedback loops
2. 5 MINS - TIPS TO GROW AS A PROFESSIONAL
3. Q&A
16. 16
16
The second law of thermodynamics, in principle, states
that a closed system's disorder cannot be reduced, it can
only remain unchanged or increase. A measure of this
disorder is entropy. This law also seems plausible for
software systems; as a system is modified, its disorder, or
entropy, tends to increase. This is known as software
entropy..
IVAR JACOBSON.
17. 17
TECHNICAL
DEBT / MESS.
Technical debt is a concept in software development
that reflects the implied cost of additional rework
caused by choosing an easy solution now instead of
using a better approach that would take longer.
Leads to “spaghetti code”.
REFACTORING
18. 18
ESSENTIAL VS
ACCIDENTAL
COMPLEXITY.
Essential tasks, the fashioning of the complex
conceptual structures that compose the abstract
software entity.
Accidental tasks, the representation of these abstract
entities in programming languages and the mapping of
these onto machine languages within space and speed
constraints.
REFACTORING
19. 19
BROKEN
WINDOWS
THEORY.
A criminological theory that visible signs of crime, anti-
social behavior, and civil disorder create an urban
environment that encourages further crime and
disorder, including serious crimes.
REFACTORING
20. 20
THE BOY
SCOUT RULE.
Leave the campsite cleaner than we found it.
Small, incremental improvements that cumulatively
make a large difference over time.
REFACTORING
22. 22
TEST-DRIVEN
DEVELOPMENT.
DESIGN WITH EXAMPLES
Test-driven development (TDD) is
a software development process
that relies on the repetition of a
very short development cycle:
requirements are turned into
very specific test cases, then the
software is improved to pass the
new tests, only.
25. 2525
CLASSICIST TDD.
CLASSICIST TDD (CHICAGO SCHOOL):
● Also called, inside-out TDD
● State based verification
● Use of triangulation
● Stimulus / response pairs
● Explore one fact about the system at a time
● Useful for algorithmic problems
“As the tests get more specific, the code gets
more generic.”
- Robert C. Martin
34. 3434
OUTSIDE-IN TDD.
OUTSIDE-IN TDD (LONDON SCHOOL):
● Also called, mockist TDD
● Start testing at the boundaries of the system
● Focus on behaviour verification
● Interaction between objects
● Use of stubs to verify data flow
● Use of mocks to verify side effects
39. 3939
MOCKS & STUBS.
MOCKS:
● Test that a side effect did occur
● Test that a side effect didn’t occur
● Control how data flows through the SUT
STUBS:
44. 44
SOLID PRINCIPLES.
DESIGN PRINCIPLES
In object-oriented computer
programming, SOLID is a
mnemonic acronym for five
design principles intended to
make software designs more
understandable, flexible and
maintainable.
47. 47
S.O.L.I.D
SINGLE RESPONSIBILITY
A class should have only a single responsibility, that is, only
changes to one part of the software's specification should be
able to affect the specification of the class.
OPEN/CLOSED
Software entities should be open for extension, but closed for
modification.
LISKOV SUBSTITUTION
Objects in a program should be replaceable with instances of
their subtypes without altering the correctness of that
program.
INTERFACE SEGREGATION
Many client-specific interfaces are better than one general-
purpose interface. Don’t force clients to depend on methods
they don’t use.
DEPENDENCY INVERSION
Depend on abstractions, not concretions.
48. 48
OTHER
PRINCIPLES.
SEPARATION OF CONCERNS
Clearly separate things that change for different reasons or at
different rates of speed.
COMMAND / QUERY SEGREGATION
Methods should either be a command that performs an action,
or a query that returns data to the caller, but not both.
TELL, DON’T ASK
“Ask the question we really want answered, instead of asking for the
information to help us figure out the answer ourselves” - Growing
Object-Oriented Software, Guided By Tests
SLAP
Single level of abstraction principle.
DRY
Don’t repeat yourself.
49. 49
CLEAN CODE
& ARCHITECTURE.
DESIGN PRINCIPLES
“Even bad code can function. But
if code isn’t clean, it can bring a
development organisation to its
knees.
Every year, countless hours and
significant resources are lost
because of poorly written code.
But it doesn’t have to be that
way.”
52. 52
52
Habitability is the characteristic of source
code that enables people coming to the code
later in its life to understand its construction
and intentions and to change it comfortably
and confidently.
RICHARD GABRIEL.
54. 54
WHAT IS
BAD CODE?
DOESN’T REVEAL INTENT
Abbreviations, ambiguity, unclear naming,
excessive use of comments
DIFFICULT TO REASON ABOUT
Large classes / methods, code at different levels of abstraction,
Single Responsibility Principle violation, Command Query
Segregation Principle violation
TIGHTLY COUPLED
Entities are inappropriately intimate, unable to test entities in
isolation, poor / no separation of concerns
SCARY TO CHANGE
Low / no test coverage makes changes risky, developers
scared to add features to / maintain the codebase
CLEAN CODE
55. The best metric for design
refuse is WTFs per minute.
ROBERT C. MARTIN
56. 56
KENT BECK’S
4 RULES OF
SIMPLE DESIGN
TESTS PASS
EXPRESSES INTENT
NO DUPLICATION (DRY)
SMALL
CLEAN CODE
66. 66
DDD: CONTEXT
& LANGUAGE.
DDD: UBIQUITOUS LANGUAGE
Striving to use the vocabulary of a given business domain,
not only in discussions about the requirements for a
software product, but also in discussions of design as well
the source code itself.
70. 70
SPIKING &
WALKING
SKELETON.
UNKNOWN UNKNOWNS
"A Walking Skeleton is a tiny implementation of the system
that performs a small end-to-end function. It need not use
the final architecture, but it should link together the main
architectural components. The architecture and the
functionality can then evolve in parallel."
- Alistair Cockburn
72. The faster we receive feedback,
the sooner we can learn and
take action.
73. 7373
TECHNICAL
SPIKE.
SPIKING:
● Experimentation
● Figure out answers to tough technical or design problems
● Reduce the risk of complications and problems
● Validate assumptions & technology choices
● Better understanding, better estimates
● Risk mitigation
● Doesn’t focus on quality, focus is on learning
● Throw away
74. A “walking skeleton” is an
implementation of the thinnest
possible slice of real functionality
that we can automatically build,
deploy, and test end-to-end
ALISTAIR COCKBURN
76. 7676
SUMMARY.
● Take time to learn the fundamentals of software design
○ SOLID,
○ Code smells
○ Refactoring
○ Four rules of simple design
● Adopt TDD
● Protect what makes you money from low level details like frameworks
● Naming is important
○ Use a common language incorporating business terms
● Flush out uncertainty with spikes and walking skeletons
84. The amount of serendipity that will occur
in your life, your Luck Surface Area, is
directly proportional to the degree to
which you do something you're
passionate about combined with the total
number of people to whom this is
effectively communicated.
JASON ROBERTS