Makefile概念入门

in nekin nek

[版本]

V0.1 Kenneth Lee 先写一个框架出来


[介绍]

写这篇东西原始目的不是为了介绍怎么写Makefile,而是介绍怎么用“基于目标分层”的方式理解一个工具,写作一个概念,定义一个设计或者部署一套代码。

但我介绍这种“方式”的方法是,写一个“Makefile的写作入门”。所以,本文首先是一个“Makefile入门”,然后才是“基于目标分层的方法介绍”。

不少的Makefile的介绍材料总是上来就开始介绍“依赖”,“规则”,而默认你已经知道为什么你需要“依赖”和“规则”了,很多“热爱学习”的工程师也把这些“依赖”和“规则”事无巨细地记在心里,然后你看着他们学习了很久的Makefile,但一直都搞不清楚他学了些啥,写的Makefile也就仿一下别家的模式,什么真的需要,什么不是真的需要,他们是搞不清楚的。


[关于程序编译]

Makefile解决的是编译的问题。编译有什么问题呢?比如说,你有3个C文件——等等,让我们先偏个题,说明一下——Makefile最初是用来解决C语言的编译问题的,所以和C的关系特别密切,但并不是说Makefile只能用来解决C的编译问题。你用来处理Java一点问题没有,但对于Java,显然ant比Makefile处理得更好。但那是细节,你理解了Makefile,理解ant就没有什么难度了。再说了,Makefile本身的格式也不是什么标准,不同的make工具对Makefile本身怎么写细节是不一样的,本文介绍的是这个工具的思想原理,细节你要自己看对应的手册。由于本文是在Linux上写的,所以我会用gnumake的格式作为例子,但从原理上说,它们是非常相似的。

回到“有三个C文件”的问题。比如说,你有foo.c, bar.c, main.c三个C文件,你要编译成一个app.executable,你会怎么做呢?你会执行这样的命令:

gcc -Wall -c foo.c -o foo.o
gcc -Wall -c bar.c -o bar.o
gcc -Wall -c main.c -o main.o
gcc main.o foo.o bar.o -lpthread -o app.executable

按Unix程序员的惯例(应该说,这是所有程序员的惯例),凡是要一次次重新执行的命令,都应该写成脚本,变成“一个动作”。所以,简单来说,你会把上面这个命令序列写成一个build.sh,每次编译你只要执行这个脚本问题就解决了。

但这个脚本有问题,假设我修改了foo.c,但我没有修改bar.c和main.c,那么执行这个脚本是很浪费的,因为它会无条件也重新编译bar.c和main.c。

所以,这个脚本更合理的写法应该是这样的:

[ foo.o -ot foo.c ] && gcc -Wall -c foo.c -o foo.o
[ bar.o -ot bar.c ] && gcc -Wall -c bar.c -o bar.o
[ main.o -ot main.o] && gcc -Wall -c main.c -o main.o
[ app.executable -ot main.o ] && [ app.executable -ot foo.o ] && [ app.executable -ot bar.o ] && gcc main.o foo.o bar.o -lpthread -o app.executable

这很复杂是不是?同样按Unix程序员的一般作风,如果你面对一个问题,不要尝试重新去定义这个问题,而是看它和原来的问题相比,多出来的问题是什么,尝试解决那个多出来的问题就好了。

那么这里,多出来的问题就是文件修改时间比较。这个就是Makefile要解决的基本问题了。我们定义一种新的“脚本语言”(只是不用sh/bash/tch来解释,而是用make来解释),可以用很简单的方法来说明我们需要做的文件比较。这样上面的脚本就可以写成这个样子了:

#sample1
foo.o: foo.c
  gcc -Wall -c foo.c -o foo.o
bar.o: bar.c
  gcc -Wall -c bar.c -o woo.o
main.o: main.c
  gcc -Wall -c main.c -o main.o
app.executable: foo.o bar.o main.o
  gcc main.o foo.o bar.o -lpthread -o app.executable

这样读写起来是不是就简单多了?

这就是Makefile解决的原始问题。Makefile不是必须的,但它能减少你很多麻烦。有人可能会说,为什么要这么麻烦?我们用IDE就好了。IDE封装了Makefile的使用当然好,问题是IDE在里面都是用默认的规则(相当于有一个默认的Makefile),但如果你想具体控制特定文件的编译细节,最终你还不是一样面对这些问题? 所以,这个完全不是个IDE和make工具的对比问题,这两者解决的是问题的不同层次。

