Chapter 14 — Software engineering

Chapter 14 — Software engineering

Lesson map

Lesson 14 published. Map, example, EX040.

flowchart TD
  N0["Learning outcomes"]
  N1["14.1 Lifecycle"]
  N2["14.2 Version control and review"]
  N3["14.3 Dependencies"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX040"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["14.1 Lifecycle"]
  N2["14.2 Version control and review"]
  N3["14.3 Dependencies"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX040"]

[Learning outcomes]
    |
    v
[14.1 Lifecycle]
    |
    v
[14.2 Version control and review]
    |
    v
[14.3 Dependencies]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX040]

Learning outcomes

You will (1) apply development lifecycle practices; (2) use version control and review; (3) manage dependencies safely.

14.1 Lifecycle

Jonas follows a lifecycle: requirements, design, implementation, verification, deployment and maintenance, with each stage producing artefacts that the next uses. For contracts, the lifecycle has an unusual feature: after deployment, code is hard or impossible to change, so verification must be thorough before release. The EthTrust specification notes that the cost of patching contracts after deployment is generally much higher than in other software. Jonas plans more time for review and testing than he would for an ordinary web application.

14.2 Version control and review

All code, configuration and documentation live in version control. Every change goes through a pull request reviewed by another person, with tests run automatically. Jonas learns to write small, focused changes with clear descriptions, because reviewers catch more in small changes. He also tags each released version and records the exact compiler version and settings used, so the deployed bytecode can be reproduced and matched to reviewed source, a requirement EthTrust places on conformance claims. Reviewers use a short checklist for each change.

14.3 Dependencies

Contracts and tools depend on libraries written by others. Jonas lists every dependency, pins exact versions and records where each came from. He prefers widely reviewed libraries and reads release notes before upgrading. He notes the risk that a dependency could be compromised or contain a bug, and plans to review changes in dependencies with the same care as the cooperative's own code. Supply-chain care matters especially when code will control value and cannot easily be patched. Each upgrade is recorded in a decision note.

Worked example

The project records compiler versions and settings for reproducible builds, uses reviewed pull requests, and pins all dependencies.

Synthetic case. Code, reviews and dependencies are synthetic; EEA EthTrust is a real source.

Errors and limits

Upgrading dependencies without reading changes can import bugs into code that controls value.

Exercises

• EX040 — Lifecycle difference. What is unusual about the contract lifecycle? Rubric: 3 = code is hard to change after deployment;; 2 = immutability;; 1 = vague;; 0 = none.
• EX041 — Build record. What is recorded for each release? Rubric: 3 = exact compiler version and settings;; 2 = compiler;; 1 = vague;; 0 = none.
• EX042 — Dependency practice. How are dependencies managed? Rubric: 3 = listed, pinned, provenance recorded;; 2 = pinned;; 1 = latest always;; 0 = none.

Synthesis

Disciplined lifecycle, review and dependency practices suit code that is hard to change after deployment.

Continue studying — chapter 14 of 50

← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →