How do you simplify your code with DRY and KISS principles?

Don't Repeat Yourself is a clear instruction on avoiding the duplication of knowledge. It can be an algorithm, a business logic, an architectural diagram, a user document, or something similar which is the unique location for that specific knowledge. So, in the code; developers must make sure to avoid the repetition of knowledge in multiple places; but have them in a specific place. Those can be reusable methods, classes, modules or even components. This helps reducing maintenance efforts as the change must be done (& probably tested) only at one place. However this is not the avoidance of simple code duplication. There can be duplicated codes related to two different business contexts which cannot be extracted into common area.

The DRY principle in coding stands for "Don't Repeat Yourself." It means that in your code, you should avoid duplicating the same logic or information in multiple places. Instead, you should create reusable functions, classes, or variables to keep your code concise and maintainable. By following DRY, you make your code easier to understand, update, and debug. It also helps prevent errors that can occur when you have multiple copies of the same code that need to be kept in sync. In essence, DRY promotes efficiency and clarity in your code. Writing code once and using it many times is a smart approach to software development!

DRY principle is also referred to as "Once And Only Once" (OAOO). According to the classic software engineering book, The Pragmatic Programmer, applying the DRY principle means we have to ensure that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system." Note, the authors, Dave Thomas and Andy Hunt talk about knowledge, and didn't explicitly mention code - that means a system's knowledge is far broader than its code. Thus the DRY principle is also valid for documentation, test plans, system configuration data, or even the project. "Copy and paste is a design error." - David L. Parnas, an early pioneer of software engineering and modular design.

🛠️ Streamline your coding! I'd emphasize the power of the DRY and KISS principles in elevating the quality and maintainability of your software. When you're tempted to copy-paste, remember DRY; creating reusable components will make your codebase more adaptable. Let KISS be your guide when faced with an intricate solution; prioritize straightforwardness over unnecessary complexities. The bonus? Descriptive naming and adherence to coding standards will ensure your code is a joy to revisit by you or any other developer. Abide by these guidelines, and you'll craft code that stands the test of time.

DRY - Don't Repeat Yourself is a form of 'Lean' concept, whereby one does not want to duplicate a process due to faulty coding. The measurement within Lean is called NRFT (or Not Right First Time). As a simple example, when paying for a process to be completed, (like; coding a program) no one wants to pay for it twice or as DRY would say 'Don't Repeat Yourself!' So, code it right first time, don' repeat yourself through errors and the client then only pays for your work once! You will make more money by getting it right first time for your clients who then pay you quicker. The measure here is simple: Amount of faulty Code written ________________________________ X Amount of code Amount of Code written written = % of NRFT

The DRY principle, “Don't Repeat Yourself,” is a foundational guideline. It advocates for code reusability and maintainability by ensuring that each piece of logic or functionality has a single authoritative representation in the codebase. DRY minimizes redundancy, reducing the risk of errors and making code more understandable. DRY code is easier to maintain, fosters efficient collaboration, and allows for quicker responses to changing requirements and bug fixes.

DRY and KISS principle comes under Object Oriented Programming principles'. DRY stand for Don't Repeat yourself. It means write reusable code using macros, include your file as header files or use external reference , so that the code is written only once and where ever needed we just call a reference to it. Since we call them by reference means we save memory.

DRY is good in theory, in practice... Microservices should be fully isolated, abstracting dependencies out. Having a common library, for example - who owns it, who determines changes, what if changes break things, do you need to keep multiple versions etc. DRY me for is an aim but not an absolute requirement.

In order to avoid breaking the DRY principle one should divide the system into pieces. Then fragment or divide the logic and code into smaller units that are reusable and call the code where one wants it. The written methods used should not be lengthy however; the logic should be divided and used as an existing piece on one’s method. The violations of the DRY principles include the WET “We enjoy typing” which means one is rewriting the same logic or code in several different ways (not to be misunderstood as polymorphism). This makes it hard to manage the code and if a change in the logic occurs then changes have to be made in all places that the code has been written.

The KISS principle in coding stands for "Keep It Simple, Stupid." It means that when you're writing code, you should strive for simplicity and avoid unnecessary complexity. Your code should be as straightforward and easy to understand as possible. By following KISS, you make your code more readable, maintainable, and less prone to errors. Complex solutions might seem impressive, but they can be harder to work with and troubleshoot in the long run. In essence, KISS encourages you to find the simplest solution to a problem that gets the job done effectively. Simplicity is often the key to writing better and more reliable code!

While writing new piece of code one should always see : 1) Does the similar method or functions are already written. 2) Does the framework provides any such similar methods or functions which can be re utilized 3) Can I minimize the piece of code. 4) Use AI or Co-Pilot to enhance to quality of your code. 5) Try to keep it as simple as possible. 6) Make the function or method generic 7) Move your method a place or package which is globally accessible and can be accessible by others 8) Follow best practices while declaring global, variables etc. 9) Use Code Quality tool

The KISS principle implies that simplicity should be a major goal in software development, and that unnecessary complexity should be avoided. In simple terms, it means "keep your code as simple as you can." In eXtreme Programming (XP), this principle is indicated by a practice named "Do the simplest thing that could possibly work" (DTSTTCPW). Of course, if there are software requirements for reusability, flexibility, extensibility etc, adding complexity in order to fulfill those requirements become inevitable. But be careful, add only that amount of complexity that makes things easier.