上面那个Makefile中,foo.o: foo.c定义了一个“依赖”,说明foo.o是靠foo.c编译成的,它后面缩进的那些命令,就是简单的shell脚本,称为规则(rule)。而Makefile的作用是定义一组依赖,当被依赖的文件比依赖的文件新,就执行规则。这样,前面的问题就解决了。

Makefile中的依赖定义构成了一个依赖链(树),比如上面这个Makefile中,app.executable依赖于main.o,main.o又依赖于main.c,所以,当你去满足app.executable(这个目标)的依赖的时候,它首先去检查main.o的依赖,直到找到依赖树的叶子节点(main.c),然后进行时间比较。这个判断过程由make工具来完成,所以,和一般的脚本不一样。Makefile的执行过程不是基于语句顺序的,而是基于依赖链的顺序的。


[phony依赖]

make命令执行的时候,后面跟一个“目标”(不带参数的话默认是第一个依赖的目标),然后以这个目标为根建立整个依赖树。依赖树的每个节点是一个文件,任何时候我们都可以通过比较每个依赖文件和被依赖文件的时间,以决定是否需要执行“规则”。

但有时,我们希望某个规则“总是”被执行。这时,很自然地,我们会定义一下“永远都不会被满足”的依赖。比如你可能会这样写:

test:
  DEBUG=1 ./app.executable

test这个文件永远都不会被产生,所以,你只要执行这个依赖,rule是必然会被执行的。这种形式看起来很好用,但由于make工具默认认为你这是个文件,当它成为依赖链的一部分的时候,很容易造成各种误会和处理误差。

所以,简化起见,Makefile允许你显式地把一个依赖目标定义为“假的”(Phony):

.PHONY: test
test:
 DEBUG=1 ./app.executable

这样make工具就不用多想了,也不用检查test这个文件的时间了,反正test就是假的,如果有人依赖它,无条件执行就对了。

PHONY目标算不上是Makefile的基础知识的一部分,我之所以提出来,是要用一个简单的例子说明,“名称定义”是怎么影响“后续逻辑和新名称定义的”。所谓“为学日益”,就是这个意思,你为了解决一个问题,就会定义一个新的逻辑(名称),这个然后这个新的名称,就会制造新的问题,你解决那个问题,就需要新的名称定义,就会产生新的问题,就需要更多的名字。日益增加的“名字”,最终会成为对你脑子的DoS攻击,导致“控制”的最终失控。在这个例子中,因为我们引入了“目标和依赖”,所以我们才有了“假目标”这个定义,而因为我们有了“假目标”这个定义,我们后面就会引入“假依赖”的问题。你在整个逻辑思考的过程中,就不能不多考虑一个“名称要素”,这些是“成本”,要省着用。所以我们才有了“不敢为主而为客”。“为客”就是让每个“名称”都要“买下至少一个问题”,不解决问题的“名称”,就让它去死。

后面讨论的每个问题,我都隐含了这个逻辑,请读者从现在起就开始注意。


[宏]

前面的sample1明显还是有很多多余的成份,这些多余的成份可以简单通过引入“宏”定义来解决,比如上面的Makefile,我们把重复的东西都用宏来写,就成了这样了:

#sample2
CC=gcc -Wall -c
LD=gcc

foo.o: foo.c
 $(CC) foo.c -o foo.o
bar.o: bar.c
 $(CC) bar.c -o bar.o
main.o: main.c
 $(CC) main.c -o main.o
app.executable: foo.o woo.o main.o
 $(LD) main.o foo.o bar.o -o app.executable

这个写出来,还是有“多余”的成份在,因为明明依赖中已经写了foo.o了,rule中还要再写一次,我们可以把依赖的对象定义为$@,被依赖的对象定义为$^(这是当前gnumake的设计),这样就可以进一步化简:

#sample3
CC=gcc -Wall -c
LD=gcc

foo.o: foo.c
  $(CC) $^ -o $@
bar.o: bar.c
  $(CC) $^ -o $@
main.o: main.c
  $(CC) $^ -o $@
app.executable: foo.o woo.o main.o
  $(LD) $^ -o $@

很明显,这还是有重复,我们可以把重复的定义写成通配符:

#sample4
CC=gcc -Wall -c
LD=gcc

%.o: %.c
 $(CC) $^ -o $@
