clean code

https://blog.testlodge.com/what-is-bdd/
https://prezi.com/5lw2osodzhqj/tdd-vs-bdd-vs-ddd/
https://qr.ae/TWrej6
https://stackoverflow.com/questions/184618/
========================================================
https://qr.ae/TWreQR

Get your mind right.
 takes practice and study, over many years
The key is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it,
analyzing your performance while and after doing it, and correcting any mistakes. Then repeat. And repeat again. There appear to be no real shortcuts
10,000 hours ==> 20 per/week ==> 10 years
Programming is a fun
Learning by doing
Talk with other programmers; read other programs
Work on projects with other programmers
Work on projects after other programmers
Learn at least a half dozen programming languages.
how long it takes your computer to execute an instruction
language standardization and coding style
================================================================
Iterate.(Lean Startup)
     how we get to great code and great products
eliminate what doesn’t work as quickly and cheaply as possible.

Most startups fail. But many of those failures are preventable.
The Lean Startup is a new approach being adopted across the globe,
 changing the way companies are built and new products are launched.

=================================================================

Simpler is usually better.

What matters in software is:
does the software do what is supposed to do?
Is it of high quality? Can we rely on it? Can problems be fixed along the way? Can requirements change over time?
The benefits of simplicity are: ease of understanding, ease of change, ease of debugging, flexibility.

XpSimplicityRules by kent beck
ExtremeProgrammers recommend that we DoTheSimplestThingThatCouldPossiblyWork.

UnitTestsTellYouWhenYoureDone, ...
SelfDocumentingCode, ...
OnceAndOnlyOnce, DontRepeatYourself, RedundancyIsInertia, ...
YouArentGonnaNeedIt, MinimumNumberOfClassesAndMethods, ...
=====================================================================
Codes written primarily for coworkers not compiler:

co-workers have a hard time understanding your code, investigate why. Maybe it’s your code that’s too complex
==========================================================================
A problem you perceive is a problem you own.

if you see an inefficiency, a bug, any sort of problem, it’s on you to take action to rectify it.
raise bug , add to bugs database , fix it yourself
Don’t Live with Broken Windows
======================================================================
Don't be clever
Don't try to write complicated code on purpose to show how smart you are.
 Write simple, clear, reusable code. Think Simplicity, Clarity, Generality.
===============================================================================
SRP (single responsibility principle) and DRY (don't repeat yourself) principles
Read "Clean Code" by Uncle Bob Martin (Robert C. Martin)
==================================================================================
You ain't gonna need it (YAGNI) applies most of the time.
 In general, just design for today's requirements, to prevent over engineering.
Code with obviously no bugs is better than code with no obvious bugs.
Being able to reason about your code is paramount to high quality.
==================================================================================
Requirements are rarely cast in stone
As an engineer/programmer, you have a responsibility to question things that look unclear, in doubt and questionable
===================================================================================================================
Start with why
“people don’t buy what you do, they buy why you do it” Simon Sinek'
So any project I work on, I want to know the bigger picture. I want to know the “why”.
When I get deep into a project, I can loose focus Knowing “why’ helps me prioritize, and gives me energy.
“Creators Need an Immediate Connection to What They Create”
“What is your guiding principle? “

================================================================================
Clients don't really know what they want,
and that includes your manager. It's your job to elicit their true needs.
"Domain Driven Design" : System analysis and design based on specific domain
1. Development is iterative. Agile development
2. Developers and domain experts have a close relationship.
Ubiquitous Language :: A language structured around the domain model and used by all team members
Command query responsibility segregation (CQRS) applies the CQS principle by using separate Query and Command objects to retrieve and modify data,
=================================================================================================
Event Sourcing (ES)
An architectural pattern which warrants that your entities (as per Eric Evans’ definition)
do not track their internal state by means of direct serialization or O/R mapping, but by means of reading and committing events to an event store.
the input is a command and the output is one or many events which are transactionally (single commit) saved to an event store,
and then often published on a message broker for the benefit of those interested
(often the views are interested; they are then queried using Query-messages).
---------------------------------------
ES is the idea of storing all the events that happened to an object.
Knowing all the events that happened to a given object, it’s possible to replay those events, to get back to a given state.
It can be seen (at least) as another form of object persistence.
An ORM stores state (and overrides previous state),
while ES stores consequences of object behavior (or behavior itself, depending on how you see it).

CRUD breaks CQS: it should be named CUD + R :)