KISS stand for Keep It Simple Stupid. It is one of the object oriented concept you come across while designing your project. It tells that write coding or design in simple way so that the logic should be understandable by the every one easily.

Too many people overthink, overengineer. Write only the code that is needed; for me TDD principles encourage that. Write test - write code satisfying test. Gives you and absolute bare minimum as long as the tests are exhaustive.

Keep It Simple, Sweetheart, is a nicer expression. Remember in measuring code there's no extra benefit to you or the client for over complicating a process or indeed a code. In term of 'Lean' this would be defined as 'Waste'. Waste processes are looked to be eliminated within Lean. Two Wastes from the 8 are seen here as: Overproduction Over Processing Why make more code than you actually need and why take more time to process, or execute a program than you need to? It would be like walking around the block twice to get to the same shop that's 100 yards away. These two wastes are seen all the time in businesses and processes and are fundamental in creating additional unwanted costs and slowing processes down. Solution: Process Mapping

In React. DRYing achieved by creating reusable components to avoid repeating similar code segments, using hooks for efficient state management and sharing data-fetching logic through utilities to prevent the repetition of API calls. Consistent styling and theming can be established to avoid duplication of style definitions, while separating application logic ensures reusability and maintainability. Leveraging third-party libraries can further reduce code repetition, leading to a more efficient, maintainable, and clean React codebase. DRY principle ensures that common logic and components are reused, reducing the need for modifications in multiple places and aligning with the core tenets of DRY.

From a coding lens DRY depends on the features of the language. For example, in C you would approach this by creating reusable function names that can take more generic arguments calculateSquare(int x) or calculateCube(int x) could become calculatePower(num, 2) and calculatePower(num, 3). In a language like ruby, you could approach this through object-oriented design by using class inheritance and overloading

A great example of DRYing your DB schema is about removing flags such as isCompleted and keeping only completed_date. One more example is about splitting logic into views, controllers, providers. As a result two different controllers may data from different providers but return the same view. If you are building some app that always calculates logarithm, then you should consider moving the logarithm function into a re-usable library, so you don't need to write this piece of code in every module.

If you have repetitive code, then usually you'll find repetitive / similar tests across test classes. Consider copying/adapting those tests to a new test class; tests will fail. Copy the repetitive code to a new class to cause the tests to succeed. Once those tests work, when replace the code in the original classes with a delegated call to the newly created class method. Tests should work with minimal refactoring.

KISS is one of those principles software engineers often forget when they develop software. They tend to write code in a more complicated way than it should be. Always keep in mind that any software system has an intrinsic complexity that is already challenging in itself. Obviously, complex problems often require complex code. The intrinsic complexity cannot be reduced there. But it would be fatal to add unnecessary complexity to this intrinsic complexity. Hence it's advisable not to use every fancy feature of a programming language or cool design patterns just because you can. However, don't overdo simplicity. If there are ten decision checks as per your requirements, that is just how it is.

Keeping things simple not only helps to make it easier to return to the code you previously wrote, but it also helps to make it easier for your team to read, understand, maintain and critique the code. Applying this principle throughout the team can make collaboration far easier and maintenance far less painful.

In other words, don't overengineer things. Simplify data-flows, calculations, use as simple as poissible patterns. As an example, the sync between two databases may be implemented with outbox pattern or you can simplify it and structure logic in a way that you know exactly where the truth is. You can iterate on those simplified solutions later when you have time, you have need to improve them.

Solution, to KISS is Process Mapping You can adapt this to suit your process or coding: List: Complete as appropriate: Column 1 your Operations Data Processing Column 2 your Data / Decision Processing Column 3 your Data / Inspection Process Column 4 your Delays in Process Column 5 your Storage of Data Column 6 your Handling of Data Time the Process and at the bottom totter-up your times. See what part of your coding or program is taking the longest - is it delays because of wrong data? or too many inspection checks in the program? Functions are needed but are there too many? KISS is to Keep it Simple Sweetheart. Process Mapping is key to identify where the over complex coding lies. Good Luck!

If you repeat yourself, you always have to make changes in multiple places; you might not remember where else you had written the same logic, and you might make more mistakes and produce new bugs.

The biggest benefit is simplicity. Those are two simple principles that helps you to avoid spending nights to fix a defect in production. It helps newcomers to learn the codebase faster and become an integral members of a team.

The benefits of DRY become more vivid when you want to modify/refactor the code. Suppose you have defined the same function in multiple files. In case of a need for a modification, you have to check and correct all instances one by one in all files. However, if you had defined it in one place and used it in all required cases, you have an easy job. Modify the single function, and all use cases will be corrected.

When designing platforms, systems or code for that matter consider: What is it I am making? Many find themselves making a product and fundamentally this for me is a fault. Yes, its ok to make a product but once you have made it, what have you made? One product. My view for what it is worth make and design build an engine. Engines fits into all types of things and can be adapted to become multiple products. In Lean we look at 'grouping parts' or 'families' of parts to consolidate or integrate them for runs of production or coding for multiple systems. DRY helps achieve this concept too, By using similar patterns in process, leads to easier user processes with less training, repeatable code, less work and quicker turnaround. Design clever!