技术、哲学、做人

最近闲下来的时候喜欢看很多书，看来看去发现一些看似很陈旧的技术和概念其实蕴涵着丰富而又浅显的哲学思维和做人原则。新技术新概念层出不穷，令人眼花缭乱，浮躁不安，甚至血压升高。而那些基本的实现原则其实就像我们应该做什么样的人一样。这也是我比较喜欢Gerald Weinbery, Steve Maguie，Richard Stevens等的一些书的原因。不一定要都当成在读技术，有时候多想想，多回顾一下这些年经历的事情也是很有感慨。

比如有空读读70年代80年代90年代的RFC，这些RFC有些已经很陈旧了，有些只是在讲一些原则性的东西，有些只是在讲一个技术历史故事甚至插曲。不一定都当技术文档来读，这样说来，有时候其实也是个从技术出发的“心灵鸡汤”。

下面是前些天我发给同事们的一个邮件。不一定大家都能认同这些，也许有人觉得这些浅显的道理没什么。但我觉得在我们现在这种浮躁的技术实现领域，特别是软件开发领域是应该有这些态度的。其实也是一种做人处世的态度吧。

-----------the email------------
在读RFC1122（Requirements for Internet Hosts）的时候，对下列部分感触很多，希望大家分享学习：
1.2 General Considerations ................................. 12
1.2.1 Continuing Internet Evolution ..................... 12
1.2.2 Robustness Principle .............................. 12
1.2.3 Error Logging ..................................... 13
1.2.4 Configuration ..................................... 14
这个RFC虽然是Internet对主机的要求，更是对主机软件的要求，特别是对我们如何设计和实现软件，在软件开发、协议开发、接口开发中很有指导意义。给出了非常明确的软件设计原则，对软件的可发展性原则，稳健性原则、错误异常统计和Log、可配置性都提出了很好的一般性原则。建议大家好好读读这部分。
1． 可发展性：软件最初设计和实现的时候可能没有那么多功能，但产品和需求是不断发展的，如果不设计好结构和可扩展性，就的不断反工或者最后乱的一团糟；
2． 稳健性原则：特别是"Be liberal in what you accept, and conservative in what you send"这句明言，其实和我们中国的一句老话“宽以待人，严以律己”非常符合，这里介绍的稳健性原则是非常经典的总结；
3． 错误异常统计和Log：任何时候发现问题或bug或和别的设备或模块对接的异常都应该能从软件中提供的统计和log中分析出来，这就需要很好设计这些统计和Log。统计Log＋代码走查应该能查到所有问题，而不是靠测试和现场重现。如果在出现异常的时候必须需要模拟重现该异常才能找到原因，那么这个软件的设计和实现就不能说是成功的。
4． 可配置性：软件用到的任何配置数据和参数都应该是可以加、删、改的，而且这些可配置性应该是稳健的，可以用最方便的方法做到的，不依赖别的软件和设备的。

以下是节选的一段：
1.2 General Considerations

There are two important lessons that vendors of Internet host
software have learned and which a new vendor should consider
seriously.

1.2.1 Continuing Internet Evolution

The enormous growth of the Internet has revealed problems of
management and scaling in a large datagram-based packet
communication system. These problems are being addressed, and
as a result there will be continuing evolution of the
specifications described in this document. These changes will
be carefully planned and controlled, since there is extensive
participation in this planning by the vendors and by the
organizations responsible for operations of the networks.

Development, evolution, and revision are characteristic of
computer network protocols today, and this situation will
persist for some years. A vendor who develops computer
communication software for the Internet protocol suite (or any
other protocol suite!) and then fails to maintain and update
that software for changing specifications is going to leave a
trail of unhappy customers. The Internet is a large
communication network, and the users are in constant contact
through it. Experience has shown that knowledge of
deficiencies in vendor software propagates quickly through the
Internet technical community.

1.2.2 Robustness Principle

At every layer of the protocols, there is a general rule whose
application can lead to enormous benefits in robustness and
interoperability [IP:1]:

"Be liberal in what you accept, and
conservative in what you send"

Software should be written to deal with every conceivable
error, no matter how unlikely; sooner or later a packet will
come in with that particular combination of errors and
attributes, and unless the software is prepared, chaos can
ensue. In general, it is best to assume that the network is
filled with malevolent entities that will send in packets
designed to have the worst possible effect. This assumption
will lead to suitable protective design, although the most
serious problems in the Internet have been caused by
unenvisaged mechanisms triggered by low-probability events;
mere human malice would never have taken so devious a course!

