COMP23311 24小时速成

Week 1: Building & Testing Open Source Systems

What is software Engineering?

1. Building software to Budget + Deadline
2. Needs to Deliver sufficient ROI (Return on Investment) + affordable to maintain and change

Typical Software organisation:

• Local Dev
• Dev
• Test
• Live
• End Users

1. Acquring Source code
2. Build the object code
3. Run tests (code review, follow coding standards/documentation procedures, pass automated tests)

Week 2: Understanding Large Software Systems Through Tests

code reading: system domain technical

syntactical/conceptual error/software bugs (faults error flow in source code or system design)

Week 3: Debugging

Debug systematic approach:

1. start with a problem:
   replicate the issue

2. stablize a problem
   describe the problem precisely

3. isolate the problem
   

   • tactic: rubber ducking, find common problems, IDE debug tools, test cases, git commit logs

   • strategy: brute force+backtrack+binary search+eliminate

4. fix the problem
   (mostly the easiest part)

5. test if the fix is successful
6. check similar errors (very important)

JUnit测试用例基本规则:

1. test class 以 Test 结尾
2. test method 一般建议以 should 开头 (别的其实也可以)
3. assert一个测试方法中只能有一个
4. test method 不要有任何传入参数

Week 4: Cost Estimation

Cost estimation: effort + resources + schedules

WBS: work breakdown structures

100% rule: states that the WBS includes 100% of the work defined by the project scope and captures all deliverables – internal, external, interim – in terms of the work to be completed, including project management.

Week5: Test First Development

Scoping features to manage risk

1. incremental dev: Simple ver, in a form that can be used, Minimum marketable feature
2. Build on existing components: reuse, adapt, expand
3. Control the scope:
   ctrl affected:
   1. existing types of obj
   2. existing functions
   3. user groups

Release planning

1. release date
2. user type?
3. build on? (reused what?)
4. affected types?
5. affected functions?

Agile Method: Fail fast (corner stone)

1. short iterations
2. user stories
3. iteration planning/release planning
4. evolutionary design
5. TFD/TDD Test-first dev (test driven dev 更强)

Test against 3 layer architecture (Presentation logic, Business Logic, Data Logic):

1. Outside-in Approach (gui driver 模拟用户操作)

2. Middle-Out Approach (调用 service layer api)

Role of acceptance tests

evaluate the system’s compliance with the business requirements and verify if it is has met the required criteria for delivery to end users.

Test-first process:

1. sketch out expected behavior as acceptance tests (use existing codes, or wishful thinking)
2. create test stubs and compile test
3. run the test to get a result (red)
4. implement the production code stubs
5. run the test again (should be green)

Remember in Jenkins:

1. grey == not running test
2. red == compile failed
3. yellow == compile successful, but some tests failed
4. green == all tests passed

Failing test:

• fail unit test: you are fucked
• failed pre-passed acceptance test: you are fucked
• failed acceptance test on future features: it’s fine

TAD -> TFD -> TDD: maximise test coverage, maximise fit of production code to test code

Week 6: Git Workflow

Code review:

1. buddy review (informal)

2. team-based review (informal)
   tool: gerrit (allow code to be held in staging area for code rev, block integration into main branch until pass quality standard)

   way: walkthrough: sanity check of design (best at the beginning), or correctness of implementation (after or during implementation)

3. formal review (formal, inspection, technical review, technical+management)

Code reviewer’s good practice: neutral tone, promiscuory reviewing (轮换检查)

Rules on Commit msg:

Imperative tone, NO COMMA, first line limit to 50 chars, the rest limit to 72 chars, second line leave blank, leave blank between paragraphs, detailed description of the change, integrate bug tracking

Git commit shits:

group coordination+codebase synchronisation, quality assurance

1. Merge
2. Cherry Pick
3. Rebase
4. Resolve conflict
5. Fast forward

Difference between Merge and conflict:

Merge == preserve feature branch, Rebase == blow up feature branch, no record, look simple and elegent

Git workflow:

