公开课学习打卡

之前转码入行一直用Ruby，新工作需要使用Java，并在日常工作中深觉得基础欠缺许多，希望通过上一系列的公开课达到以下目标：1. 系统性掌握Java
2. 系统性掌握Spring

因为关注点更多在于怎么把java应用到实际工作中，所以pick了这门software construction的课，系统性地归纳了怎么写更好的工业用代码吧。按每天1-2小时的time commitment，大致列了一下课程书籍的顺序和学习时长。bar设得比较低，每天来打卡完成进度，希望年底完成目标。

1. MITx: 6.005.1x Software Construction in Java （12d）
2. MITx: 6.005.2x Advanced Software Construction in Java（9d）
3. Udemy: Java 8 New Features in Simple Way (10d)
4. Udemy: Java memory management (5d)
5. Effective Java (22d)
6. Udemy: Spring & Hibernate for Beginners (includes Spring Boot) (20d)
7. Thinking in Java（30d）


另有其他经典课程是用java教授，因为侧重点更在算法上，现在就不列入了。
Stanford CS61A: https://see.stanford.edu/Course/CS106A or UCBerkley CS61B: https://inst.eecs.berkeley.edu/~cs61b/sp20/

补打卡前几天的software construction的学习，7/15-18

7/15 Reading 1,
Java trap, static checking, dynamic checking, no checking
  Immutable object
  Document the assumption
    - communicate w/ computer
    - communicate w/ people
  safety, clarity, abstraction and engineering instincts  safe from bugs, easy to understand and ready for change


7/16 Reading 2, Code Review
- Don't repeat yourself (DRY)
- Write comments where you need them
  - spec, e.g. javadoc
  - note the reference, especially when you copy the code from web
  - example of bad comments, merely translate the code to english: while (n != 1) {} // test whether n is 1
- Make your code fail fast
  - e.g. validate your input is in valid range
- Avoid using magic numbers
  - people do not know where this number coming from, causing confusions.
  - it is much better to use names
- Have one purpose for each variables
  - method parameters in particular, should generally be left unmodified, use final w/ it is a good idea
- Use good names for methods and variables
  - method names are usually verb phrase, while variable and class names are usually noun phrase, avoid using abbreviation
- Don't use global variables
- Have your methods return their results rather than printing them?
- Use whitespace to help the reader read your code

7/17 Reading 3 Testing
- Ways of validation
  - Formal reasoning
  - Code review
  - Testing
- Why testing is hard?
  - Exhaustive testing, Haphazard testing and Random or statistical testing (sampling) are general ways for testing, but are not applicable for software testing.
  - test case need to be chose carefully and systematically
- Test-first programming / TDD
- Partitioning
  - input space => subdomain
  - include boundaries in the partition
    - off-by-one mistakes
  - how to cover partition
    - full cartesian product (exhaustive approach)
    - cover each part (this is more feasible in day to day coding)
- Black box & White box testing
  - black, spec
  - white, implementation
- Testing coverage
  - statement coverage (should always try to achieve this)
  - branch coverage
  - path coverage (almost impossible to be 100%)
- Type of tests
  - unit test, test the module itself
  - integration test, connection between modules
  - regression test, Whenever you find and fix a bug, take the input that elicited the bug and add it to your automated test suite as a test case. This kind of test case is called a regression test.


07/19 Reading 4 Spec
- Structure
  precondition & postconditions
- Avoid null
- Mutation is disallowed unless stated otherwise
- Exceptions: checked (expected behavior and usually r handled properly) vs unchecked (signal bugs)

我也准备用ruby转行，想要认识楼主

上周工作比较忙，周末把周中的任务一起补上了。明天希望能恢复打卡。

7/20 Reading 5 Designing Specifications
Three dimensions when comparing specs:
1. deterministic
  - rather than use non-deterministic (sometimes behave one way and other times behave another way, e.g. use random number, timing of concurrent process), use undetermined.
  - undetermined spec could have deterministic implementation.
2. declarative
  - properties of final outcome and how it relates to the input.
  - declarative spec is preferable than operational spec, as the latter's audience is maintainer and the former's audience is client programmer. It is better to leave comment between codes for the maintainer.
3. strong
  - weaker precondition & stronger postcondition => stronger spec
  - it is safe to replace the old spec w/ stronger new spec
What is good spec?
- coherent
- usually define postcondition to say if the input is such, a certain exception is thrown. That is better to define a stronger precondtion, which cause client more trouble. The key factors are the cost of the check (writing & executing the code), e.g. private or public method.

7/21 Reading 6: Avoid Debugging
- Makes bugs impossible
  - static checking
  - dynamic checking
  - immutability, e.g. String (immutable type), final (immutable reference)