foo.o: foo.c
woo.o: woo.c
main.o: main.c
app.executable: foo.o woo.o main.o
 $(LD) $^ -o $@

这终于短了吧。实际上,你要化简,还有很多手段,比如gnumake其实是默认定义了一组rule的,上面这个整个你都可以不写,就这样就可以了:

#sample5
LDLIBS=-lpthead
SRC=$(wildcard *.c)
OBJ=$(SRC:.c=.o)
app.executable: $(OBJ)

这里其实没有定义.o到.c的依赖,但gnumake默认如果.c存在,.o就依赖对应的.c,而.o到.c的rule,是通过宏默认定义的。你只要修改CC,LDLIBS这类的宏,就能解决大部分问题了。所以你又省掉了一组定义,这就可以写得很短。

我前面的博文中说到,构架设计具有存在性的。这是一个例子,其实在我们开始定义最初Makefile的语义的时候,最后软件会长成这个样子,已经是可预期的了。这就叫执古之道,以御今之有。


[头文件问题]

现在我们把问题搞得复杂一点,增加三个头文件。比如foo.h, bar.h和common.h,前两者定义foo.c和bar.c的对外接口,给main.c使用,common.h定义所有文件都要用到的通用定义(foo.h和woo.h中包含common.h)。这样前面这个sample1就有毛病了。照理说,foo.h更新的时候,foo.o和main.o都需要重新编译,但根据那个定义,根本就没有这个比较。

为了增加这个比较,我们的定义必须写成这个样子:

#sample4+
CC=gcc -Wall -c
LD=gcc

%.o: %.c
  $(CC) $< -o $@
foo.o: foo.c foo.h common.h
bar.o: bar.c bar.h common.h
main.o: main.c foo.h bar.h common.h
app.executable: foo.o bar.o main.o
  $(LD) $^ -o $@

(注:这个例子我们在.o.c依赖的规则中使用了$<宏,它和$^的区别是,它不包括依赖列表中的所有文件,而仅仅是列表中的第一个文件)

这就又增加了复杂度了——头文件包含关系一变化,我就得更新这个Makefile的定义。这带来了升级时的冗余工作。按我们前面考虑一样的策略,我们尝试在已有的名称空间上解决这个问题。Makefile已经可以定义依赖了,但我们不知道这个依赖本身。这个事情谁能解决?——把这个过程想一下——其实已经有人解决这个问题了,这个包含关系谁知道嘛?当然是编译器。编译器都已经用到那个头文件了,当然是它才知道这种包含关系是什么样的。比如gcc本身直接就提供了-M系列参数,可以自动帮你生成依赖关系。比如你执行gcc -MM foo.c就可以得到

foo.o: foo.c foo.h common.h

这样,剩下的问题是Makefile得先生成依赖本身,然后再基于依赖来生成文件。这样,我们可以把Makefile写成这样(为了简单,我直接用sample5来改了):

#sample5+
LDLIBS=-lpthead
CFLAGS+=-MMD -MP
SRC=$(wildcard *.c)
OBJ=$(SRC:.c=.o)
DEP=$(SRC:.c=.d)
-include $(DEP)
app.executable: $(OBJ)

CFLAGS中增加的参数可以为xxx.c产生xxx.d文件,里面就是那个依赖关系,然后我用-include包含这些依赖关系。这样就不再需要手工来写每个依赖了。为了解决这个问题,你已经看见了,include前面又增加了一个语法。那个减号表示允许被包含的文件不存在。

不仅如此,一旦引入这样的支持,我们就必须面对一个新的问题了:一开始foo.d不存在,Makefile所定义的依赖链是一个样子,等foo.d存在了,它又是一个样子。那make工具以哪个样子为准呢?

所以,这又引入了所谓的“remake rule”,决定了在什么时刻,make工具以什么为准。这个rule的细节,读者可以自己找手册看。大概的原理是make会第一次先认出所有的用于组成Makefile定义的文件,然后先make一次,等更新后,再做第二次的更新。名的复杂度,就是这样一步步建立起来的。“无中生有”的过程,在计算机软件领域其实表现得最为淋漓尽致。你说这个概念是本身就已经存在了,所以你定义出来了呢?还是因为你“发明”了它,所以它就存在了呢?


[autoconf]