Compared to the simpler CRUD approach, a DDD one will result in a far richer usage of verbs and events

It’s the idea to separate read from writes.
CQS is a really simple concept that can be implemented by having write-only methods (returning void),
and read-only methods that don’t modify any state, just querying and returning data.

CQRS goes a step further by saying these two separate parts should be segregated in two separate models (or APIs).

==============================================================================================
Don't treat patterns as a hammer looking for a nail.
None of them. All of them.
People noticed that programmers seemed to be approaching problems in similar ways in a bunch of different applications,
and they decided that it would be pretty useful to be able to talk about those approaches using a common vocabulary
so they wouldn't have to keep explaining what they were referring to

a skilled programmer should read a lot of other people's code and figure out what's good about it.
 If a bunch of smart people are solving a certain class of problem in a certain way,
 you should understand why they're doing it that way,
==============================================================
SOLID principles
===========================
Beware of dogma :عقيدة
 There's usually more than one way of doing things. The term "best practice" is overused. instead of Good practice
=========================================================================
No one has it all figured out.
Some know more than others. Always try to be the worst member in the band. Read "The Passionate Programmer"
You'll learn how to build your software development career step by step,
following the same path that you would follow if you were building, marketing, and selling a product.
 After all, your skills themselves are a product.
=================================================================
https://www.infoq.com/ Watch Barbara Liskov's talk "The Power of Abstraction"
. If your are struggling with naming things, perhaps you don’t have the right abstraction.
The worst abstraction I’ve ever seen is was a Java class called BeanFacade.

================================================================================
There's no such thing as perfect. You can always be better. "The perfect is the enemy of the good" - Voltaire.
design for large scale , security
=============================================================================
You are not your code. Criticism of your code isn't a criticism of you.
=====================================================
Remember, it's a team sport  ==> TheTableGroup channel
===============================================
Don't go dark. Share your unfinished work with others willingly
===============================================================
Test your work. Try writing tests before code. Try TDD. Try BDD.
====================================================
Learn multiple paradigms. OOP, Functional, etc.
========================================================
Never stop learning. Read as many books as you can, but not only technical books
==============================================================
Don't ask permission to refactor, test, document etc. It's all part of "programming". Don't ask permission to do your job.

Care about your work. Care about your customers. The code we write allows the users of our code to get their shit done
, without our software getting in their way
==========================================================
Always ask "what problem am I trying to solve"? This is such a great question to ask to gain clarity on what it is exactly that you are doing.
It helps you focus. This ties in nicely with Simon Sinke’s “Start With Why”.


In general, stick to solving one problem at a time. When you spot other problems, note them and come back to them later
=================================================================

Be where you're at. This is a life lesson that applies to software development.
When you commit to doing something, focus on doing it. When your washing the dishes focus on washing the dishes -
forget all the things that stressed you out that day
When you're in a meeting, participate - focus on the conversation and forget about the work
=======================================================================================
"Premature optimization is the root of all evil"
Ask "what's the simplest thing that can possibly work?"

Be OK with you. You will never know everything - that is impossible.
Keep learning, but don't get caught up on what you don't know
=================================================================
Be humble. Everyone is at different points of learning in their career.
Help others on their path. Ask for help when you need it. Give back to the community.
=============================================================
It's OK to be average
“I am, at best, an average programmer.”
================================================================
Multi-tasking is an illusion. Computers get away with it because they can context switch really fast (most of the time).
 Context switching for us mere mortals has a high cost. Do one thing at a time, and do it well.

9 women can't have a baby in a month. Read "The Mythical Man Month" by Fred Brooks.

There is no spoon. Just a reminder to lighten up a little bit. Have fun.
======================================================================

Jacob Kaplan-Moss, a core contributor to Django, is many things. But he’s not, he insists, an “incredible programmer.