Let’s say one of the components needed to make widgets is a 42″ stem-bolt and it arrives on pallets. There are 100 stem-bolts on a pallet. When the pallet is empty, the person assembling the widgets takes a card that was attached to the pallet and sends it to the stem-bolt manufacturing area. Another pallet of stem-bolts is then manufactured and sent to the widget assembler.
A new pallet of stem-bolts is not made until a card is received.
This is Kanban, in it’s simplest form.
Kanban is Pull (Demand)
看Growing Object-Oriented Software Guided by Tests也看到这样的方法。就是需要干什么才干什么。以前agile也有这样的精神。
From <<Growing Object-Oriented Software Guided by Tests>> p8
Nat was once brought onto a project that had been using TDD since its inception.The team had been writing acceptance tests to capture requirements and show progress to their customer representatives. They had been writing unit tests for the classes of the system, and the internals were clean and easy to change. Theyhad been making great progress, and the customer representatives had signed off all the implemented features on the basis of the passing acceptance tests.
But the acceptance tests did not run end-to-end—they instantiated the system’s internal objects and directly invoked their methods. The application actually did nothing at all. Its entry point contained only a single comment:
// TODO implement this
Additional feedback loops, such as regular show-and-tell sessions, should have been in place and would have caught this problem.
Unit-Test Behavior, Not Methods
We’ve learned the hard way that just writing lots of tests, even when it produces high test coverage, does not guarantee a codebase that’s easy to work with. Many developers who adopt TDD find their early tests hard to understand when they revisit them later, and one common mistake is thinking about testing methods.
A test called testBidAccepted() tells us what it does, but not what it’s for. We do better when we focus on the features that the object under test should provide, each of which may require collaboration with its neighbors and calling more than one of its methods. We need to know how to use the class to achieve a goal, not how to exercise all the paths through its code.
From <<Growing Object-Oriented Software Guided by Tests>> p58
As we wrote in Chapter 2, we view a running system as a web of communicating objects, so we focus our design effort on how the objects collaborate to deliver the functionality we need. Obviously, we want to achieve a well-designed class structure, but we think the communication patterns between objects are more important.
In languages such as Java, we can use interfaces to define the available messages between objects, but we also need to define their patterns of communication—their communication protocols. We do what we can with naming and convention, but there’s nothing in the language to describe relationships between interfaces or methods within an interface, which leaves a significant part of the design implicit.
We use TDD with mock objects as a technique to make these communication protocols visible, both as a tool for discovering them during development and as a description when revisiting the code.
Interface and Protocol
Steve heard this useful distinction in a conference talk: an interface describes whether two components will fit together, while a protocol describes whether they will work together.
From <<Growing Object-Oriented Software Guided by Tests>> p65
Our response is to organize the code into two layers: an implementation layer which is the graph of objects, its behavior is the combined result of how its objects respond to events; and, a declarative layer which builds up the objects in the implementation layer, using small “sugar” methods and syntax to describe the purpose of each fragment. The declarative layer describes what the code will do, while the implementation layer describes how the code does it. The declarative layer is, in effect, a small domain-specific language embedded (in this case) in Java
//declarative layer 应该算是interface层
From <<Growing Object-Oriented Software Guided by Tests>>
Iterations in Space
We’re writing this material around the fortieth anniversary of the first Moon landing. The Moon program was an excellent example of an incremental approach (although with much larger stakes than we’re used to). In 1967, they proposed a series of seven missions, each of which would be a step on the way to a landing:
1. Unmanned Command/Service Module (CSM) test
2. Unmanned Lunar Module (LM) test
3. Manned CSM in low Earth orbit
4. Manned CSM and LM in low Earth orbit
5. Manned CSM and LM in an elliptical Earth orbit with an apogee of 4600 mi
6. Manned CSM and LM in lunar orbit
7. Manned lunar landing
比如业务相关的代码主要有几类readers, workers, contexts, widgets，每个类别都有相同的模式和类似的接口
最近开始看growing object-oriented software guided by tests
To use App Inventor, you do not need to be a developer. App Inventor requires NO programming knowledge. This is because instead of writing code, you visually design the way the app looks and use blocks to specify the app’s behavior.