然后我们接着处理下一个问题,因为我们有了Makefile,所以跨平台的问题就活该Makefile来解决了。跨平台要面对的是不同平台习惯不同的问题。这种问题一个解决方案是定义标准,比如POSIX。POSIX规定了,如果你要用malloc,你就应该包含stdlib.h。但你以为你是标准就是老大?我的平台就不包含stdlib.h,我就要包含alloc.h,怎么着?

你的编译器叫gcc,我的平台编译器就叫laozizuida_compiler,怎么着?

所以我们一开始会在Makefile前面包含一个文件,来生成这些定义,比如这样:

ifdef WINDOWS
  include windows_def.mk
#endif
#ifdef LINUX
  include linux_def.mk
#endif
...

这样弄得编译的人非常头疼。如果我们比较一下,这个问题和Makefile鸟关系没有,它是个“自动化宏定义”的问题。autoconf,就是从这个角度解决这个问题的。它的工作是生成一组脚本,自动检查要参与编译的目标平台的某些定义应该是怎么样的,这样编译的人就不需要去做那么多复杂的定义了,运行一下自动编译脚本就好了。

所以,如果你拿到一份基于autoconf的源代码,它的编译方法是这样的:

./configure
make

那个./configure取代了你手工设置参数过程,通过自动检查帮你设置参数。

autoconf相当于一个知识库,负责帮助你生成./configure。大部分gnu或者非gnu的开源项目都使用autoconf生成这个检查过程。如果你随便下载一个源代码,你会发现这个脚本写得相当复杂。为了生成这个复杂的脚本,autoconf为了你提供了一个更简单的语法——其实也不是什么简单语法了,它是通过m4这种宏语言,把你用宏写的脚本,变成这个configure文件。


用来生成configure的源文件叫configure.ac。这个东西的语法估计你也很难学。一般情况下,其实你也不用学。autoconf提供了一个工具,叫autoscan,它可以根据你的源代码,自动帮你生成一个模板,比如,在我这个空的只有foo,bar,main的工程中,它生成的模板就是这样的:

#                                               -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

AC_PREREQ([2.69])
AC_INIT([FULL-PACKAGE-NAME], [VERSION], [BUG-REPORT-ADDRESS])
AC_CONFIG_SRCDIR([bar.c])
AC_CONFIG_HEADERS([config.h])

# Checks for programs.
AC_PROG_CC

# Checks for libraries.

# Checks for header files.

# Checks for typedefs, structures, and compiler characteristics.

# Checks for library functions.
AC_FUNC_MALLOC
AC_CONFIG_FILES(Makefile)
AC_OUTPUT

这个语法都不怎么需要学,对着改就是了,前后的两段宏是用来生成configure的开头和结尾的,不要动,中间就放一堆的检查,检查结果会生成一组Makefile可以用的宏定义。

其中AC_CONFIG_SRCDIR是用来确定脚本是不是放在正确的源代码目录中的,所以输入参数是其中一个“肯定会有”的源程序即可。

AC_CONFIG_FILES用来定义进行宏转换的文件,脚本生成了一堆宏以后,会读入这里定义的文件,然后把其中的宏都替换掉。比如这里的参数是Makefile,脚本会找目录中的Makefile.in,然后把里面的宏替换掉,生成Makefile。剩下的事情会怎么样,猜都猜到了。

剩下的就是中间那些检查函数了,比如AC_PROG_CC用来检查gcc的名字,AC_FUNC_MALLOC用来检查malloc函数是否被支持,一般来说也不用学,因为autoscan会自动根据你的源代码找出来的。

把这个模板保存为configure.ac文件,然后执行autoconf,就会生成configure脚本,这样你就不用关心更多的跨平台的细节了。如果你修改过源代码,觉得自己调用了更多的库。可以重新运行autoscan,把新的,你觉得有用的检查也补充进去就可以了。

把上面这个过程画成一副图,就是这个样子的:

也许你已经注意到了,图中比我的描述多了config.h.in,这只是另一个类似autoscan的helper工具,辅助你生成不同平台上不同库函数宏定义的,你自己运行一下autoheader就明白了。


我们说了,configure.ac其实是基于autoconf预定义的宏写的一个脚本,所以,你在里面直接写脚本一点问题没有,比如,我有时会这样插一段进去:

...
AC_CHECK_LIB([ossp-uuid], [uuid_create], [OSSPUUIDLIB="-lossp-uuid"])
if test "x$OSSPUUIDLIB" = "x"; then
        AC_CHECK_LIB([uuid], [uuid_create], [UUIDLIB="-luuid"])
