Infotech is a global Information Technology company committed to Empowering Business Transformation. Our Independent Testing and Compliance Business [ITCB] became the world's first true testing platform in 2011 -- ClouT™
Quality in delivered software is intangible and very different from quality in physical goods. Some external attributes of quality software-free from defects and easy to maintain-are reflections of the code's internal qualities. When classes and methods are cohesive, non-redundant, well-encapsulated, assertive, and explicitly coupled, they are less prone to mistakes and far easier to debug, test, and maintain. David Bernstein asserts that paying attention to code quality helps us focus on the key principles, patterns, and practices used by expert developers. If you don't pay attention to critical code quality attributes, iterative development practices can quickly degrade code into a maintenance nightmare. Join David and your peers to take a deep dive into the code qualities that make software more maintainable and less bug friendly.
The question of how much-or how little-design to do up-front on a project often leads to a conundrum. Too much design often results in overkill engineering that results in extra complexity and wasted effort. Too little design results in insufficient system structures that result in extra complexity and wasted effort. So, how can you determine the right balance for a given application or system? Alan Shalloway offers a proven approach to determine how much design work to do before beginning the code-build steps in a project. Alan has learned that the trick is to discover and ponder what you don’t know, how it may affect you, and then how to isolate these risks in your code in the simplest way possible.
Have you heard any of these from your development staff or said them yourself? "Our software and systems are too fragile." "Technical debt is killing us." "We need more time to refactor." Having quality code is great, but we should understand why it matters and specifically what is important to your situation. Joel Tosi begins by defining and discussing some common code metrics-code complexity, coverage, object distance, afferent/efferent coupling, and cohesion. From there, Joel takes you through an application with poor code metrics and shows how this application would be difficult to enhance and extend in the future. Joel wraps up with a discussion about what metrics are applicable for specific situations such as legacy applications, prototypes, and startups. You'll come away from this class with a better understanding of code metrics and how to apply them pragmatically.
Assaults against digital assets are unquestionably on the rise. If you create applications that handle valuable assets, your code WILL be attacked. In addition to lost revenue and productivity, the consequences of compromised systems can include loss of trust, a tarnished reputation, and legal problems. Much like quality assurance, it’s important to have a holistic approach to security that unifies people, process, and technology. Cassio Goldschmidt introduces defense techniques that measurably reduce the number and severity of software vulnerabilities. These include secure coding techniques, minimizing the use of unsafe functions, use of compiler and linker security options, and specialized static analysis tools. Enrich your development lifecycle with threat modeling, security code review, penetration testing, and vulnerability management.
The question of how much design to do up-front on a project is an engaging one. Too much design often results in overkill, complexity, and wasted work. Too little design results in insufficient system structures that require rework, additional complexity, and wasted effort. How can we know what the right balance is? Alan Shalloway shows how to use the advice from Design Patterns coupled with the attitude of not building what you don't need from Agile. The trick is in discovering what you don't know, how it may affect you, and then how to isolate these risks in your code in a simple manner. Alan describes the essence of emergent design–that is, starting with a simple design and letting it evolve as the requirements evolve. He also demonstrates how to refactor to better designs and how this is different from refactoring bad code.
Developers often run into the same issues on every project. As the software is created, design problems start to creep in-causing maintenance releases with no new features, project delays, and worse. While some of these problems can be resolved by simple refactoring, others can be fixed only by a complex code restructuring effort. But you can avoid most these issues in the first place with prefactoring-using your experiences in previous projects and the experiences of others to help in early detection of common design errors and problems.
Functions are the basic building blocks of computer systems. Object-oriented classes are a way of packaging functions with shared data. Inheritance and polymorphism essentially are all about finding the right function. It’s all about functions! Get the picture? Chuck Allison explains that functions come in many varieties: static functions, polymorphic functions, generic functions, nested functions, higher-order functions, generator (aka stream) functions, coroutines, function closures, delegates, etc. Functions can handle arguments in different ways: by value, by result, by reference, by sharing, and by need, to name a few. Do you know how and when to use which? Functions should also be resource-friendly and robust should something hit the proverbial fan. Are your functions error-safe? Reusable? Maintainable? Do you know-really know-how to write a function? Come join Chuck and find out.
As certain as evolving requirements lead to code changes, code changes lead to code degradation. Therefore, code refactoring is critical to the long-term viability of all software products. Kevin Sawicki shares tips and tricks for refactoring to help developers identify code that needs refactoring, preserve the correct code history during refactoring sessions, and ensure that appropriate unit tests cover the refactored code. Kevin demonstrates the Eclipse open-source frameworks and Java-based tools, including EMMA for code coverage analysis and JUnit for unit testing. These tools not only make code refactoring less painful, they also empower developers to constantly improve their code through relentless refactoring. Kevin outlines a step-by-step process to find refactoring candidates, perform the refactorings in an isolated code branch, and collaborate with other developers to review the refactored code.
Even though the code may have been written only five years ago, there it is-a sprawling unintelligible mess that nobody wants to touch. For most people and teams, this reality is a cause for fear and loathing-something we want to sweep under the rug. We can, however, choose to see “bad” code as a challenge to restructure and refactor into a maintainable design that serves the business for years to come. Although legacy code presents many constraints on design choices, it offers the opportunity for incremental improvement. Michael Feathers shows you how to practice design within the boundaries of what some see as unintelligible code and explains ways to make the improvement process manageable. See how you can escape the fear that holds you back from productive action. Find out how to start with what you have now and progress toward a structure that supports the work at hand and immediately adds value.