1. GitFlow Model
   
   • 2 main branches: master develop
   • 3 supporting branches: feature hotfix release
   • only hotfix branch can fork from master

   • NO FAST FORWARD, NEVER.

   • [branch structure]:

     develop <=> master <=> feature

     master <=> hotfix, feature <=> develop

     release <=> develop, (maybe!) hotfix => develop

   

2. GitHub Flow
   master, feature branches. all work done on feature branch

   every commit on master is deployable, test branch in production environment before merging, pull request for code review

3. Trunk-Based Development (主干开发模型)
   everyone work in one single trunk branch
   

   one can work on local branch, merge to remote branch after get passed in gerrit
   

   every single commit is release ready, high quality commits but no protection against errors

Week 8: Refactoring and Migration

• fixed bugs: corrective
• added feature: adaptive
• refactoring/migration: preventive change (prevent cost)

Patterns of code change:

• rename method/class

• covert a var into const

• convert a local var into a field

• move a method to another class

Refactoring:

1. IDE integrated
2. change structure but not behavior
3. good tests are essential
4. workflow: run tests -> refactor -> run test again
5. relatively small changes

Software Migration:

large scope, move some functionality from one context to another (like from MySQL to Couchbase)

Typical Process:

1. Ensure behavior which to be migrated is well tested
2. Migrate test to fit target context (doesn’t care abstract layer tests)
3. Then migrate functionality
4. test+fix until all migrated tests passed
5. then remove old form migrated tests

9. Design for Testability

Code is easy to test => code is easy and safe to change => good software design

design driven for testability, ensure the code is easy to test

Bad factors:

1. Non-deterministic (randomness) code
2. Hard-coding/hiding behavior
3. Not allowing inheritance/overriding
4. Complex/Slow configuration (running excessive shit such as database even if just need to test a simple thing, take more time)
5. Break the LAW OF DEMETER (I don’t know, didn’t covered, don’t ask)

Test doubles: (测试替身): a ver of predictable production code object

1. Dummies: placeholder, passed but never used
2. Stubs: fixed value, canned answers
3. Fakes: include simple (usually shitty) logic, (partly) working implementations
4. Mocks: basically stub with assertions

10. Patterns

Patterns: distilled wisdom, allow to reuse solutions (experience), provide a shared vocabulary of talking about software design

Group of Patterns:

1. Behavioural Patterns (state, strategy)
2. Structural Patterns (composite, adaptor)
3. Creational Patterns (factory method, singleton)

• Strategy Pattern: 基于不同类对应的策略封装算法
• State Pattern: 封装同一对象基于不同状态的多种行为
• Composite Pattern: 部分-整体组合模式
• Adapter Pattern: 接口转换, wrapper class
• Factory Method: 让子类自己在运行时决定实例化哪个类
• Singleton Pattern: 只让某个类创建唯一的一个对象

Caution:

1. No overuse
2. No over-engineering
3. refactor TOWARD a pattern rather than TO a pattern (把pattern作为参考, 而不是标准)

Pattern的意义:

Make code easy to understand, maintain and modify

11. Risk Management

Risk: possible negative event

Risk exposure = likelihood + impact (potential cost)

Planning:

1. Mitigate planning: make it less likely happen + reduce impact
2. Contingency Planning: make preparation if it happen, do nothing to reduce likelihood or impact

Tools used for risk management:

• Git for Risk Management: ……
• CI/CD for Risk Management: reduce risk likelihood
  CI: Integrate, build, test, report, make testing and building reliable
• Automated Test Suite for Risk Management: reduce cost of regression (reduce cost)

a, b : interval

Begin(), End() shike

Before(a, b) => End(a) < Begin(b)

After(a, b) => Begin(a) > End(b)

Meet(a, b) => End(a) = Begin(b)

During(a, b) => Begin(b) < Begin(a) < End(a) < End(b)

Finishes(a, b) => Begin(b) < Begin(a) < End(a) = End(b)

Starts(a, b) => Begin(b) = Begin(a) < End(a) < End(b)

Equals(a, b) => Begin(b) = Begin(a) && End(a) = End(b)

Overlap(a, b) => Begin(a) < Begin(b) < End(a) < End(b)

• Previous
  数据库导论 其他数据库
• Next
  计算机视觉导论：图像合成