不要把简单的事情搞得N复杂（例1）

题目：用java写一个程序，打印如下图形

*

**

***

****

*****

请思考三钞钟，写下你的程序，然后看答案。

 

 

 

我刚毕业时的答案：

package com.albertsong;

/**
 * 
 * @author Albert
 *
 */
public class PrintStar {

	public static void main(String[] args) {
		for(int i=0;i<5;i++){
			for(int j=0;j<i+1;j++){
				System.out.print("*");
			}
			System.out.println();
		}
	}

}

现在的答案：

 

package com.albertsong;

/**
 *
 * @author Albert
 *
 */
public class PrintStar {

    public static void main(String[] args) {
        System.out.println("*\n**\n***\n****\n*****\n");
    }

}

 

 

看到这里，同学们肯定有话要说了。

 

我也有话要说，我想说的是：“与人方便，自己方便”。

 

仅就这个题目而言，显然第二个程序要好得多，它实现了和第一个程序一样的功能。无论从代码行数，还是容易理解的程度，第一个程序都无法与之相比。

 

讨论1：

M：第一个程序更容易修改，扩展，适应性更强。如果要打印下面的图形，

*

**

***

...

*****...***（注：第100行有100个）

改第二个程序还不累死？

A：如果第二天客户要打印的是下面这个图形呢？

*

**

***

* **

*** *

M：变态！%^&*

A：没有变态的客户，只有懒惰的程序员。

 

 

讨论2：

1）

A：到目前为止，这样的图形最多有几行？

G：十行吧

A：随着贵公司的发展，有可能到一百行吗？

G：当然是希望越多越好，但按公司目前的情况，十年之内不太可能。

G：但我们有可能调整业务，那时图形可能会变。

A：变了的话应该还是有一定规律的吧

G：那当然，也不能胡乱调阿，结果基本上不是正三角形就是倒三角形，最多会变成菱形。

2）

A：需不需要能够打印一百行，或者一千行的？

G：不需要，这个图还是昨天拍脑袋出来的，先给我打出来看看效果

A：会不会有中间哪儿少个*号的情况

G：你先别管这么多，先把目前这个问题解决了，中间会不会少*号这会儿还不知道。

 

讨论3：

T：本来想招个学过Java for循环的程序员阿

A：我们下回是不是把题目改成“用java写一个程序，打印如下图形（请使用for循环）。

 

现在到底哪个程序好，应该比较清楚了吧。

“不要把简单的事情搞得N复杂”，这句话是针对结果，而不是针对过程的准则。

前几天在闲聊中写道：不要解决不存在的问题，我想更为准确的说法是：不要解决了不存在的问题。

 

路人甲：哦，懂了，但是，这和前面说到的“与人方便，自己方便”有什么关系？

A：没有一毛钱的关系，如果“认真分析需求，为客户着想”这种理念高尚得让你有点儿难受的话，不妨想想，这样做，实际上可以为自己省下看毛片的时间呀，对不？

 

评论

44 楼 pufan 2009-04-15  

rubynroll 写道

要我说,还是curl放心.就一行代码能搞定的事,整那么多干啥?

搭个鸡窝怎么都无所谓，要盖大楼就斟酌斟酌了。

43 楼 wangxin0072000 2009-04-15  

绝对抬杠贴。

42 楼 rubynroll 2009-04-15  

pufan 写道

多说无用，还是上代码
Java代码 public class ThreadUtilities {      private static final ExecutorService pool = Executors.newSingleThreadExecutor();      public static void notify(final String url) {          pool.submit(new Callable<Void>() {                @Override              public Void call() throws Exception {                  URL l = new URL(url);                  HttpURLConnection connection = (HttpURLConnection) l.openConnection();                  connection.setConnectTimeout(5000);                  connection.setReadTimeout(30000);                  connection.connect();                  return null;              }          });      }  }  public class ThreadUtilities {
private static final ExecutorService pool = Executors.newSingleThreadExecutor();
public static void notify(final String url) {
pool.submit(new Callable<Void>() {

@Override
public Void call() throws Exception {
URL l = new URL(url);
HttpURLConnection connection = (HttpURLConnection) l.openConnection();
connection.setConnectTimeout(5000);
connection.setReadTimeout(30000);
connection.connect();
return null;
}
});
}
}

这段代码在极端情况下会存在n个Callable对象，curl方案会存在n个curl进程（线程）。

那个方案比较放心，大家评一评。

要我说,还是curl放心.就一行代码能搞定的事,整那么多干啥?

41 楼 pufan 2009-04-15  

night_stalker 写道

肉饼的方案出了意外能处理，你的出了意外没法处理。（这是10行代码么？还不包括调用呢……）建议你写个监控脚本或者写个监控程序。

出了意外最多log一下，加上try catch及调用也就是十行左右的代码。

为什么要监控呢，监控什么？通知搜索引擎失败就失败了，无所谓。

40 楼 王者之剑 2009-04-15  

pufan 写道

这段代码在极端情况下会存在n个Callable对象，curl方案会存在n个curl进程（线程）。

那个方案比较放心，大家评一评。

但是javaeye网站是用ruby做的阿，用java写个程序还得用ruby去调用。

39 楼 night_stalker 2009-04-15  

pufan 写道

这段代码在极端情况下会存在n个Callable对象，curl方案会存在n个curl进程（线程）。
那个方案比较放心，大家评一评。

肉饼的方案出了意外能处理，你的出了意外没法处理。
（这是10行代码么？还不包括调用呢……）

