book reading: 97 Things Every Programmer Should Know (I)

Nov. 15, 2015.

 I like to tell how I get here to read this book - 97 things every programmer should know. It is a long story, but it can be described as this flow:

Julia works on leetcode questions (January 2015) ->
Challenged on August, 2015 about SOLID OO principles (Only know / remember S, basic decoupling, work on interface)
-> procedural code's concern, try to follow DRY principles, Oct. 2015
-> Learn SOLID priciples through videos in Nov., 2015:
-> Recommended reading: the book

Spent 3 hours to read the book on Sunday morning, take some notes about my favorite ideas:

1. Act with prudence - Seb Rose

"doing it right"   vs "doing it quick"

Julia's comment: thinking about it later :-)  Prudence means " be careful".

2. Apply Functional Programming Principles - Edward Garson

Julia's comment:
   Look into the term: "high degree of referential transparency"
   Questions from Julia, list a 3-5 principles of functional programming principles, most popular ones.

3.  Ask, "What Would the User Do?" (You are not the user) - Giles Colborne
Julia's comment:
     Look up the term: the false consensus bias - psychologists call it.

4. Automate your coding Standard - Filip van Laenen

Julia's comment: Look up the meaning of "antipatterns", things talked about are interesting: test coverage, coding standard. Read the article later.

5. Beauty is in simplicity - Jorn Olmheim

Julia's comment: Four things we strive for in our code:
   Readability (1), maintainability (2), speed of development (3), the elusive quality of beauty (4)
Simple objects with a single responsibility, with simple, focused methods with descriptive names.
Desirable goal is to have short methods of 5-10 lines of code. (Julia likes this argument!)

6. Before you refactor - Rajith Attapattu

Julia's comment: great topic, and good to hear some advice.

7. Beware the Share - Udi Dahan

8. The Boy Scout Rule - Robert C. Martin (Uncle Bob)

Julia's favorite: Make it better: improve name of one variable, or split one function into two smaller functions. Or break a circular dependency, or add an interface to decouple policy from detail.

And more about team spirit, help one another and clean up after one another.

9. Check Your Code First before looking to blame others - Allan Kelly
    Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth.
    http://www.allankelly.net/

10. Choose Your tools with Care - Giovanni Asproni
      existing tools - components, libraries, and frameworks
http://www.atlantec.ie/giovanni-asproni-to-be-added/
 
11. Code in the language of the Domain - Dan North
consulting service:
http://dannorth.net/about/

12. Code is Design - Ryan Brush
http://conferences.oreilly.com/strata/stratany2014/public/schedule/speaker/138579

13. Code layout matters - Steve Freeman

Julia is still working on the code layout; she thinks that the good layout helps, her favorite book: the art of readable code

15. Code Reviews - Mattias Karlsson
 Code review - increase code quality and reduce defect rate.

used to be:  Lead programmer does the review, architect reviews everything.

16 Coding with Reason - Yechiel Kimchi

http://programmer.97things.oreilly.com/wiki/index.php/Coding_with_Reason

Julia likes the idea -
1. Try to reason about software correctness by hand
2. Automated tools are preferable but not always possible
3. a middle path - reasoning semiformally about correctness
    Julia likes this middle path, in detail,
   To divide all the code under consideration into short sections - from a single line, such as a function call, to blocks of less than 10 lines - and argue about their correctness.

Julia likes to memorize those good advices, so just write it down word by word.
1. Avoid using goto statements, as they make remote sections highly interdependent.
2. Avoid using modifiable global variables, as they make all sections that use them dependent.
3. Each variable should have the smallest possible scope. For example, a local object can be declared right before its first usage.
4. Make objects immutable when relevant.
5. Make the code readable using spacing, both horizontal and vertical.
6. Make the code self-documenting by choosing descriptive name for objects, types, functions, etc.
7. If you need a nested section, make it a function. <- Julia's favorite: avoid nested section, add a function
8. Make your functions short and focus on a single task. <-  great advice, obey it.
The old 24-line limit still applies. Although screen size and resolution have changed, nothing has changed in human cognition since 1960s. ( 24 lines, Julia can do it! )
9. Function should have few parameters ( four is a good upper bound). This does not restrict the data communicated to functions: Grouping related parameters into a single object benefits from object invariants and saves reasoning, such as their coherence and consistency.

17. Convenience is Not an -ility - Gregor Hohpe

It is a great topic about API design. A good API follows a consistent level of abstraction, exhibits consistency and symmetry, and forms the vocabulary for an expressive language.

API design reading, found one through search:
http://lcsd05.cs.tamu.edu/slides/keynote.pdf

18. Deliberate practice

Leading Lean Software Development (Addison-Wesley Professional)

19. Domain-Specific Languages

https://about.me/mhunger

20 Do not afraid to break things - Mike Lewis

21. Encapsulate Behavior, Not just State - Julia's favorite article

