| A | B | C | D | |
|---|---|---|---|---|
1 | Read row 86 today | |||
2 | ||||
3 | Subject | Concept | Description | More info |
4 | Algorithms & Data Structures | Big O Notation | Big O notation is used in Computer Science to describe the performance or complexity of an algorithm. Big O specifically describes the worst-case scenario, and can be used to describe the execution time required or the space used (e.g. in memory or on disk) by an algorithm. | https://dev.to/amejiarosario/8-time-complexities-that-every-programmer-should-know-494m https://robbell.io/2009/06/a-beginners-guide-to-big-o-notation |
5 | Application Architecture | Serverless Architectures | Serverless architectures are application designs that incorporate third-party “Backend as a Service” (BaaS) services, and/or that include custom code run in managed, ephemeral containers on a “Functions as a Service” (FaaS) platform. By using these ideas, and related ones like single-page applications, such architectures remove much of the need for a traditional always-on server component. Serverless architectures may benefit from significantly reduced operational cost, complexity, and engineering lead time, at a cost of increased reliance on vendor dependencies and comparatively immature supporting services. AWS: AWS Lambda Microsoft Azure: Azure Functions Google Cloud: Cloud Functions | https://martinfowler.com/articles/serverless.html |
6 | Application Architecture | Micro Frontends | In particular, we're seeing patterns emerge for decomposing frontend monoliths into smaller, simpler chunks that can be developed, tested and deployed independently, while still appearing to customers as a single cohesive product. We call this technique micro frontends, which we define as: "An architectural style where independently deliverable frontend applications are composed into a greater whole" Some of the key benefits that we've seen from micro frontends are: - smaller, more cohesive and maintainable codebases - more scalable organisations with decoupled, autonomous teams - the ability to upgrade, update, or even rewrite parts of the frontend in a more incremental fashion than was previously possible | https://martinfowler.com/articles/micro-frontends.html |
7 | Application Architecture | Command Query Responsibility Segregation | CQRS stands for Command Query Responsibility Segregation. It's a pattern that I first heard described by Greg Young. At its heart is the notion that you can use a different model to update information than the model you use to read information. For some situations, this separation can be valuable, but beware that for most systems CQRS adds risky complexity. The mainstream approach people use for interacting with an information system is to treat it as a CRUD datastore. By this I mean that we have mental model of some record structure where we can create new records, read records, update existing records, and delete records when we're done with them. In the simplest case, our interactions are all about storing and retrieving these records. As our needs become more sophisticated we steadily move away from that model. We may want to look at the information in a different way to the record store, perhaps collapsing multiple records into one, or forming virtual records by combining information for different places. On the update side we may find validation rules that only allow certain combinations of data to be stored, or may even infer data to be stored that's different from that we provide. | https://martinfowler.com/bliki/CQRS.html |
8 | Computer programming | Callback | In computer programming, a callback, is any executable code that is passed as an argument to other code that is expected to call back (execute) the argument at a given time. This execution may be immediate as in a synchronous callback, or it might happen at a later time as in an asynchronous callback. In all cases, the intention is to specify a function or subroutine as an entity that is, depending on the language, more or less similar to a variable. | https://en.wikipedia.org/wiki/Callback_(computer_programming) |
9 | Databases | Relational database | A relational database is a set of formally described tables from which data can be accessed or reassembled in many different ways without having to reorganize the database tables. The standard user and API of a relational database is the Structured Query Language (SQL). Each table, which is sometimes called a relation, in a relational database contains one or more data categories in columns, also called attributes. Each row, also called a record or tuple, contains a unique instance of data, or key, for the categories defined by the columns. Each table has a unique primary key, which identifies the information in a table. The relationship between tables can then be set via the use of foreign keys -- a field in a table that links to the primary key of another table. | https://searchdatamanagement.techtarget.com/definition/relational-database |
10 | Design Patterns | Strategy pattern | The strategy pattern, also known as the policy pattern, is a behavioral design pattern that lets an object execute some algorithm (strategy) based on external context provided at runtime. This pattern is particularly useful when you have an object that needs to be able to execute a single behavior in different ways at different times. | https://www.dotnettricks.com/learn/designpatterns/strategy-design-pattern-c-sharp |
11 | Design Patterns | Singleton pattern | It involves only one class which is responsible to instantiate itself, to make sure it creates not more than one instance; in the same time it provides a global point of access to that instance. In this case the same instance can be used from everywhere, being impossible to invoke directly the constructor each time. Intent Ensure that only one instance of a class is created. Provide a global point of access to the object. | https://www.oodesign.com/singleton-pattern.html |
12 | Design Patterns | Decorator pattern | The decorator pattern, also known as the wrapper pattern, is when you wrap an object within another object, thus providing a means of enhancing or overriding certain behavior. The wrapper object will delegate any incoming method calls to the original object, unless it defines a new method to enhance or replace the original object’s behavior. By using the decorator pattern, you can dynamically create as many decorated objects as you want, each enhancing the behavior of the original object in a unique way — and all without mutating the original object. In this manner, you can effectively add, remove, or extend behaviors at runtime. | https://pavcreations.com/decorator-design-pattern-for-dynamic-game-stats/ |
13 | Design Patterns | Dependency injection | Dependency: A “dependency” is an object that a class depends on to perform its functionality. For example, if you’re building a game, a character might depend on a weapon to attack enemies. In software, dependencies can be anything from data sources to other classes or services. Injection: “Injection” refers to the process of providing these dependencies to a class from outside. Instead of the class creating its own dependencies, they are provided externally. | https://medium.com/@sonusprocks/dependency-injection-unity-c-in-easy-words-8344c6eff52d#:~:text=Unity%20provides%20a%20feature%20called,by%20the%20application%20code%20itself. |
14 | Design Patterns | Circuit Breaker | It's common for software systems to make remote calls to software running in different processes, probably on different machines across a network. One of the big differences between in-memory calls and remote calls is that remote calls can fail, or hang without a response until some timeout limit is reached. What's worse if you have many callers on a unresponsive supplier, then you can run out of critical resources leading to cascading failures across multiple systems. In his excellent book Release It, Michael Nygard popularized the Circuit Breaker pattern to prevent this kind of catastrophic cascade. The basic idea behind the circuit breaker is very simple. You wrap a protected function call in a circuit breaker object, which monitors for failures. Once the failures reach a certain threshold, the circuit breaker trips, and all further calls to the circuit breaker return with an error, without the protected call being made at all. Usually you'll also want some kind of monitor alert if the circuit breaker trips. | https://martinfowler.com/bliki/CircuitBreaker.html |
15 | Design Patterns | Anti-patterns | - Premature Optimization: Profile before optimizing. Avoid trading simplicity for efficiency until it is needed, backed by empirical evidence - Bikeshedding: Avoid spending too much time on trivial decisions. - Analysis Paralysis: Prefer iterating to over-analyzing and speculation. - God Class: Avoid large classes with too many responsibilities and dependencies. - Fear of Adding Classes: More classes are not necessarily a sign of bad design. - Magic Numbers and Strings: Avoid having unexplained and unnamed numbers and string literals in code. - Management by Numbers: Use numbers to inform your decisions, not determine them | https://sahandsaba.com/nine-anti-patterns-every-programmer-should-be-aware-of-with-examples.html |
16 | Design Patterns | Anti pattern - 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. | https://blog.codinghorror.com/the-big-ball-of-mud-and-other-architectural-disasters/ |
17 | Design Patterns | Anti pattern - Deploying Software Manually | When the deployment process is not automated, it is not repeatable or reliable, leading to time wasted on debugging deployment errors. A manual deployment process has to be documented. With a manual process, there is no guarantee that the documentation has been followed. Only an automated process is fully auditable. Performing manual deployments is boring and repetitive and yet needs significant degree of expertise. | Etermax CI/CD talk |
18 | Design Patterns | DTO | DTO is a class representing some data with no logic in it. DTO’s are usually used for transferring data between different applications or different layers within a single application. You can look at them as dumb bags of information the sole purpose of which is to just get this information to a recipient. | https://enterprisecraftsmanship.com/posts/dto-vs-value-object-vs-poco/ |
19 | DDD | Anemic Domain Model | Application Layer [his name for Service Layer]: Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems. This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program. Domain Layer (or Model Layer): Responsible for representing concepts of the business, information about the business situation, and business rules. State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure. This layer is the heart of business software. | https://martinfowler.com/bliki/AnemicDomainModel.html |
20 | DDD | Aggregates | Is a domain pattern used to define object ownership and boundaries. Factories and Repositories are two design patterns which help us deal with object creation and storage. The number of associations should be reduced as much as possible. Firstly, associations which are not essential for the model should be removed. They may exist in the domain, but they are not necessary in our model, so take them out. Secondly, multiplicity can be reduced by adding a constraint. If many objects satisfy a relationship, it is possible that only one will do it if the right constraint is imposed on the relationship. Thirdly, many times bidirectional associations can be transformed in unidirectional ones. An Aggregate is a group of associated objects which are considered as one unit with regard to data changes. The Aggregate is demarcated by a boundary which separates the object inside those outside. Each Aggregate has one root. The root is an Entity, and it is the only object accessible from outside. The root can hold references to any of the aggregate objects, and the other objects can hold references to each other, but an outside object can hold references only to the root object. Yet there are other Entities inside the boundary, the identity of those entities is local, making sense only inside the aggregate. | |
21 | DDD | Entities | A category of objects which seem to have an identity, which remains the same throughout the states of the software. For these objects it is not the attributes which matter, but a thread of continuity and identity, which spans the life of a system and can extend beyond it, such objects are called entities. Implementing entities in software means creating identity. For a person it can be a combination of attributes: name, date of birth, place of birth, name of parents, current address. For a bank account the account number seems to be enough for its identity. Are important objects of a domain model, and they should be considered from the beginning of the modeling process. It is algo important to determine if an object need to be an entity or not. | ddd quickly |
22 | DDD | Value objects | When we need to contain some attributes of a domain element. We are not interested in which object it is, but what attributes it has. An object that is used to describe certain aspects of a domain, and which does not have identity. It is recommended to select as entities only those objects which conform to the entity definition. And make the rest of the objects Value Objects. Also they should be immutable. They are created with a constructor, and never modified during their lifetime. One golden rule: if Value Objects are shareable, they should me immutable. Value Objects can contain other Value Objects, and they can even contain references to Entities. Although Value Objects are used to simply contain attributes of a domain object, that does not mean that it should contain a long list with all the attributes. | ddd quickly |
23 | DDD | Services | They act as interfaces which provide operations. Are common in technical frameworks, but they can be used in the domain layer too. Services does not have an internal state, and its purpose is to simply provide functionality for the domain. The assistance provided by a Service can be a significant one, and a Service can group related functionality which serves the Entity and the Value Objects. They usually become a point of connection for many objects. While using Services, is important to keep the domain layer isolated. It is easy to get confused between services which belong to the domain layer, and those belonging to the infrastructure. Three characteristics: - The operation performed by the Service refers to a domain concept which does not naturally belong to an Entity or Value Object - The operation performed refers to other objects in the domain. - The operation is stateless | ddd quickly |
24 | DDD | Modules | Are used as a method of organizing related concepts and tasks in order to reduce complexity. Communicational cohesion is achieved when parts of the module operate on the same data. Using modules in design is a way to increase cohesion and decrease coupling | ddd quickly |
25 | DDD | Anti-Corruption layer | Implement a façade or adapter layer between different subsystems that don't share the same semantics. This layer translates requests that one subsystem makes to the other subsystem. Use this pattern to ensure that an application's design is not limited by dependencies on outside subsystems. Use this pattern when: - A migration is planned to happen over multiple stages, but integration between new and legacy systems needs to be maintained. - Two or more subsystems have different semantics, but still need to communicate. | https://www.youtube.com/watch?v=7fT6B7lO9OU https://docs.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer |
26 | Functional programming | Anonymous function | In computer programming, an anonymous function (function literal, lambda abstraction, or lambda expression (C#)) is a function definition that is not bound to an identifier. Anonymous functions are often arguments being passed to higher-order functions, or used for constructing the result of a higher-order function that needs to return a function. If the function is only used once, or a limited number of times, an anonymous function may be syntactically lighter than using a named function. Anonymous functions are ubiquitous in functional programming languages and other languages with first-class functions, where they fulfil the same role for the function type as literals do for other data types. | https://en.wikipedia.org/wiki/Anonymous_function |
27 | Functional programming | Foundation | The foundation of functional programming can be presented in three main ideas: - Immutable Data Structures - Pure Functions - First Class Functions | https://dev.to/ganderzz/introduction-to-functional-programming-598e |
28 | Functional programming | First class function | A programming language is said to have First-class functions when functions in that language are treated like any other variable. For example, in such a language, a function can be passed as an argument to other functions, can be returned by another function and can be assigned as a value to a variable. | https://developer.mozilla.org/en-US/docs/Glossary/First-class_Function |
29 | Functional programming | Lazy evaluation | Is an evaluation strategy which delays the evaluation of an expression until its value is needed (non-strict evaluation) and which also avoids repeated evaluations (sharing). The sharing can reduce the running time of certain functions by an exponential factor over other non-strict evaluation strategies, such as call-by-name. The benefits of lazy evaluation include: The ability to define control flow (structures) as abstractions instead of primitives. The ability to define potentially infinite data structures. This allows for more straightforward implementation of some algorithms. Performance increases by avoiding needless calculations, and avoiding error conditions when evaluating compound expressions. | https://en.wikipedia.org/wiki/Lazy_evaluation |
30 | Java | Maven | Maven is a "build management tool", it is for defining how your .java files get compiled to .class, packaged into .jar (or .war or .ear) files, (pre/post)processed with tools, managing your CLASSPATH, and all others sorts of tasks that are required to build your project. It is similar to Apache Ant or Gradle or Makefiles in C/C++, but it attempts to be completely self-contained in it that you shouldn't need any additional tools or scripts by incorporating other common tasks like downloading & installing necessary libraries etc. | https://stackoverflow.com/questions/13335351/what-does-maven-do-in-theory-and-in-practice-when-is-it-worth-to-use-it |
31 | Methodologies & Frameworks | Agile manifesto | Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. | https://agilemanifesto.org/principles |
32 | Methodologies & Frameworks | Lean management | Lean management is an approach to running an organisation that supports the concept of continuous improvement. It is an ongoing effort to improve products, services, or processes, which require “incremental” improvement over time in order to increase efficiency and quality. Lean management uses methods for eliminating factors that waste time, effort or money. This is accomplished by analysing a business process and then revising it or cutting out any steps that do not create value for customers. Lean management principles: Defining value from the standpoint of the end customer. Identifying each step in a business process and eliminating those steps that do not create value. Making the value-creating steps occur in tight sequence. Repeating the first three steps on a continuous basis until all waste has been eliminated. | https://www.kanbanchi.com/lean-management |
33 | Microservices | API Gateway | When you divide a big monolithic application into small functional parts that works independently from each other, you need a wrapper around them some sort of Facade such that they behave as a single application to the client. That wrapper is known as API Gateway. It's a one stop shop for the client, anything client wants API Gateway will get it for him. An API gateway is programming that sits in front of an application programming interface (API) and acts as a single point of entry for a defined group of microservices. Because a gateway handles protocol translations, this type of front-end programming is especially useful when clients built with microservices make use of multiple, disparate APIs. | https://whatis.techtarget.com/definition/API-gateway-application-programming-interface-gateway |
34 | OOP | Function Types: A Spectrum | Static functions are the simplest type of function. They can only access their parameters and static variables, which are essentially global and should be extremely few. This is hugely advantageous because we can look at a static function and only have to think about the code we see in front of us. Invoking one means basically just jumping to the memory address of the function’s code, which is known at compile time. They’re as simple and fast as can be. On the downside, static functions are very rigid. They lack all of the tricks offered by the rest of the types we’re about to talk about. Instance functions are slightly more complex. They can access their parameters, static variables, the fields and functions of their class, and the fields and functions of their base classes. Compared to static functions, we must now inspect the rest of the class and the base classes in order to find all of the data and functions the function may access due to the extra this parameter. In the case of an instance function on a class, the compiler automatically generates a check to see if the this parameter is null. If it is, an exception is thrown and the game probably has severe errors as a result. The check also slows down the function call compared to static function calls that never have any checks. That is to say, a null parameter is OK with a static function but only OK with explicit parameters of an instance function on a class. Instance functions are also pretty rigid. They also can’t perform many of the the other types’ tricks, such as being overridden. For that, we’ll need virtual functions… Virtual functions, which includes abstract functions, are a special kind of instance functions. They are called indirectly via a “function pointer.” This is the memory address of the function to call, which isn’t known at compile time. This allows derived classes like Crossbow to overwrite that function pointer in its constructor. The actual function pointer, its initialization, and its overwriting are all invisible. This function pointer, its lookup, and the indirect call based on its address all contribute to slowness compared to non-virtual instance functions and static functions. When we look at Weapon.GetDamage, we can’t know if this version of the function will be called or if a dervied version such as Crossbow.GetDamage will be called. The possibilities grow as more derived classes are added, especially multi-level inheritance that forms a class hierarchy tree. The function call has become stateful because it depends on the type of the object used as this, which may vary at runtime due to polymorphism. Even still, virtual functions lack some of the tricks of even fancier function types… Interface functions are very similar to virtual functions. The major difference is that the interface defines what is essentially an abstract function and is itself essentially an abstract class. One major difference is that classes and structs can “implement” multiple interfaces while classes can only “extend” one class and structs can’t “extend” other structs at all. The complexity growth here comes in two ways. First, its possible to have a variable with an interface type such as IWeapon. When looking at such code, there is no longer a possibility that its implementation of the function is that one that will be called because it doesn’t have an implementation. Instead, we must search elsewhere to try to find the class that implements that interface and is the instance the line of code is going to have when it makes the call. Second, multiple interfaces may have functions with the same name and this will lead to conflicts. Consider IEnumerable and IEnumerable<T>. Both have GetEnumerator but one returns IEnumerator and the other returns IEnumerator<T>. To implement both interfaces, as is common, the ambiguity must be resolved, the syntax is usually found to be particularly tricky, and determining which will be called in which circumstances is complicated. Even at this function type’s level of complexity, we can still go further and implement even more complex kinds of functions. It’s even common to do so! Delegates, often incorrectly called events, are objects that represent functions. GetDamage is a delegate type. It can refer to zero or more functions of any type: static, instance, virtual, interface, and even other delegates! The result is that calling a delegate may call zero functions, one function, multiple functions, or a whole tree of functions due to delegates referring to delegates referring to more delegates. The definitions of these functions is extremely opaque as even the type of function is uknown, let alone the type that declared it. Further, lambdas and anonymous functions are delegates that the compiler generates closures for. | https://jacksondunstan.com/articles/5508 |
35 | OOP | Struct vs Class | Struct cannot have a default constructor (a constructor without parameters) or a destructor. Structs are value types and are copied on assignment. Structs are value types while classes are reference types. Structs can be instantiated without using a new operator. A struct cannot inherit from another struct or class, and it cannot be the base of a class. All structs inherit directly from System.ValueType, which inherits from System.Object. Struct cannot be a base class. So, Struct types cannot abstract and are always implicitly sealed. Abstract and sealed modifiers are not allowed and struct member cannot be protected or protected internals. Function members in a struct cannot be abstract or virtual, and the override modifier is allowed only to the override methods inherited from System.ValueType. Struct does not allow the instance field declarations to include variable initializers. But, static fields of a struct are allowed to include variable initializers. A struct can implement interfaces. | https://www.c-sharpcorner.com/blogs/difference-between-struct-and-class-in-c-sharp |
36 | OOP | Interfaces vs Abstract Class | An Interface defines what something can do (how it behaves), and an Abstract Class defines what something is. Abstract Class can contain implementation of methods, fields, constructors, etc Interface only contains method and property prototypes. A class can implement multiple interfaces, but it can only inherit one class (abstract or otherwise). | https://stackoverflow.com/questions/15178219/whats-the-difference-between-an-abstract-class-and-an-interface |
37 | OOP | OOP | Abstraction in C# is the process to hide the internal details and showing only the functionality. The abstract modifier indicates the incomplete implementation. An abstract class is somewhere between a C# interface and a non-abstract class. Of the public members defined by an abstract class, any number of those members may include an implementation. | https://en.wikibooks.org/wiki/C_Sharp_Programming/Abstract_classes |
38 | OOP | Polymorphism | Polymorphism is a concept in object-oriented programming that refers to the ability of a single interface to be used to refer to multiple implementations of a particular behavior. In C#, polymorphism can be achieved through inheritance, interfaces, and virtual methods. | https://medium.com/@CodeWithHonor/c-polymorphism-91b5b348c19f#:~:text=Polymorphism%20is%20a%20concept%20in%20object%2Doriented%20programming%20that%20refers,%2C%20interfaces%2C%20and%20virtual%20methods. |
39 | Programming Languages | Dynamic & Static typing | Static typing: Variables have types, values have types, variable cannot change types Dynamic typing: Variable have no types, values have types, variables change type dynamically Strongly typing: Its type system allows all type error in programs to be detected, either at compile time or at runtime. Weak typing: The language allows automatic type conversions with the proviso that there may be some loss of information. | http://techtales.co/2017/09/05/dynamic-typing-vs-static-typing-mean/ |
40 | Programming Languages | Android - aar vs jar | AAR files are more similar to Jars than to Dlls for the following reason: Dlls can be shared across applications where as AARs and jars are packaged in with your app. AARs vs Jars: The main difference between a Jar and a AAR is that AARs include resources such as layouts, drawables etc. This makes it a lot easier to create self-contained visual components. For example if you have multiple apps that use the same login screen, with Jars you could share classes but not the layout, styles, etc., you still had to duplicate them. With AARs everything is bundled in one neat package. In conclusion, AARs are a big step in the right direction. | https://stackoverflow.com/questions/23915619/android-archive-library-aar-vs-standard-jar |
41 | Programming Languages | Uber-Jar | An uber-JAR—also known as a fat JAR or JAR with dependencies—is a JAR file that contains not only a Java program, but embeds its dependencies as well. This means that the JAR functions as an "all-in-one" distribution of the software, without needing any other Java code. (You still need a Java runtime, and an underlying operating system, of course.) | https://imagej.net/Uber-JAR |
42 | Programming paradigms | Paradigms definitions | - imperative which allows side effects: a) object-oriented which groups code together with the state the code modifies, b) procedural which groups code into functions, - declarative which does not state the order in which operations execute: a) functional which disallows side effects, b) logic which has a particular style of execution model coupled to a particular style of syntax and grammar, and - symbolic programming which has a particular style of syntax and grammar. | https://en.wikipedia.org/wiki/Programming_paradigm |
43 | Programming paradigms | Imperative paradigm | Imperative programming is a paradigm of computer programming in which the program describes a sequence of steps that change the state of the computer. Unlike declarative programming, which describes "what" a program should accomplish, imperative programming explicitly tells the computer "how" to accomplish it. Programs written this way often compile to binary executables that run more efficiently since all CPU instructions are themselves imperative statements. | https://www.computerhope.com/jargon/i/imp-programming.htm |
44 | Programming paradigms | Declarative paradigm | Declarative programming consists of instructing a program on what needs to be done, instead of telling it how to do it. In practice, this approach entails providing a domain-specific language (DSL) for expressing what the user wants, and shielding them from the low-level constructs (loops, conditionals, assignments) that materialize the desired end state. | https://www.toptal.com/software/declarative-programming |
45 | Reactive | Schedulers | Schedulers.io() is backed by an unbounded thread pool. It is used for non CPU-intensive I/O type work including interaction with the file system, performing network calls, database interactions, etc. This thread pool is intended to be used for asynchronously performing blocking IO. Schedulers.computation() is backed by a bounded thread pool with size up to the number of available processors. It is used for computational or CPU-intensive work such as resizing images, processing large data sets, etc. Be careful: when you allocate more computation threads than available cores, performance will degrade due to context switching and thread creation overhead as threads vie for processors’ time. Schedulers.newThread() creates a new thread for each unit of work scheduled. This scheduler is expensive as new thread is spawned every time and no reuse happens. Schedulers.mainThread() (also known as UI thread) is where user interaction happens. Care should be taken not to overload this thread to prevent janky non-responsive UI. | https://proandroiddev.com/understanding-rxjava-subscribeon-and-observeon-744b0c6a41ea |
46 | Reactive | SubscriveOn and ObserveOn | subscribeOn affects upstream operators (operators above the subscribeOn) observeOn affects downstream operators (operators below the observeOn) | https://proandroiddev.com/understanding-rxjava-subscribeon-and-observeon-744b0c6a41ea |
47 | Reactive Systems | Definition | Systems built as Reactive Systems are more flexible, loosely-coupled and scalable. This makes them easier to develop and amenable to change. They are significantly more tolerant of failure and when failure does occur they meet it with elegance rather than disaster. Reactive Systems are highly responsive, giving users effective interactive feedback. Responsive: The system responds in a timely manner if at all possible. Responsiveness is the cornerstone of usability and utility, but more than that, responsiveness means that problems may be detected quickly and dealt with effectively. Resilient: The system stays responsive in the face of failure. This applies not only to highly-available, mission-critical systems — any system that is not resilient will be unresponsive after a failure. Resilience is achieved by replication, containment, isolation and delegation. Elastic: The system stays responsive under varying workload. Reactive Systems can react to changes in the input rate by increasing or decreasing the resources allocated to service these inputs. Message Driven: Reactive Systems rely on asynchronous message-passing to establish a boundary between components that ensures loose coupling, isolation and location transparency. | https://www.reactivemanifesto.org/ |
48 | Refactoring | Types of refactoring | Treat refactoring as a regular part of your work Yuck: You find something not right and ugly, and try to fix it (despite if it works) "Boy's scout rule". At least a small improvement every time, becomes a big improvement. Comprehension refactoring: You can't understand something. It's in your head but it's fragile, in x time it will disappear. Preparatory: When you start thinking that a functionality should have been done in another way. Planned: The team assigns time for refactoring in their schedule. Good teams will never do this because they refactor all the time as part of their regular work. Long-term: If you have a big code to refactor, do not make the planned refactoring. Think where you want to go and do small changes with the new goal in mind. | https://www.youtube.com/watch?v=vqEg37e4Mkw |
49 | Refactoring | Definition | By Martin Fowler: A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its existing behaviour. Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations, each of which "too small to be worth doing". However the cumulative effect of each of these transformations is quite significant. By doing them in small steps you reduce the risk of introducing errors. You also avoid having the system broken while you are carrying out the restructuring - which allows you to gradually refactor a system over an extended period of time. | https://martinfowler.com/books/refactoring.html |
50 | Refactoring | Parallel change | Parallel change, also known as expand and contract, is a pattern to implement backward-incompatible changes to an interface in a safe manner, by breaking the change into three distinct phases: expand, migrate, and contract. In the expand phase you augment the interface to support both the old and the new versions. During the migrate phase you update all clients using the old version to the new version. This can be done incrementally and, in the case of external clients, this will be the longest phase. Once all usages have been migrated to the new version, you perform the contract phase to remove the old version and change the interface so that it only supports the new version. | https://martinfowler.com/bliki/ParallelChange.html |
51 | Software architectures | Definition | In simple words, software architecture is the process of converting software characteristics such as flexibility, scalability, feasibility, reusability, and security into a structured solution that meets the technical and the business expectations. This definition leads us to ask about the characteristics of a software that can affect a software architecture design. There is a long list of characteristics which mainly represent the business or the operational requirements, in addition to the technical requirements. | https://codeburst.io/software-architecture-the-difference-between-architecture-and-design-7936abdd5830 |
52 | Software architectures | Principles | For software architecture, the principles of stability and usefulness represent system resiliency and life cycle, and they are closely related to how the architecture withstands and enables changes over time. The principle of beauty arises when the architecture is in harmony with its surroundings, and with no unnecessary clutter and complexity. A flexible software architecture is able to adapt to changes in both environment and usability requirements without encompassing structural changes. It is also free of rigid structures that otherwise would obstruct functional evolution and growth. | https://medium.com/devopslinks/flexibility-a-software-architecture-principle-6eafe045a1d4 |
53 | Software architectures | GUI Architectures | MVP: the view is in charge. The view, in most cases, creates its presenter. The presenter will interact with the model and manipulate the view through an interface. The view will sometimes interact with the presenter, usually through some interface. This comes down to implementation; do you want the view to call methods on the presenter or do you want the view to have events the presenter listens to? It boils down to this: The view knows about the presenter. The view delegates to the presenter. MVC: the controller is in charge. The controller is created or accessed based on some event/request. The controller then creates the appropriate view and interacts with the model to further configure the view. It boils down to: the controller creates and manages the view; the view is slave to the controller. The view does not know about the controller. | https://www.techyourchance.com/mvp-mvc-android-1/ |
54 | Software architectures | Monolithic | Monolithic, in this context, means composed all in one piece. Monolithic software is designed to be self-contained; components of the program are interconnected and interdependent rather than loosely coupled as is the case with modular software programs. In a tightly-coupled architecture, each component and its associated components must be present in order for code to be executed or compiled. Furthermore, if any program component must be updated, the whole application has to be rewritten. However, there are benefits to monolithic architectures as well. Monolithic programs typically have better throughput than modular approaches, such as the microservice architecture (MSA) and they can be easier to test and debug because, with fewer elements there are fewer variables that come into play. | https://microservices.io/patterns/monolithic.html |
55 | Software architectures | Microservices pattern | Define an architecture that structures the application as a set of loosely coupled, collaborating services. Each service implements a set of narrowly, related functions. For example, an application might consist of services such as the order management service, the customer management service etc. Services communicate using either synchronous protocols such as HTTP/REST or asynchronous protocols such as AMQP. Services can be developed and deployed independently of one another. Each service has its own database in order to be decoupled from other services. | https://microservices.io/patterns/microservices.html |
56 | Software delivery | Software delivery performance | Lead Time: the time it takes to go from a customer making a request to being satisfied. Deployment frequency: a single piece flow where each commit can be released to production (continuous deployment) Mean time to restore: how quickly can be restored Change fail percentage: percentage of fail when making changes to systems | Accelerate - The Science of Lean Software and DevOps |
57 | Software delivery | CI & CD & CD | Continuous Integration refers to integrating, building, and testing code within the development environment. Continuous Delivery is the discipline where you build software in such a way that the software can be released to production at any time. Continuous Deployment means that every change goes through the pipeline and automatically gets put into production, resulting in many production deployments every day. | Etermax CI/CD talk |
58 | Software delivery | Values of CI/CD | Create fully automated, repeatable, reliable process for building, deploy and test stages. Reduce cycle time. Receive Feedback as soon as possible. Reduce Risks. Establish Greater Product Confidence. Encourage collaboration, because everything is explicit in a script. Stressless releases. | Etermax CI/CD talk |
59 | Software delivery | Best Practices for CI/CD | Write an extensive test suite Executable code should be the same executable code that is deployed into every environment. Environment configuration should be versioned to easily rollback. Integrate Often. Three Strikes and you Automate | Etermax CI/CD talk |
60 | Software delivery | Branch by abstraction | "Branch by Abstraction" is a technique for making a large-scale change to a software system in gradual way that allows you to release the system regularly while the change is still in-progress. | https://martinfowler.com/bliki/BranchByAbstraction.html |
61 | Software delivery | Continuous delivery | Is a set of capabilities that enable us to get changes of all kinds - features, configuration changes, bug fixes, experiments - into production or into the hands of users safely, quickly and sustainably. In continuous delivery we invest in building a culture supported by tools and people where we can detect any issues quickly, so that they can be fixed straight away when they are cheap to detect and resolve. Key capabilities that drive to CD: Version control Test automation: tests that are reliable, when the tests pass, teams are confident that their software is releasable. Test data management: Successful teams had adequate test data to run their fully automated test suites and could acquire test data for running automated tests on demand. Trunk-based development Information security: Incorporate information security into the delivery process. Continuous integration | Accelerate - The Science of Lean Software and DevOps |
62 | Software delivery | Continuous deployment | a single-piece flow where each commit can be released to production. | Accelerate - The Science of Lean Software and DevOps |
63 | Software delivery | Continuous integration | Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly | Etermax CI/CD talk |
64 | Software delivery | Canary release | Canary release is a technique to reduce the risk of introducing a new software version in production by slowly rolling out the change to a small subset of users before rolling it out to the entire infrastructure and making it available to everybody. You start by deploying the new version of your software to a subset of your infrastructure, to which no users are routed. When you are happy with the new version, you can start routing a few selected users to it. | https://martinfowler.com/bliki/CanaryRelease.html |
65 | Software delivery | Docker - Functionality | Makes easier to create, deploy and run apps by using container. A container has all the app and its dependencies and libraries. Build: creates new images Run: initialize the container Pull: download image | |
66 | Software delivery | High availability | In computing, the term availability is used to describe the period of time when a service is available, as well as the time required by a system to respond to a request made by a user. High availability is a quality of a system or component that assures a high level of operational performance for a given period of time. | https://www.digitalocean.com/community/tutorials/what-is-high-availability |
67 | Software development | Versioning | Major: API is no more backward compatibility. 1.2.7 -> 2.0.0 Minor: New feature with backward compatibility. 1.2.7 -> 1.3.0 Patch: Fix without adding new functionality. 1.2.7 -> 1.2.8 | |
68 | Software development | Commands | In a method called CreateUser, uncle bob prefers to throw an exception an not an optional because it's a command. As it's a command, it shouldn't return an optional because if not you will be using the null to check. | LondonVsChicago EP 01 |
69 | Software development | Ineffective Habits | - Noise code: simple things done with long and/or complex code. - Comments: If code is clear, is self explained. Comments aren't checked by the compiler, so there is no guarantee they are right. They clutter code. - Indentation. - Naming exceptions: e.g. AccessViolationException - BadImageFormatException. - Getters and setters. | https://www.youtube.com/watch?v=ZsHMHukIlJY |
70 | Software development | Excellent teams | An excellent team has this properties: ask for help, value tech skill, integrity, no toxic people, home for the evening, learning > blame, share knowledge | https://www.youtube.com/watch?v=Avs70dZ3Vlk |
71 | Software development | Stop learning frameworks | Technology come and go, but it has a lot in common. Set priorities right. Invest 80% of your learning time in fundamentals. Leave 20% for frameworks, libraries and tools. The longer a technology is on the market, the safer investment it is. Don't rush to learn new technology – it has a high probability of dying. Time will show which technology is worth investing in. Time is your best advisor. Learn to wait. | https://sizovs.net/2018/12/17/stop-learning-frameworks/ |
72 | Software development | Proxy | A proxy, in its most general form, is a class functioning as an interface to something else. The proxy could interface to anything: a network connection, a large object in memory, a file, or some other resource that is expensive or impossible to duplicate. In short, a proxy is a wrapper or agent object that is being called by the client to access the real serving object behind the scenes. Use of the proxy can simply be forwarding to the real object, or can provide additional logic. In the proxy, extra functionality can be provided, for example caching when operations on the real object are resource intensive, or checking preconditions before operations on the real object are invoked. For the client, usage of a proxy object is similar to using the real object, because both implement the same interface. | https://en.wikipedia.org/wiki/Proxy_pattern |
73 | Software development | The importance of readability | When reading someone's else's poorly named methods, classes, variables, you spend much more time decrypting the code that writing new functional. But it shouldn't be that way, and there is no excuse in writing such way. Average developer spends 75% of the time understanding code, 20% of the time modifying existing code and only 5% writing new (source). A slight additional time of a single developer spent on readability reduces the understanding time for teammates. This practice becomes important when the application size grows, since the understanding time increases with complexity. Reading meaningful code is easy. Nevertheless writing meaningful code is opposite: you have to learn clean code practices and put constant effort to express yourself clearly. | https://dmitripavlutin.com/coding-like-shakespeare-practical-function-naming-conventions/ |
74 | Software development | Containers | Containerization is increasingly popular because containers are: Flexible: Even the most complex applications can be containerized. Lightweight: Containers leverage and share the host kernel. Interchangeable: You can deploy updates and upgrades on-the-fly. Portable: You can build locally, deploy to the cloud, and run anywhere. Scalable: You can increase and automatically distribute container replicas. Stackable: You can stack services vertically and on-the-fly. | https://docs.docker.com/get-started/ |
75 | Software development | Clean code - definitions | Uncle bob asked to this guys: What is clean code? Bjarne Stroustrup (c++ creator): I like my code to be elegant and efficient. CC does one thing well. Grady Booch (UML creator): When code is simple and direct. CC reads like well written prose. Michael C. Feathers: CC always looks like it was written by someone who cares. Ward Cunningham (wiki creator): You know you are working on CC when each routine you read turn out to be pretty much you expected. | https://www.youtube.com/watch?v=SVRiktFlWxI |
76 | Software development | Clean code | Your code should be elegant: Your code should make you smile the way a well-crafted music box or well-designed car would. Your code has been taken care of: Someone has taken the time to keep it simple and orderly. They have paid appropriate attention to details. They have cared. Your code has to be focused: Each function, each class, each module exposes a single-minded attitude that remains entirely undistracted, and unpolluted, by the surrounding details. Contains no duplication Runs all the tests Minimize the number of entities such as classes, methods, functions, and the like. One difference between a smart programmer and a professional programmer is that the professional understands that clarity is king. Professionals use their powers for good and write code that others can understand. — Robert C. Martin | https://medium.com/mindorks/understanding-clean-code-in-android-ebe42ad89a99 |
77 | Software development | Clean code - Functions | First rule -> Functions should be small Second rule -> Function should be smaller than that. A function name should clearly indicate what the function does. You don't have to scroll around, open the function source code to understand how it works. Avoid same name for different things: initialize(), configure(), init(), start()... Avoid pointless function names / Avoid stupid function names: foo(), bar(), myFun(), test(), sarasa() Avoid same name covering many concepts For example an application has in different classes a method named get(). Having the same name, these methods do different things: fetches data from server httpService.get(), gets the wrapped object wrapper.get() or initialize and get a storage instance Storage.get(). Avoid same concept covered by many names: remove(), delete(), eliminate() Don't say one thing and do another Problems with long functions (scope) - Hard to read and remember - Hard to test and debug - Conceal business rules - Hard to reuse and lead to duplication - Have a higher probability to change - Can’t be optimized - Obsolete comments | https://dmitripavlutin.com/coding-like-shakespeare-practical-function-naming-conventions/ |
78 | Software development | Command Query Separation | Queries: Return a result and do not change the observable state of the system (are free of side effects). Commands: Change the state of a system but do not return a value. The really valuable idea in this principle is that it's extremely handy if you can clearly separate methods that change state from those that don't. This is because you can use queries in many situations with much more confidence, introducing them anywhere, changing their order. You have to be more careful with modifiers. | https://martinfowler.com/bliki/CommandQuerySeparation.html |
79 | Software development | Is High Quality Software Worth the Cost? | High quality software is cheaper to produce because - Neglecting internal quality leads to rapid build up of cruft - This cruft slows down feature development - Even a great team produces cruft, but by keeping internal quality high, is able to keep it under control - High internal quality keeps cruft to a minimum, allowing a team to add features with less effort, time, and cost. | https://martinfowler.com/articles/is-quality-worth-cost.html |
80 | Software development principles | Premature optimization | Optimization is a very right and necessary process that allows you to speed up the work of the program, as well as reduce the consumption of system resources. But everything has its time. If optimization is carried out in the early stages of development, then it can do more harm than good. This is primarily due to the fact that the development of optimized code requires more time and effort of the developer and it may be more complex. In this case, quite often it is necessary to first verify the correctness of the chosen development approach. Therefore, at first, it is more profitable to use simple, but not the most optimal solutions. And in the future, assessing how much this application slows down the work of the application, perform the change to a faster or less resource-intensive algorithm. In addition, for the time while you initially implement the most optimal algorithm, the requirements may change and the code will go to the garbage. So no need to spend time on premature optimization. | |
81 | Software development principles | Occam’s Razor | No need to create extra entities without the need for them. So, you always need to think first about the benefits of adding one more method/class/tool/process/etc. After all, if you add one more method/class/tool/process/etc and don't get any benefits but increasing complexity then what's the point? | https://michaellant.com/2010/08/10/occams-razor-and-the-art-of-software-design/ |
82 | Software development principles | KISS | The "keep it simple stupid" (KISS) principle is a design rule that states that systems perform best when they have simple designs rather than complex ones. | |
83 | Software development principles | Tell don't ask | Tell-Don't-Ask is a principle that helps people remember that object-orientation is about bundling data with the functions that operate on that data. It reminds us that rather than asking an object for data and acting on that data, we should instead tell an object what to do. This encourages to move behavior into an object to go with the data. | https://martinfowler.com/bliki/TellDontAsk.html |
84 | Software development principles | Law of demeter | The fundamental notion is that a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents), in accordance with the principle of "information hiding". It may be viewed as a corollary to the principle of least privilege, which dictates that a module possess only the information and resources necessary for its legitimate purpose. The Law of Demeter for functions requires that a method m of an object O may only invoke the methods of the following kinds of objects: - O itself - m's parameters - Any objects created/instantiated within m - O's direct component objects - A global variable, accessible by O, in the scope of m | https://en.wikipedia.org/wiki/Law_of_Demeter |
85 | Software development principles | SOLID | Single Responsibility Principle A class should be responsible for only one thing. If a class has more than one responsibility, it becomes coupled. A change to one responsibility results to modification of the other responsibility. Open-Closed Principle Software entities(Classes, modules, functions) should be open for extension, not modification. Liskov Substitution Principle A sub-class must be substitutable for its super-class Interface Segregation Principle Make fine grained interfaces that are client specific Clients should not be forced to depend upon interfaces that they do not use. Dependency Inversion Principle Dependency should be on abstractions not concretions A. High-level modules should not depend upon low-level modules. Both should depend upon abstractions. B. Abstractions should not depend on details. Details should depend upon abstractions. | https://www.oodesign.com/design-principles.html https://blog.bitsrc.io/solid-principles-every-developer-should-know-b3bfa96bb688 |
86 | Software development principles | DRY | "Don't repeat yourself". Aimed at reducing repetition of information. The DRY principle is stated as, "Every piece of knowledge or logic must have a single, unambiguous representation within a system." | https://dzone.com/articles/software-design-principles-dry-and-kiss |
87 | Software development principles | Big Design Up Front | Big Design Up Front (BDUF) is a software development approach in which the program's design is to be completed and perfected before that program's implementation is started. It is often associated with the waterfall model of software development. | https://en.wikipedia.org/wiki/Big_Design_Up_Front |
88 | Software development principles | Principle Of Least Astonishment | This principle means that your code should be intuitive and obvious, and not surprise another developer during code review. Example, if the method called "make cookies", but as a result, you get a potato than this code is bad(obviously). | https://softwareengineering.stackexchange.com/questions/187457/what-is-the-principle-of-least-astonishment |
89 | Software development principles | YAGNI | "You Aren't Gonna Need It". It's a statement that some capability we presume our software needs in the future should not be built now because "you aren't gonna need it". “Always implement things when you actually need them, never when you just foresee that you may need them.” | https://martinfowler.com/bliki/Yagni.html |
90 | Software development techniques | Mob programming | Mob Programming is where the whole team — and that includes tester, product owner, and designer — work together on one task at the same time on the same computer. Whenever possible, avoid doing things separately. If one stops, everybody stops. Ask questions as early as possible if it looks like you lost the context. | https://hackernoon.com/how-mob-programming-will-make-you-more-effective-590a1b7e0418 |
91 | Software development techniques | Pair programming | All code to be sent into production is created by two people working together at a single computer. Pair programming increases software quality without impacting time to deliver. It is counter intuitive, but 2 people working at a single computer will add as much functionality as two working separately except that it will be much higher in quality. With increased quality comes big savings later in the project. The best way to pair program is to just sit side by side in front of the monitor. Slide the key board and mouse back and forth. Both programmers concentrate on the code being written. Pair programming is a social skill that takes time to learn. You are striving for a cooperative way to work that includes give and take from both partners regardless of corporate status. The best pair programmers know when to say "let's try your idea first." Don't expect people to be good at it from the start. It helps if you have someone on your team with experience to show everyone what it should feel like. One thing pair programming is not is mentoring. A teacher-stundent relationship feels very different from two people working together as equals even if one has significantly more experience. It takes time to get used to pair programming so don't worry if it feels awkward at first. XP Rules | http://www.extremeprogramming.org/rules/pair.html |
92 | Software development techniques | Promiscuous pairing and beginners mind | What is to have a beginner's mind? It refers to having an attitude of openness, eagerness, and to lack preconceptions when studying a subject, even when at an advanced level, just as a beginner would do. It must be remarked that this is a transitory state, and that you may rapidly exit the 'beginner's mind'. This is why Arlo and his team wanted to find out how to stay longer in this state. Promiscuous means to change partners quickly. So what Arlo tries to convey with this concept is the idea of swapping peers more frequently than usual while pair programming, even before finishing the given task. While you're pair programming there is a transfer of knowledge between peers, so after switching pairs, knowledge is transferred around all participants. The author states that, generally, the most important information is transferred at the beginning. It could be anything: from using something from the IDE, or a TDD technique, or even about the language used. If we, programmers, could achieve this state of beginner's mind, we should be able to code better. The problem is that, as I said before, this is a temporary state. As soon as you know what you are doing and you get involved for a time, you are no longer in that state. | https://medium.com/p/817dc152dfff/edit |
93 | TDD | Explained | TDD can be defined as a programming practice that instructs developers to write new code only if an automated test has failed. This avoids duplication of code. TDD means “Test Driven Development”. The primary goal of TDD is to make the code clearer, simple and bug-free. Test-Driven Development starts with designing and developing tests for every small functionality of an application. In TDD approach, first, the test is developed which specifies and validates what the code will do. In the normal Software Testing process, we first generate the code and then test. Tests might fail since tests are developed even before the development. In order to pass the test, the development team has to develop and refactors the code. Refactoring a code means changing some code without affecting its behavior. The simple concept of TDD is to write and correct the failed tests before writing new code (before development). This helps to avoid duplication of code as we write a small amount of code at a time in order to pass tests. (Tests are nothing but requirement conditions that we need to test to fulfill them). | https://www.guru99.com/test-driven-development.html |
94 | TDD | Mockist vs Classicist | The classical TDD style is to use real objects if possible and a double if it's awkward to use the real thing. So a classical TDDer would use a real warehouse and a double for the mail service. The kind of double doesn't really matter that much. This style of testing uses state verification: which means that we determine whether the exercised method worked correctly by examining the state of the SUT and its collaborators after the method was exercised. As we'll see, mock objects enable a different approach to verification. A mockist TDD practitioner, however, will always use a mock for any object with interesting behavior. In this case for both the warehouse and the mail service. Mocks use behavior verification, where we instead check to see if the order made the correct calls on the warehouse. We do this check by telling the mock what to expect during setup and asking the mock to verify itself during verification. Only the order is checked using asserts, and if the method doesn't change the state of the order there's no asserts at all. Mocking is not about testing, is about designing the collaboration between classes (LondonVsChicago EP 01) | https://martinfowler.com/articles/mocksArentStubs.html |
95 | TDD | Why TDD | - Fast feedback if code is not behaving as expected: this is good for debugging, and reduces the cost of defects. - They can be a form of documentation, because nobody ever updates actual documentation. - They can often encourage better design principles, as untestable code is often bad code. - To ensure that any changes we make don’t accidentally alter the functionality of the existing codebase. - We can work on refactors (both big and small ones) in the code without fear of causing bugs - It helps us detect if there is too much coupling in our code (why was it necessary to modify the classes in feature A to add a behaviour to feature B?) | |
96 | TDD | Type of tests | Unit tests: Drives the architecture. Acceptance Tests: Behaviour. Guarantees that has the behaviour expected for the outer world. | LondonVsChicago EP 02 |
97 | TDD | Test doubles types | Test Double as the generic term for any kind of pretend object used in place of a real object for testing purposes. Types of test doubles - Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists. Is just an object that you pass to satisfy a constructor, it will not have any method implemented and it shouldn’t. - Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. They still don’t have any logic but they will not throw an error, instead they return a pre-defined value. - Mocks objects pre-programmed with expectations which form a specification of the calls they are expected to receive. They are used to verify the behaviour between the System Under Test and its collaborators. You set your expectations, call the method of the SUT and verify if the method was called at the end. - Spies are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent. You use spies when you are not really sure about what your SUT will call from your collaborator, so you record everything and assert if the spy called the desired data. - Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example). Fakes are different from all the other examples that we had, instead of canned responses or just recording calls, they have a simplified version of the business logic. An example of a Fake would be a InMemory repository where we have the logic to store, retrieve and even do some queries, but it won’t have a real database behind, in fact everything can be stored in a list, or you can fake a external service like an API. | https://martinfowler.com/articles/mocksArentStubs.html https://codurance.com/2019/04/08/Introduction-to-test-doubles/ |
98 | TDD | test && commit || revert | If the tests fail, then the code goes back to the state where the tests last passed. - Add test and pass. The goal here is to shorten the time between idea and some kind of test passing in some kind of way. Even writing part of the test is fine. Cheating is encouraged, as long as you don’t stop there. - Better passing. Once you have a test passing, replace the fake implementation with a real implementation, a little at a time if necessary. - Make hard changes easy. Rather than change four places in the code, introduce a helper function (a little at a time, natch) so you can change one place. Violating any of these strategies results in the changes being instantly reverted, so you don't have to worry about enforcing small diffs. | https://medium.com/@kentbeck_7670/test-commit-revert-870bbd756864 |
99 | TDD | Purpose of tests - Mark seemann | At first glance, that may seem like an inane question, but there's actually more than one purpose of a unit test. When doing TDD, the purpose of a test is to provide feedback about the API you're developing. A unit test is the first client of the production API. If a test is difficult to write, the production API is difficult to use. You may say that another purpose of automated tests is that they prevent errors. That's not the case, though. Automated tests prevent regressions. If you wrote the correct test, your test suite may also help to prevent errors, but a unit test is only as good as the programmer who wrote it. You could have made a mistake when you wrote the test. Or perhaps you misunderstood the specification of what you were trying to implement. Why do you even trust tests? | |
100 | TDD | ATDD | Analogous to test-driven development, Acceptance Test Driven Development (ATDD) involves team members with different perspectives (customer, development, testing) collaborating to write acceptance tests in advance of implementing the corresponding functionality. The collaborative discussions that occur to generate the acceptance test is often referred to as the three amigos, representing the three perspectives of customer (what problem are we trying to solve?), development (how might we solve this problem?), and testing (what about...). These acceptance tests represent the user's point of view and act as a form of requirements to describe how the system will function, as well as serve as a way of verifying that the system functions as intended. In some cases the team automates the acceptance tests. | https://www.agilealliance.org/glossary/atdd/#q=~(infinite~false~filters~(postType~(~'page~'post~'aa_book~'aa_event_session~'aa_experience_report~'aa_glossary~'aa_research_paper~'aa_video)~tags~(~'acceptance*20test~'atdd))~searchTerm~'~sort~false~sortDirection~'asc~page~1) |