Chasing the Trunk Based Development

A source-control branching model, where developers collaborate on code in a single branch called trunk, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after..

Release branch is typically a snapshot from trunk with an optional number of cherry picks that are developed on trunk and then pulled into the branch.

The Liskov Substitution Principle (LSP) flashback

Violations of the Liskov Substitution principle make your code behavior unexpected, therefore hard predictable & bad maintainable...

Liskov Substitution Principle

Subtypes must be behaviorally substitutable for their base types - official formulation
That is, if S is a subtype of T, then objects of type T in a program P may be replaced with objects of type S without altering any of the desirable properties(correctness) of that program P.

---

Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. - general form
It means that we must ensure that new derived classes extend the base classes without changing ancestor's behavior.

---

Child classes should never break the parent class’ type definitions - simplified interpretation
Otherwords, Subclass should override the parent class’ methods in a way that does not break functionality from a client’s point of view.

The Law of Demeter (LoD) flashback

Violations of the Law of Demeter make your code unreadable, hard understandable, overcrowded with extra dependencies and bad scalable...

Low of Demeter

Each unit should have only limited knowledge about other units: only units "closely" related to the current unit
- general formulation

---

Don't talk to strangers! - short form of law
Means each unit should talk only to its friends.

---

Use only one dot. - simplified form
This is the tricky one: It's only in common, don't confuse when using 'builders', 'factoryMethods', etc.

Java: Forget About JSP

I hope that you already have forgotten about JSF (JavaServer Faces) :)
Not long time ago, all feeds were overloaded by post about, why everyone has to stop using JSF. However JSP (JavaServer Pages) is usually a kind of pain in ass for developers as well, because it's badly readable, not reusable, different from html syntax, not obvious, coupled, etc.

So, here is a better way, that should be chosen in favour of JSP:

Themeleaf

Thymeleaf is a Java library. It is a template engine capable of processing and generating HTML, XML, JavaScript, CSS and text, and can work both in web and non-web environments. It is better suited for serving the view layer of web applications, but it can process files in many formats, even in offline environments.

It provides an optional module for integration with Spring MVC, so that you can use it as a complete substitute of JSP in your applications made with this technology, even with HTML5.

As mentioned above, Thymeleaf is well integrated with Spring and allows more intuitive way to handle views part, which makes it's quite easy usable & useful especially for small fast projects.

Fail-Fast instead of Fire-and-Forget

Fail-Fast

fail-safe, fail-fast, fire-and-forget

Fail Fast means, when something goes wrong, you must show an error as soon as possible, so that you can take an action to solve the problem.

With fire-and-forget (when you have no any response) there is nothing you can do, when something went wrong.

Here is few points to follow fail-fast behavior:

• assertions;
• meaningful exceptions;
• response for each request.

Storing created & last updated properties

Created & Last Updated properties

Whenever u're dealing with some accounts, transactions, product items, notes, reviews, etc. it's always useful to know when those where created & last updated/edited/modified.

Notice, that it's always better to fill such properties on the Back-End side rather than on the Front-End. Otherwise, the client can exchange the data & try to store some invalid values. Actually even if the client will send the valid dates, those will not reflect exact time when the data was added in the DB.

Parallel Processing Access Patterns

Parallel processing refers to the structure when a single program is running by multiple CPU cores at the same time. Depending on what the program does and how it works, this could lead to massive gains in speed. Especially if computation tasks could be separated & executed in not blocking way. *(like with java `ForkJoinPool` approach)* Writing the programs to run in parallel requires different thought processes than sequential programming.The first thing to do is to figure out what exactly can be separated & parallelized. If 1st part of the program depends on the results of 2nd part, then the first part should guarantee *happens-before* relation to the 2nd one. On the other hand, most programs have large sections that can run without reference to one another and then their outputs can be combined.

SOLID principles in Real World

S.O.L.I.D

This abbreviation supposed to give you an opportunity to keep in mind 5  main design principles,that you have to use while writing your App  classes.

• Single Responsibility Principle (SRP).
• Open/Closed Principle (OCP). 
• Liskov's Substitution Principle (LSP).
• Interface Segregation Principle (ISP).
• Dependency Inversion Principle (DIP).

TDD. The tip of iceberg.

...write unit tests before the writing production code.

Three Laws of TDD (R.C. Martin)

• You may not write production code until you have written a failing unit test.
• You may not write more of a unit test than is sufficient to fail, and not compiling this failing.
• You may not write more production code than is sufficient to pass the currently failing test.

The tests and the production code are written together, with the tests just a few seconds ahead of the production code.