建议你写个监控脚本或者写个监控程序。

38 楼 pufan 2009-04-15  

多说无用，还是上代码

public class ThreadUtilities {
	private static final ExecutorService pool = Executors.newSingleThreadExecutor();
	public static void notify(final String url) {
		pool.submit(new Callable<Void>() {

			@Override
			public Void call() throws Exception {
				URL l = new URL(url);
				HttpURLConnection connection = (HttpURLConnection) l.openConnection();
				connection.setConnectTimeout(5000);
				connection.setReadTimeout(30000);
				connection.connect();
				return null;
			}
		});
	}
}

这段代码在极端情况下会存在n个Callable对象，curl方案会存在n个curl进程（线程）。

那个方案比较放心，大家评一评。

37 楼 night_stalker 2009-04-15  

to pufan：
你可能认为你的做法很完美，发射后不用管了，ok，恭喜你，你推翻了图灵机停机判定定理！

36 楼 pufan 2009-04-15  

night_stalker 写道

你分明是双重标准，curl你不放心，脚本你不放心，ruby你不放心，操作系统你不放心，估计你对机房管理员也不放心 ……

一条curl当然放心，但是n条呢，nn条呢。

35 楼 night_stalker 2009-04-15  

pufan 写道

你直接说用java不放心得了，嗯，目前最强的企业级开发语言不够您放心。

你分明是双重标准，curl你不放心，脚本你不放心，ruby你不放心，操作系统你不放心，估计你对机房管理员也不放心 ……

34 楼 pufan 2009-04-15  

night_stalker 写道

pufan 写道
java(单线程+队列):十行代码(放心运行，无需监控报警)一点都不能放心，你得把整个 jvm 运行时仔细检查一遍才行。不…… 很多遍都不够……

你直接说用java不放心得了，嗯，目前最强的企业级开发语言不够您放心。

33 楼 night_stalker 2009-04-15  

pufan 写道

java(单线程+队列):十行代码(放心运行，无需监控报警)

一点都不能放心，你得把整个 jvm 运行时仔细检查一遍才行。
不…… 很多遍都不够……

32 楼 pufan 2009-04-15  

监控另加报警

王者之剑 写道

你说的问题，确实存在，但不是robbin要解决的问题。就好比robbin说我骑自行车上班挺好的。你也不管人家上班到底有多远，居住附近的交通状况，就在那儿列举坐公汽或者坐地铁或者开私家车的好处。并且宣布：坐地铁上班是最好的，又快又经济，我上班就是坐地铁，骑自行车还不累死。请仔细看我的文章，前两个字就是“题目”，robbin的第二个回贴也严格地限定了问题的所在。

其实我想表达的在于对简单的认知，是本质上简单还是形式上简单。

对于前者要推崇，但对于后者就要洞悉简单下所隐藏的复杂。

31 楼 potian 2009-04-15  

You Aren'T Gonna Need It

30 楼 王者之剑 2009-04-15  

pufan 写道

night_stalker 写道
一行代码的健壮度是十行代码的十倍。你说的问题只是你想象中的，你真实遇到过么？

那要看一行代码调用了几行代码，麻烦你把curl的代码行数算一下。

生产环境中确实遇到过，不过不是调用curl。

你说的问题，确实存在，但不是robbin要解决的问题。

就好比robbin说我骑自行车上班挺好的。
你也不管人家上班到底有多远，居住附近的交通状况，就在那儿列举坐公汽或者坐地铁或者开私家车的好处。
并且宣布：坐地铁上班是最好的，又快又经济，我上班就是坐地铁，骑自行车还不累死。

请仔细看我的文章，前两个字就是“题目”，robbin的第二个回贴也严格地限定了问题的所在。

29 楼 pufan 2009-04-15  

night_stalker 写道

一行代码的健壮度是十行代码的十倍。你说的问题只是你想象中的，你真实遇到过么？

那要看一行代码调用了几行代码，麻烦你把curl的代码行数算一下。

生产环境中确实遇到过，不过不是调用curl。

28 楼 Army 2009-04-15  

哈哈，这样是很爽！

27 楼 night_stalker 2009-04-15  

pufan 写道

够简单，但不见得健壮。

大并发的情况，特别是当网络拥挤时，http请求很可能造成线程占用过多从而引起系统资源不足。

用ruby，curl看上去简单，但实现是怎样的谁知道：是后台单线程还是多线程、是否和其他模块共用线程池等等，这些都可能会引发潜在问题。

如果用java，做法就是将请求放入队列，后台单线程轮询执行（看起来挺复杂，其实就是线程池+URL十行代码搞定），虽然没ruby代码少，但用得放心不是。

一行代码的健壮度是十行代码的十倍。

你说的问题只是你想象中的，你真实遇到过么？

26 楼 pufan 2009-04-15  

另外补充一下，java的socket默认超时是0（永远不超时）。

25 楼 王者之剑 2009-04-15  

pufan 写道

大并发的情况下，多线程执行堵塞IO是有隐患的，这是一个基本常识，解决方式无非有
1）用非阻塞IO替代
2）实时需求不高的情况下，用单线程队列轮训

交给操作系统就健壮，估计很多人有这种误区，难道操作系统不是代码写出来的，更何况一个curl命令了。

请教一下，何谓大并发？
或者说大到什么程度，这个隐的患就出来了？
或者说你曾经实践过什么样的案例？

然后再看看发这个ping请求是不是需要用你的方法。