kanban

最近经常注意到amazon上一本kanban的书评价很高

也是关于软件开发的

这几天一个项目接近尾声,准备好好反思一下

又查到这个词

这个地方讲的最简单:

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也有这样的精神。

打算啥时候把这本书搞来看看。

The Importance of End-to-End Testing: A Horror Story

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.

p43

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.

Communication over Classification

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.

//自己一般是写个demo程序或者类似demo的test

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.

two layers

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层

card

From <<Growing Object-Oriented Software Guided by Tests>>

We find it useful to keep a notepad or index cards by the keyboard to jot down failure cases, refactorings, and other technical tasks that need to be addressed. This allows us to stay focused on the task at hand without dropping detail.

增量迭代

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
(7400 km)
6. Manned CSM and LM in lunar orbit
7. Manned lunar landing

新的代码

花了两个礼拜重写
把原来的一个程序分解为两个
现在耦合更加松散
大部分类基本都可以单独测试
每个模块也可以单独运行和测试
大量运用context来进行解耦,把依赖都放到context接口里
把业务无关的代码都分解出去,单独进行重构,扩展和测试
新的代码模式更加统一
比如业务相关的代码主要有几类readers, workers, contexts, widgets,每个类别都有相同的模式和类似的接口
本来以为一个礼拜就可以写完
但是没有想象中的那么简单
写这个版本的时候心里想为什么前一个版本没有这么设计?
也许这就是边写边学习的过程吧
只有完全接触了每个部分之后才能够从整体出发进行重新设计
一开始看不清楚整体
另外,第一版里面也有很多的教训
这些都是设计第二版的基础
最近开始看growing object-oriented software guided by tests
觉得这本书应该对目前的事情有些帮助

AppInventor

http://appinventor.googlelabs.com/about/

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.

之前是一个MIT哥们的硕士论文:Open Blocks

个人觉得编程语言的未来应该是图形化的编程,门槛很低以至于老少皆宜

大家就跟安装一个书架或者自行车一样来安装出自己的程序

其实现在自己编程一般也都是先在白纸上画出一个个blocks

在写代码的时候头脑里的模型也是基于blocks的,而不是一行行的文本

构思的时候是想象出一个一个的小精灵,每个小精灵拿什么东西,输出什么东西。物品是如何在小精灵中流通的。