编程时需要有两种状态：一种浮在表面，把握全局;另一种需沉入代码，就像潜水一样一头扎进去。两种状态缺一不可，且需要不停切换，把握全局需要深入代码内部，体查民情，了解各个对象需要什么接口，需要什么帮助，但一味深入代码，不浮到水面上透口气，把握一下全局脉络，就会迷失在代码海洋中，淹死掉。
在做大型一些的程序时，一定要做好两种状态的切换。如果代码超过万行，类种类超过30个，不做全局的设计，是非常危险的事，很容易就迷失在代码森林里，做设计需要全局思维，设计什么？设计类，设计类的接口，类的继承关系和组合关系。最好的武器是ＵＭＬ，只是建模，只是建立出代码的骨架，就像是一张地图一样，如果你拿着地图进入森林，就一定不会那么容易迷路。当然，如果你条件更好，还可以在UML的基础上更进一步，写单元测试，测试驱动开发就更安全了。UML建模和TDD是递进关系，写单元测试首先要有一套单元测试框架--ｘｕｎｉｔ,其次，在编写testcase之前，是需要先进行设计的，单元测试只是用一组断言将你的设计，你设计的类，你设计的接口进行确认。如果说UML是老虎，那单元测试就是给老虎添了翅膀。但单元测试的成本很高，第一需要工程师有非常深厚的功底，不然单元测试不但不能帮你，还会拖累你，第二工作量会翻一倍，不但要维护生产代码，还要维护测试代码，这其实对“设计”提出了更高的要求，如果设计得不好，那么生产代码和测试代码都需要频繁做改动。但事实上，代码的重构在所难免，所以在这个角度来说，单元测试反而会有避免不了的一些拖累。
在功力足够深厚以前，我建议单元测试可免，但UML一定不能免。UML的成本非常低，画个图非常快速方便，我相信就算不通过UML这种表现形式，工程师在编码以前一定还是会自己进行一下设计，只是很可能在纸上草草画了下，然后就丢掉了，没有以UML的形式保存下来。这样会有一个问题，就是如果没有UML这张地图的话，程序规模越来越大时，工程师自己都可能会迷失掉，更别说新加入进来的新人了。我想，架构师和普通工程师一个很重要的区别是，架构师无论何时都要有把控全局的能力，别人能乱，他不能乱，别人能只见树叶，他必须见森林，别人无法指导新人，他必须能！所以架构师在做一些选择时，权衡利弊不仅仅只看“代码性能”，“代码是否最精简”，他还需要考虑“可维护性”，“代码规范”，“一致性”，也许有的选择从局部看并不是性能最好的，也并不是代码最精简的，但从全局看，却是最能保证团队开发及维护成本最低的。
我并非鼓吹架构师的角色，在ｓｃｒｕｍ和ｘｐ中甚至提倡代码集体所有制，团队自管理，希望所有工程师一起为代码负责，我非常支持敏捷时的这些观点，只是做一个补充：架构师的角色非常重要，就算团队中每个人的能力都很平均，都很优秀，便也仍然需要一个人来做主导，主导代码的规范、画出UML图、分层分块，让全团队保持相同共识，劲儿往一处使，事半功倍。
编程的两种状态都需要锻炼，缺一不可，架构师更应如此。