http://www.researchgate.net/profile/Einar_Landre/publications

http://programmer.97things.oreilly.com/wiki/index.php/Encapsulate_Behavior,_not_Just_State

Examples:
  It is easy to find a class with a single 3,000-line main method, or a class with only set and get method for its primitive attributes.
Analysis: do not understand the object-oriented thinking, do not take advantage of the power of objects as modeling constructs.

Given an example, 3 classes: Customer, Order, and Item.
A Customer  object is the natural placeholder for the credit limit and credit validation rules.
An Order object knows about its associated Customer, and its addItem operation delegates the actual credit check by calling customer.ValidateCredit(Item.Price()).

Less experienced OO developer, design one objects: OrderManager or OrderService to wrap all business rules. In the design, Order, Customer, and Item are treated as little more than record types.
All logic is factored out of the classes and tied together in one large, procedural method with a lot of internal if-then-else constructs.

But, these methods are easily broken and almost are impossible to maintain. Because encapsulation is broken.

22. Hard work does not pay off - Olve Maudal

23. Know your limits
http://www.boost.org/doc/libs/1_34_0/people/greg_colvin.htm

24. A message to the Future - Linda Rising

Her website:
http://www.lindarising.org/

Julia really likes the short story written in the chapter. The problem solved is difficult, and the solution should be just as difficult for everyone (maybe even for themselves a few months after the code was written) to understand and maintain. But, the code should be easy to understand.

25. Only the code tells the truth - Peter Sommerlad

https://www.youtube.com/watch?v=XLsZkA77h8c
Notes from video:
Less code = More Software
Let Julia read those sentences and laugh about mistakes she made as well:
1. Complexity is one of the biggest problems with software if not THE biggest.
2. It is much easier to create a complicated "solution" than to really solve a problem.
3. Much software complexity is accidental not inherent to the problem solved.
4. It starts in the small, one statement at a time.
5. Architects and developers need to value Simplicity!
  . Good Abstractions are the key, as are
  . Managing Dependencies (Avoid global variables)
6. Software needs to be simpler to solve more complex problems.
7. Simple software requires work and skill but pays off in the long run.

Famous Quotes by Sir C.A.R. (Tony) Hoare
1. Inside every large problem, there is a small program trying to get out.
2. There are two ways of constructing a software design:
   1. one way is to make it so simple that there are obviously no deficiencies, and
   2. the other way is to make it so complicated that there are no obvious deficiencies.
   The first method is far more difficult.

Good advice:

 1. Strive for good names.
 2. Structure your code with respect to cohesive functionality, which also naming.
 3. Decouple your code to achieve orthogonality.
 4. Write automated tests explaining the intended behavior and check the interfaces.
 5. Refactor mercilessly when you learn how to code a simpler, better solution.
 6. Make your code as simple as possible to read the understand.

- to be continued.

More reading about authors:

1.  Enjoy reading the blog of one of authors:

To junior developer:

http://dearjunior.blogspot.ca/2014/11/make-implicit-concepts-explicit-in-code.html

Note:

Eric Evans, the thought leader of Domain Driven Design.

http://dearjunior.blogspot.ca/2012/03/dry-and-false-negatives.html

OO design principles - DRY - Don't repeat yourself principle

Nov. 14, 2015

It is so great to find something to work on this weekend of November. My favorite time to study the video:

The Don't repeat yourself princple, part 2

https://www.youtube.com/watch?v=wweNdRuM64g&list=PLD4GnSXHpkQ2_eKG5fKzszXs5hYcEsft7&index=2

Video time: 30:15/31:07
Summary
. Repetition breed errors and waste
. Abstract repetitive logic in code
. Related fundamentals:
  . template method pattern
  . command pattern
  . dependency inversion principle
Recommended reading:
  . The pragmatic programming: From Journeyman to Master
  . 97 Things Every Programmer Should Know.

So, Julia found one book to read this weekend, 97 Things Every Programmer Should Know.

Further reading: (Nov. 18, 2015)
Template method pattern:
https://en.wikipedia.org/wiki/Template_method_pattern

testing, automation and testing patterns

Nov. 8, 2015

  Watch the video:

Automated Testing Patterns and Smells

 https://www.youtube.com/watch?v=Pq6LHFM4JvE

Julia is a developer in the city of Vancouver last 5 years, she enjoyed the understanding how to minimize time 70% by following one simple principle: DRY - Do not repeat yourself.

For instance, to calculate something, the same code repeats twice; Just a simple example, Julia does not like to see the code repetition in the C# code, so she gives out a try to use base class, and then, merge to one function applying to the base class. But, all other repetitions are everywhere, so she cuts other places similar to the one, 2 to 1. So, do a math, the code needs change for cases 2 x 2 x 2, 3 place duplication, becoming 1 x 1 x 1; Done, reduce the 7/8 work to work with design, unit test, and bugs related to design. (similar ideas seen video, watched on Nov. 13, 2015 - https://www.youtube.com/watch?v=bxQK7hcVyGs&list=PLD4GnSXHpkQ2_eKG5fKzszXs5hYcEsft7)