fi
if test "x$OSSPUUIDLIB$UUIDLIB" = "x"; then
        AC_ERROR([No uuid library available])
fi
LIBS="$LIBS $UUIDLIB $OSSPUUIDLIB"
...

AC_CHECK_LIB是autoconf的m4宏,它负责检查ossp-uuid这个库是否存在,如果它不存在,我可以用uuid,如果两个都不存在,我就报错。我需要的仅仅是autoconf的检查功能,其他东西要怎么弄,完全在我的掌控之下。

所以,这个用起来自由度其实是很高的,你会写脚本就可以了。autoconf只是个知识库,提醒你要主要跨平台的时候有什么要考虑的。你要自己增加什么检查,那是你的事情。整个脚本体系可以一步步完善的。要知道你的检查产生了哪些宏,运行一次configure,然后检查一下config.log就可以了,你会看到类似这样的东西:

## ----------------- ##
## Output variables. ##
## ----------------- ##

ACLOCAL='${SHELL} /home/kenny/work/hisi-repo/kernel-dev/samples/wrapdrive/missing aclocal-1.15'
AMDEPBACKSLASH='\'
AMDEP_FALSE='#'
AMDEP_TRUE=''
AMTAR='$${TAR-tar}'
AM_BACKSLASH='\'
AM_DEFAULT_V='$(AM_DEFAULT_VERBOSITY)'
AM_DEFAULT_VERBOSITY='1'
AM_V='$(V)'
AR='ar'
AUTOCONF='${SHELL} /home/kenny/work/hisi-repo/kernel-dev/samples/wrapdrive/missing autoconf'
AUTOHEADER='${SHELL} /home/kenny/work/hisi-repo/kernel-dev/samples/wrapdrive/missing autoheader'
AUTOMAKE='${SHELL} /home/kenny/work/hisi-repo/kernel-dev/samples/wrapdrive/missing automake-1.15'
AWK='gawk'
CC='gcc'
CCDEPMODE='depmode=gcc3'
CFLAGS='-g -O2'
CPP='gcc -E'
CPPFLAGS=''
CYGPATH_W='echo'
DEFS='-DHAVE_CONFIG_H'
DEPDIR='.deps'
DLLTOOL='false'
DSYMUTIL=''
DUMPBIN=''
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EGREP='/bin/grep -E'
EXEEXT=''
FGREP='/bin/grep -F'
GREP='/bin/grep'
INSTALL_DATA='${INSTALL} -m 644'
INSTALL_PROGRAM='${INSTALL}'
INSTALL_SCRIPT='${INSTALL}'
INSTALL_STRIP_PROGRAM='$(install_sh) -c -s'
LD='/usr/bin/ld -m elf_x86_64'
LDFLAGS=''
LIBOBJS=''
LIBS='-luuid -lsysfs -lpthread '
LIBTOOL='$(SHELL) $(top_builddir)/libtool'
LIPO=''
LN_S='ln -s'
LTLIBOBJS=''
LT_SYS_LIBRARY_PATH=''

该怎么用,也不用我说了。

我经常说,“也不用我说了”。这也是一种架构师习惯:但凡只剩下工作量的事情,就不再考虑,无论这个事情以后是我自己干还是让别人干。至少构架方面的工作是做完了。所谓架构设计,就是设计到怎么演进也不会有什么大风浪了为止。(但什么程度才不会有大风浪,取决于为你工作的工程师是什么水平和习惯)


[automake]

有了autoconf,检查工作简单多了,但Makefile.in还是不好写。所以,我们又有了automake,用来产生Makefile.in

automake用Makefile.am作为输入,生成Makefile.in。它提供了一个非常简单的语法,类似这样的:

lib_LTLIBRARIES=libfoo.la
libwd_la_SOURCES=foo.c bar.c common.h foo.h bar.h

bin_PROGRAMS=app
app_SOURCES=main.c
app_LDADD=.libs/libfoo.a

这个很简单吧:你要编译一个二进制,就把名字赋给bin_PROGRAMS,然后描述它的源代码是什么,剩下的事情全部交给automake。

automake依赖autoconf,所以对configure.ac的写法有一些额外的要求。我这里是介绍原理,不是介绍细节,所以这个读者随便搜索一下就能找到大把材料,简单试用一下就知道怎么弄了。