- Localize bug
  - checking precondition => defensive programming. e.g. assert (off r default), jvm argument + -ea. use assertion only in development and testing, never used in release. <= emm, not sure this is applicable in real case, we do valid input check all the time in day to day programming, and throw BadInputException as early as possible.
  - incremental development
    - unit testing, regression testing
    - modularity, encapsulation (access control, variable scope - declare your variable when you need it, to avoid unnecessary larger scope)

7/22 Reading 7: Mutability and Immutability
- mutable variable usually created for the benefit of performance, like StringBuilder.
- However, it is general better to use immutable variable
- Date, mutable object, deprecated => ZonedDateTime
- defensive copying, advantage: client could do whatever, disadvantage: resources wasting, better to have immutable object
- root cause: multiple references, also called alias, to a mutable object
- It is important to include the side effects (e.g. mutation) on the spec of the method
7/23 Reading 8: Debugging
- reproduce the bug w/ a repeatable test case (which could be attended as a regression test)
- reduce the input to manageable input
  - cut the input by half, e.g. binary search
  - pick smaller module of the input
- use scientific method to find the bug
  - study the data, e.g. stack trace from exception, small test case
  - make hypothesis, e.g. modularize your program to localize the bug
  - do a experiment, e.g. different test case, print statement/assertion, debugger
  - repeat
- tips
  - bug localization by binary search (finding bug is like a search process)
  - prioritize your hypotheses, e.g. more recent code have higher possibility of leading to the bug
  - swap components, but do not do this unless have good reason to suspect a component
  - make sure your source code and object code r up to date
  - get help, e.g. talk to your yellow duck :)
  - sleep on it, trade latency for efficiency
- fix the bug thoughtfully, not slapdash
  - identify the type of bug, e.g. is it a coding error, or a design error
  - think if the bug has any relatives
7/24 Reading 9: Abstract Data Type
- a.k.a
  - Abstraction
  - Modularity
  - Encapsulation
  - Information hiding
  - Separation of concerns
- a type is characterized by the operations you can perform on it, e.g. no need to worry about the data structure behind it
- operations of an abstract type:
  - creators, create new objects of the type, e.g. constructor, factory method, valueOf(), new ArrayList()
  - producers, create new objects from old objects of the type
  - observers, .size()
  - mutators, change objects, e.g. Set.add()
- design abstract data type
  - few simple operation
  - coherent, general?
  - adequate, e.g. enough operations to extract the property of the object
  - representation / implementation independent
- An ADT is tested by generating tests for each of its operations, but using the creators, producers, mutators, and observers together in the same tests.

7/25 Reading 10: Abstraction Functions and Rep Invariants
- preserve its own invariants, e.g. immutable
- representation exposure, defensive copy, e.g. should never store or return the direct reference to a mutable object, just use immutable type (immutable wrappers around mutable data types, e.g. Google Guava immutable set)
- abstract value & rep value, more like one to many relationship
- document rep invariant & abstraction functions & safety from rep exposure (access control & immutablity)? this is not usually seen in industry codes?
- Structure induction (proving invariant)
  - established by creators & producers
  - preserved by mutators and observers
  - no representation exposure occurs
- ADT invariants replace preconditions

7/26 Reading 11: Interfaces
- list of method signatures
- subtype, the spec is stronger that of supertype
- advantages of interface
  - documentation for both complier and human
  - allowing performance trade off, e.g. different implementation for different scenarios for better performance
  - optional methods, e.g. by omitting optional method in Java List interface to create immutable list
  - methods w/ intentionally undetermined spec
  - multiple views of one class
  - more and less trustworthy implementations

txyxfox 发表于 2020-7-19 14:26
我也准备用ruby转行，想要认识楼主

看到回复有些晚。好啊，有什么问题可以在帖子里问我，或者私信都可以。可能回答会有个人经历影响会比较片面。

7/27 Reading 12: Equality
- three ways to regard equality
  - using an abstraction fn, a equals b if f(a)=f(b)
  - using a relation, reflexive, symmetric, transitive
  - using an observation (calling operation on object)
- java
  - ==, reference equality
  - equals, object equality, e.g String.equals, usually defined by the object
    - for immutable type, you always want to override the default equals() (the default usually evaluate the reference equality)
    - possible problem w/ overloading, @Override to indicate the correct override
    - instanceof (or method like getClass()) is disallowed anywhere except for implementing equals
- hashCode
  - Always override hashCode when u override equals
- the equality of mutable type
  - observational equality vs behavioral equality
  - e.g. adding mutable object to Set
  - equals should implement behavioral equality
  - mutable type should not modify the equals method, should always use referential equality
- For Integer == implements referential equality while for int == implements behavioral equality. This could be a problem, since Java autoboxing(int => Integer) and autounboxing(Integer => int).