| Code Conventions | guidelines for maintainability |
| Enums | Enumeration members are always public, and no access modifiers can be applied |
| Delegates | Delegates behave like classes and structs. By default, they have internal access when declared directly within a namespace, and private access when nested. |
| Covariance | Enables you to use a more specific type than originally specified. You can assign an instance of IEnumerable<Derived> (IEnumerable(Of Derived) in Visual Basic) to a variable of type IEnumerable<Base>. |
| Contravariance | Enables you to use a more generic (less derived) type than originally specified. You can assign an instance of IEnumerable<Base> (IEnumerable(Of Base) in Visual Basic) to a variable of type IEnumerable<Derived>. |
| Invariance | Means that you can use only the type originally specified; so an invariant generic type parameter is neither covariant nor contravariant. You cannot assign an instance of IEnumerable<Base> (IEnumerable(Of Base) in Visual Basic) to a variable of type IEnumerable<Derived> or vice versa. |
| Implicit | dd the methods / properties etc demanded by the interface directly to the class as public methods |
| Explicit | forces the methods to be exposed only when you are working with the interface directly, and not the underlying implementation, This is preferred in most cases. |
| docstring | In programming, a docstring is a string literal specified in source code that is used, like a comment, to document a specific segment of code. Unlike conventional source code comments, or even specifically formatted comments like docblocks, docstrings are not stripped from the source tree when it is parsed and are retained throughout the runtime of the program. This allows the programmer to inspect these comments at run time, for instance as an interactive help system, or as metadata. |
| Idempotent | an operation, if executed multiple times, the result is the same, no matter what |
| state | every single piece of data in your application |
| Code coverage | Code coverage measures what percentage of your code is actually run during testing---helps spot dead zones. |
| Smoke tests | Smoke tests are quick, shallow checks to confirm core functionality works after a build---nothing crashes, basics run. |
| End-to-end tests (e2e) | End-to-end tests run a user scenario from start to finish---like logging in, clicking around, submitting a form---through the full app stack as if a real person did it. |
| Smoke test | (aka Sanity check) A simple integration test where we just check that when the system under test is invoked it returns normally and does not blow up. It is an analogy with electronics, where the first test occurs when powering up a circuit: if it smokes, it's bad. |
| Unit test | Specify and test one point of the contract of single method of a class. This should have a very narrow and well defined scope. Complex dependencies and interactions to the outside world are stubbed or mocked. |
| Integration test | Test the correct inter-operation of multiple subsystems. There is whole spectrum there, from testing integration between two classes, to testing integration with the production environment. |
| Regression test | A test that was written when a bug was fixed. It ensure that this specific bug will not occur again. The full name is "non-regression test". It can also be a test made prior to changing an application to make sure the application provides the same outcome. |
| Acceptance test | Test that a feature or use case is correctly implemented. It is similar to an integration test, but with a focus on the use case to provide rather than on the components involved. |
| System test | Test that tests a system as a black box. Dependencies on other systems are often mocked or stubbed during the test (otherwise it would be more of an integration test). |
| Pre-flight check | Tests that are repeated in a production-like environment, to alleviate the 'builds on my machine' syndrome. Often this is realized by doing an acceptance or smoke test in a production like environment |
| Reactive Programming | Reactive programming is an asynchronous programming paradigm concerned with data streams and the propagation of change |
| Deep learning | |
| Predictive Models | |
| neural networks | |
| monoliths | all of the source code is in the same repository. simple at first, the default for new projects, works for small teams or short-term projects. They become unmanageable |
| multi-repos | The project's source code is kept separate so that each part can be deployed independently. more involved setup. the deployment process could be more complex. Generally fits companies with isolated teams. ex: microservices |
| monorepos | all code is in the same codebase but it is organized to be independent. Used by many large tech companies. organized, ease of deployment |
| Temperature | set to 0 for more predictability. set to .5 for more creativity |
