好的代码应该方法不过十行,类不过百行.......好的命名是好的开始...
一个最小层次方法只做一件事,一个较高层次的方法应该是把最小层次方法的调用。
把方法划分到很小很小,一方面是为了代码的重用,另一方面是为了写代码的时候,思路清淅。
我们总要求写需求文档的人,把需求文档写得更细,让我们这些开发人员看得懂。
我觉得我们开发人员也应该写一份代码流程文档,以 方法名+方法作用的形式,
把自己代码想做什么的意图写出来。
虽然我们有了注释,也可以通过 Open Declaration去追踪,
但是,一个流程走向的大纲还是得有的。
以上的建议,就我看来,带来的最大问题是,就是方法太多,类太多了。
而方法太多,类太多会导致想知道这些类和方法有什么用得慢慢的找出注释看。
这样,一个个注释看,也会使看代码的人消耗太多时候。
一个有经验的程序员写出的代码,比没经验的程序员写出的代码要好,很大方面是因为命名。
有经验的程序员知道怎么命名才令别人一看就知道这些类是干什么用的。
没经验的程序员在简单的系统,较少量的类的编写时,也能根据JDK命名规范得出不错的命名。
但当遇到大系统时,元素众多,类众多,在命名划分得更细了。没经验的程序员就不注意了,随便起。
我认为,一个有经验的程序员,他的能力表现在把一个系统,把一堆事物分得足够细,
然后有清淅的思路,把各个细的事物做好,通过思路的连通,就成了一个强大的系统。
这就回归到我们做事的方法了。
再讨论下来,就上升到哲学的高度了,呵呵.....
一个最小层次方法只做一件事,一个较高层次的方法应该是把最小层次方法的调用。
把方法划分到很小很小,一方面是为了代码的重用,另一方面是为了写代码的时候,思路清淅。
我们总要求写需求文档的人,把需求文档写得更细,让我们这些开发人员看得懂。
我觉得我们开发人员也应该写一份代码流程文档,以 方法名+方法作用的形式,
把自己代码想做什么的意图写出来。
虽然我们有了注释,也可以通过 Open Declaration去追踪,
但是,一个流程走向的大纲还是得有的。
以上的建议,就我看来,带来的最大问题是,就是方法太多,类太多了。
而方法太多,类太多会导致想知道这些类和方法有什么用得慢慢的找出注释看。
这样,一个个注释看,也会使看代码的人消耗太多时候。
一个有经验的程序员写出的代码,比没经验的程序员写出的代码要好,很大方面是因为命名。
有经验的程序员知道怎么命名才令别人一看就知道这些类是干什么用的。
没经验的程序员在简单的系统,较少量的类的编写时,也能根据JDK命名规范得出不错的命名。
但当遇到大系统时,元素众多,类众多,在命名划分得更细了。没经验的程序员就不注意了,随便起。
我认为,一个有经验的程序员,他的能力表现在把一个系统,把一堆事物分得足够细,
然后有清淅的思路,把各个细的事物做好,通过思路的连通,就成了一个强大的系统。
这就回归到我们做事的方法了。
再讨论下来,就上升到哲学的高度了,呵呵.....