Adaptability to change must be designed into all levels of
Internet host software. As a simple example, consider a
protocol specification that contains an enumeration of values
for a particular header field -- e.g., a type field, a port
number, or an error code; this enumeration must be assumed to
be incomplete. Thus, if a protocol specification defines four
possible error codes, the software must not break when a fifth
code shows up. An undefined code might be logged (see below),
but it must not cause a failure.

The second part of the principle is almost as important:
software on other hosts may contain deficiencies that make it
unwise to exploit legal but obscure protocol features. It is
unwise to stray far from the obvious and simple, lest untoward
effects result elsewhere. A corollary of this is "watch out
for misbehaving hosts"; host software should be prepared, not
just to survive other misbehaving hosts, but also to cooperate
to limit the amount of disruption such hosts can cause to the
shared communication facility.

1.2.3 Error Logging

The Internet includes a great variety of host and gateway
systems, each implementing many protocols and protocol layers,
and some of these contain bugs and mis-features in their
Internet protocol software. As a result of complexity,
diversity, and distribution of function, the diagnosis of
Internet problems is often very difficult.

Problem diagnosis will be aided if host implementations include
a carefully designed facility for logging erroneous or
"strange" protocol events. It is important to include as much
diagnostic information as possible when an error is logged. In
particular, it is often useful to record the header(s) of a
packet that caused an error. However, care must be taken to
ensure that error logging does not consume prohibitive amounts
of resources or otherwise interfere with the operation of the
host.

There is a tendency for abnormal but harmless protocol events
to overflow error logging files; this can be avoided by using a
"circular" log, or by enabling logging only while diagnosing a
known failure. It may be useful to filter and count duplicate
successive messages. One strategy that seems to work well is:
(1) always count abnormalities and make such counts accessible
through the management protocol (see [INTRO:1]); and (2) allow

the logging of a great variety of events to be selectively
enabled. For example, it might useful to be able to "log
everything" or to "log everything for host X".

Note that different managements may have differing policies
about the amount of error logging that they want normally
enabled in a host. Some will say, "if it doesn't hurt me, I
don't want to know about it", while others will want to take a
more watchful and aggressive attitude about detecting and
removing protocol abnormalities.

1.2.4 Configuration

It would be ideal if a host implementation of the Internet
protocol suite could be entirely self-configuring. This would
allow the whole suite to be implemented in ROM or cast into
silicon, it would simplify diskless workstations, and it would
be an immense boon to harried LAN administrators as well as
system vendors. We have not reached this ideal; in fact, we
are not even close.

At many points in this document, you will find a requirement
that a parameter be a configurable option. There are several
different reasons behind such requirements. In a few cases,
there is current uncertainty or disagreement about the best
value, and it may be necessary to update the recommended value
in the future. In other cases, the value really depends on
external factors -- e.g., the size of the host and the
distribution of its communication load, or the speeds and
topology of nearby networks -- and self-tuning algorithms are
unavailable and may be insufficient. In some cases,
configurability is needed because of administrative
requirements.

Finally, some configuration options are required to communicate
with obsolete or incorrect implementations of the protocols,
distributed without sources, that unfortunately persist in many
parts of the Internet. To make correct systems coexist with
these faulty systems, administrators often have to "mis-
configure" the correct systems. This problem will correct
itself gradually as the faulty systems are retired, but it
cannot be ignored by vendors.

When we say that a parameter must be configurable, we do not
intend to require that its value be explicitly read from a
configuration file at every boot time. We recommend that
implementors set up a default for each parameter, so a
configuration file is only necessary to override those defaults
that are inappropriate in a particular installation. Thus, the
configurability requirement is an assurance that it will be
POSSIBLE to override the default when necessary, even in a
binary-only or ROM-based product.

This document requires a particular value for such defaults in
some cases. The choice of default is a sensitive issue when
the configuration item controls the accommodation to existing
faulty systems. If the Internet is to converge successfully to
complete interoperability, the default values built into
implementations must implement the official protocol, not
"mis-configurations" to accommodate faulty implementations.
Although marketing considerations have led some vendors to
choose mis-configuration defaults, we urge vendors to choose
defaults that will conform to the standard.

Finally, we note that a vendor needs to provide adequate
documentation on all configuration parameters, their limits and
effects.
---------------------------

做一个对周遭的事物包容的人，做一个对自己做事严谨的人!