Julia tries to contribute the ideas to show how important it is to following DRY principle, and then, reduce test cases, improve code quality, and then, shorten time to work on a project.

Back to the video, Julia likes to write down the notes from the video, she does not have time to read 600 pages book, but she knows the tip: get a good video, google talk, and then, invest 2-3 hours:

1. video time 16:07/59.33
What is a " Test smell"
1. duplicate code, hard coded values, etc.

A set pf symptoms of an underlying problem in test code. Like duplicate code, breaking DRY principle.

In the talk, using changing diaper as an example, how to know when to change diaper? When diaper stinks.

code smells - visible problems in test code
behavior smells - test behaving badly
project smells - testing-related problems visible to a project manager

2. video time 19:27 / 59:33
What's a "Test Pattern"?

A "test pattern" is a recurring solution to a test automation problem
- E.g. A "Mock Object" solves the problem of verifying the behavior of an object that should delegate behavior to other objects

Test Patterns occur at many levels:
- Test automation strategy pattern
 recorded test vs scripted test
- Test design Patterns
 implicit setup  vs delegated setup
- Test coding patterns
  assertion method, creation method
- Language-specific test coding idioms
  expected exception test, constructor test

3. video time 20:28/59:33
Common code smells

• conditional test logic
• hard to test code
• obscure test
• test code duplication 
• test logic in production 

4. Example to explain, best part
video time 22:16/59:33

1. Better assertion
2. Hard-wired test data - what is the relationship between those data? What is math? Do we need math? 30, why it is not 1, 19.99, why it is not 2, 69.96, why it is not 3? 6 months later, what is business logic?
    Hard-wired test data - will lead to fragile test

3. Introduce custom assert

  Avoid any conditional test logic in the test method - make less test code.
  Problem of conditional test logic is not sure what you are testing. <-  Julia likes this argument
  use customer assert, make a compaction of the code.

video time 28:58 / 59:33
4. Automated fixture teardown

tear down logic is a smell, such as, to separate business logic with presence logic

explicitly create deleteAllTestObjects instead of those complicated logic checking - nested try methods.

5. video time 32:07 / 59:33
Obscure test - irrelevant information

create address
create ..                               vs   createAnnoymousCustomer       vs createAnnoymounsInvoice
create customer                         createAnnoymounsInvoice

Hide detail in creation method - encapsulation, what is level of info - different levels info stays in one function - create more functions - each function much easy to be understandable, easy for unit test, variable scope less than a few lines

6. Test coverage, rapid test writing

Work outside in, create functions not existed yet, type test what you like to look

- Julia's comment:
If the code she wrote, it seems that the task is not showed in Leetcode questions, that means the code is not abstracted, not using object-oriented programming, cannot be unit test easily, people cannot read it without too much memorization, one function does all kinds of tasks; results? just too much time wasted for development, maintenance, testing, and it is bad behavior, not a pro. 


7. video time
44:08/ 59:38
Reducing Erratic Tests - Shared Fixture

Build new Shared Fixture for each run
- Avoids Unrepeatable Tests
- When:
 >> Lazy Setup
>> Setup Decorator
>> SuiteFixture Setup

Fragile Tests:
Causes:
Interface Sensitivity
- Every time you can change the SUT (S- , U- , T- tear down), tests won't compile or start failing
- You need to modify lots of tests to get things "Green" again
- Greatly increases the cost of maintaining the system

Behavior Sensitivity
- Behavior of the SUT changes but it should not affect test outcome
- Caused by being dependent on too much of the SUT's behavior.

Data sensitivity

Context sensitivity
- something outside the SUT changes
e.g. system time/date, contents of another application

46:19/ 59:33
Hard to test code
. code can be hard to test for a number of reasons:
- too closely coupled to other software
- No interface provided to set state, observe state
- Only asynchronous interfaces provided

. Root cause is lack of design for testability
- comes naturally with Test-Driven development
- Must be retrofitted to legacy (test-less) software

. Temporary workaround is Test Hook
- Becomes test logic in production (code smell) not removed.

50:17/59:33
What Does it take to be successful?
Programming Experience
+ xUnit Experience
+ Testing Experience
+ Design for Testability
-  Test smells
+ Test Automation Patterns
+ Fanatical Attention to Test Maintainability

read the website:
http://xunitpatterns.com/

Julia's comment:
Source code should be only written for machine to understand             - 20%
Source code should be readable for herself after 6 months / years        - 20%
Source code should be minimal - DRY principle - All other principle for easy to understand,
relax for herself - any time                                                                     - 30%
Source code should be fun to read, with documented unit test cases, log history etc.                                           - ?