我这里更愿意讨论这样一个问题:语义其实就是这么一回事——你要简单,你就失去细节的控制,你要深入控制,你就要面对复杂度。所以,很大程度上,我们进行抽象,都是在两者之间取得平衡,并没有“完美”的方法。你脑子里想得特好的“美好生活”,到你亲自去体验的时候,你又觉得非常Boring。你的意愿,和你的好恶,并不重合。

所以,我们进行抽象设计,本质上是判断什么是使用者“不在乎”的部分,把那部分帮他选了。你的模块就产生对他的价值。所以,Unix这种插件、组合式的设计是有道理的。你什么都帮用户做了,总有他不满意的部分,每个都可以成为他把你整体放弃的理由。而分离的插件,则是一个个独立的“逻辑收缩”,你要收缩哪部分逻辑(不想管细节),就单独用那一个“逻辑收缩”就好了。至于更大规模的收缩,我们可以通过小逻辑组合出来。好比这个automake,如果你仅仅就是编译一个Unix上的应用程序,该有的都有了,但如果你要控制一堆自动生成的代码,它就不够看了,但这不影响你放弃automake,继续使用autoconf和makefile等的功能。

所以评论中有人问,为什么有cmake这么高级的工具,还需要学习Makefile。这就看你到底要控制到什么层次了。


[关于架构的进一步讨论]

Makefile相关的概念我介绍完了,我觉得大线条我描述完了,细节可以看工具手册本身,但如果读者觉得在大线条上哪里有不理解的,请提问,我再补充。

现在回到我想讨论的构架设计的问题上。

写程序是个精细控制的过程,至少现在如此。我们大部分程序员习惯了c=a+b,e=c+d这样一步步逻辑组合的过程。很容易忘掉,构架是个粗糙控制的过程,构架的说法常常只是“算一下这个多边形的面积”这种类型的。这听起来好像是种“老板要求”,在程序员看来是“技术白痴”的要求。而架构师和两者的区别在于,架构师需要满足老板(客户)的意欲,同时保证它是可行的。

所以架构师的思路(注:架构师也可以是程序员,当他进行架构设计的时候,我们认为他是架构师。我一直都在写代码,但我进行架构设计的时候,干的活和我写代码的时候干的活是完全不同的)和程序的思路是很不同的。这就好像你画一副画,打架子的时候和你细绘眼睛的时候是完全不同的。

架构师在打架子的时候,考量的是,一旦这个架子定义成这样了,我把钱洒到这个架子中,它最后会长什么模样。

软件首先是个工程问题,构架只是解决它“有机会成型”的问题,但工程上,你能否在每个阶段都让你的软件保持一定的“收益”,这才是它最后“能成型”的关键。而保持这种收益的关键就在于每波投资,都能产生“收益”,我们抛开商业收益这么远的东西,首先要解决一批人的问题吧。在我们介绍Makefile这套工具的过程中,我们看到了这种变化的过程:

一开始你仅仅解决“更简单地描述文件依赖”这个问题,然后你简化用户描述的过程,然后你加入自动平台判断,然后你加入“最简化描述Unix文件生成方法”……这每一次扩展,都是在迎合一波足够Solid的用户需要,然后才前进的。构架控制的整个过程,就好像冲浪,不是你有多用力去滑水去让滑浪板前进。而是你必须准备好,迎接下一个浪尖,浮起来,然后顺势滑下去的一个过程。

能让一个架构生存下去,是因为这样的需求压力,而不是“投资”,“投资”会导致你有钱,有钱就会任性,任性就会把钱投资在没有需求backup的功能上,比如说,假设这个automake拿到一个亿的投资,他们可以把这个功能做出花来,界面支持,用AI进行辅助脚本生成,等等等等。但为此也就解决一个生成Makefile.in,能持续养活这些人吗?


[总结]

总的来说,我想说的是,

第一,架构设计是存在的。前提是你注意到它,如果你进行增量设计的时候,从来都是推翻前面的概念空间来从新开始,当然注意不到它的存在

第二,架构设计的架子和架构维护的过程,是完全不同的两个思路。前者保证的是生存的可能性,后者是积累每一波的能力,浇灌到架子中,让它长起来。

所以,控制架构的过程,不是控制软件如你所愿的过程,而是一个捕获“现实世界如何”的一个过程。

「真诚赞赏,手留余香」
4 人赞赏
萧十一郎
刘典
上善若水
Zorro
文章被以下专栏收录
13 条评论
推荐阅读