zeuux-universe  - 讨论区

标题:[zeuux-universe] [TopLanguage] Re: {编程}IDE综合症

2008年09月27日 星期六 11:53

Zoom.Quiet zoom.quiet在gmail.com
星期六 九月 27 11:53:06 CST 2008

2008/9/27 Kenny Yuan <yuankaining在gmail.com>:
> 我提一个另外角度出发的观点:楼主反对的这种趋势需要正视,并提供更多支持,或者叫引导。
>
有什么样儿的用户就有什么样儿的平台,
不过,平台也是人创造的,必然就带了不同的价值取向,
总体来讲,IDE 面向的是习惯了 Windows 的用户群,支持的目标就是快速的通过即有丰富模块的支持,完成事儿;
  但是具体程序在干什么,"开发者"知道的越少越好,
  强调的是模块仓库的魔法体验;
  以便对 IDE 和模块供应商形成长尾收益;
纯文本编辑环境,面向的是有一堆自个儿模块的程序员,帮助他们理性的快速调配出知根知底的软件/新模块出来,强调的是开发者的创造力;

> 其实不管做什么,哪个行业,都会有一些人持更"敬业"的态度,或者叫"专业"、"本来"等等,反正就是对人要求很高的那种。
> 但是大量的这样的人(用户)会"劫持"技术的发展方向,快餐化和初级用户虽然"可笑",但是数量上却不可忽视。
>
> 我举几个例子:
>
> 手动曝光系统-->自动曝光系统
> 手动对焦镜头-->自动变焦镜头
> 强大的命令行界面-->GUI
> 专业的图像编辑工具-->快餐式的图像处理软件
> 手动档汽车-->自动档
> MAKEFILE-->IDE
> ……
> 等等等等
>
> 一开始,后者都是发展得很不完善,被许多持传统论调的人所"耻笑"。但后者的发展会慢慢超越前者,有时是在用户数量上超越(比如GUI),有时是则在技术上超越了。
>
> 最终的结果是,厂家、标准委员会等都无法忽视这一大批用户的存在,向其妥协。
>
> P.S. 我曾经会写qt的makefile,但是现在我只会用qmake了
>
> 2008/9/27 Linker <linker.m.lin在gmail.com>
>>
>> 个人觉得微软的邪恶之处就在于把IDE做得很好用,从而绑定了很多程序员到windows平台.
>> 其实用惯了命令行,感觉是非常的好的.
>> 我现在主要用: cmake vim lua python 来干活.
>> 感觉不错.
>>
>> 2008/9/27 莫华枫 <longshanksmo在gmail.com>
>>>
>>> http://blog.csdn.net/longshanks/archive/2008/09/27/2986548.aspx
>>> ==============================================
>>>
>>>
>>> 前些日子猛然间接到开发POS机的任务。没有完整的IDE,索性就学着用vim,也算是技能锻炼吧。没几天,就看到了两位大牛在blog里展示无鼠标的魅力(这个,这个,这个,和这个,这个,这个,这个)。特别是风云,直接告诉我们不依赖于IDE的方法和好处。令人震撼。从另一个角度来看,不依赖于IDE带来的不光是方便、简洁,以及geeky。更重要的,它将使得我们打下更扎实的基础。而那些离了IDE就活不成的人,总存在着一些缺陷。
>>>
>>> 在开发POS机之前,我正在做web的项目。既然是web,用javascript更加合适。由于行事仓促,没来得及找一个合适的javascript
>>> IDE,所以就直接借用vs的编辑器编写js代码。vs
>>> IDE的intellisence做的颇为出色。但是这仅限于C#、VB、C++等主要语言。对于javascript(ms叫它JScript),几乎
>>> 没有任何auto-complete功能。我还比较适应,因为过去在vc5以前没有这类功能。即便vc6,auto-complete也时有时无,至今
>>> vc9依然如此。(拜C++那non-lalr语法所赐,似乎没有希望得到完全的auto-complete了)。但是,我身边的几个程序员则不停地向我
>>> 抱怨,没有auto-complete太不方便了。一开始,他们甚至有些手足无措。
>>>
>>> 于是,我告诉他们,不要太依赖IDE,特别是auto-complete功能,要学会多看文档...。说完这些话,我开始留意身边程序员的行为。结果发
>>> 现,他们拥有强烈的,用IDE替代文档的倾向。每当他们需要一个功能,又不知道该用什么函数的时候,便找到相应的对象或类(C#),在后面打上个".",
>>> 然后等着。等到成员函数列表显示出来,便在里面搜索,看看有没有符合要求的函数或属性。如果找到一个名字看上去像的,就选中它,看看
>>> intellisence列出的说明。如果有函数的参数不知道,就打上括号,看提示。根据参数类型和参数名猜测参数的含义。
>>>     这种做法本身并没有什么太大的问题,我自己也经常这么做。但是,根本的差别在于,我一般都用过这些函数或属性,只是时间长了忘记了函数名或参数。
>>> auto-complete起的是助记和辅助的作用。auto-complete原本也应该是这个作用。对于从未用过的,或者不清楚功能的函数或属性,我
>>> 基本上还是先看文档,了解函数或属性的具体含义和用法后,再使用。但很多在先进的IDE里泡大的程序员们,却并非如此。他们把auto-complete
>>> 功能当成了百科全书,反倒是很少看文档。
>>>
>>> 有人会说,既然auto-complete提供了函数的介绍,参数的类型和介绍,对于编程而言已经足够了,没有必要再浪费时间看文档了。但是,这种想法是
>>> 绝对错误的、危险的,甚至会要命的。对于一个类型、函数、属性、参数而言,文档并非仅仅提供了名称和大致含义。而是提供了完整的说明、注意事项、参数/返
>>> 回值的详细说明和规约,以及更加重要的异常特性和线程安全性。所有这些都是无法容纳在auto-complete的狭小说明空间里。
>>>
>>> 有经验的程序员,往往非常关注参数/返回值的规约(契约)、异常特性和线程安全性。这些地方往往是藏污纳垢的地方。对于参数/返回值处理不当,往往引发意
>>> 想不到的错误。比如一个参数不允许null指针。在通常情况下传入的实参都有效,但在很偶然的情况下,一个null传了进来,于是引发了程序崩溃。如果程
>>> 序员提前对null作出处理,便可以避免这类问题。有些函数对与null字符串和空字符串的处理是不一样的。比如.net
>>> framework中IXPathNavigate的GetAttribute()方法,第二个参数是namespace,如果用null字符串,则不会
>>> 得到所需的结果;如果用空字符串,则能够得到正确的结果。在复杂程序中这种错误往往非常隐蔽,是最佳bug候选人。
>>>
>>> 异常特性决定了一个函数对于非正常情况的处理方式。很多新手往往忽视异常。实际上,一个函数的异常有时是正常的,比如一个文件不存在的异常抛出时我们可能
>>> 不认为它是错误,而是一个提示,我们可以据此创建一个文件;而另一些情况下,异常却是错误,比如参数无效。更有甚者,一个异常有时是错误,有时则是正常流
>>> 程的一部分。这些东西往往需要细心处理,以免在客户面前出洋相。
>>>     至于并发特性,毋庸置疑是绝对不可忽视的。可以想象,几个线程在一个线程不安全的函数里能制造出多大的混乱。更何况这些混乱很难调试。
>>>
>>> 过度依赖IDE也造成了程序员的"营养不良"。对于程序的调试,他们只知道使用debuger,甚至不知道log也可以用于调试,而且应用范围更广。我曾
>>> 经问一个C#使用多年的老程序员,.net上有没有log库。他告诉我一个.net内置的,我一看,这不是调试用的log库,而是访问windows系统
>>> log的几个类。他根本就不明白log库是什么东西。
>>>     至于其他的方面,IDE综合症还有很多症状,我就不多说了。如果细心观察,我们都会发现很多这样的现象,也能发现其中的弊病。
>>>
>>> 客观地讲,IDE是个好东西。但是对于程序员,特别是新手,过度依赖IDE会造成不良的后果。我们永远应该把IDE看作一个辅助的工具,而不是唯一的编程
>>> 编程平台。而对于一个新手,应当尽可能地减少IDE的使用量。特别在练习的时候,更应当放弃IDE,而更多地锻炼编程时的自主控制能力。



-- 
http://zoomquiet.org'''
过程改进乃是催生可促生靠谱的人的组织!
PE keeps evolving organizations which promoting people be good!'''
[HR]金山软件常年招聘大量Py/C++人才!
https://groups.google.com/group/python-cn/web/ot-py-c
简历直投俺就好;-)

[导入自Mailman归档:http://www.zeuux.org/pipermail/zeuux-universe]

2008年09月27日 星期六 12:23

Xia Qingran qingran在zeuux.org
星期六 九月 27 12:23:50 CST 2008

Zoom.Quiet wrote:
> 有什么样儿的用户就有什么样儿的平台,
> 不过,平台也是人创造的,必然就带了不同的价值取向,
> 总体来讲,IDE 面向的是习惯了 Windows 的用户群,支持的目标就是快速的通过即有丰富模块的支持,完成事儿;
>   但是具体程序在干什么,"开发者"知道的越少越好,
>   
这些工具并没有阻止开发者去探索内部的秘密,只是看使用者如何去使用了。
比如安装了 M$ Visual Studio后就也同时安装了MFC的源代码,只是很少有人去看 
罢了。
>   强调的是模块仓库的魔法体验;
>   
上面这两条在编程工具的发展上很常见。
越来越多的易学易用的动态语言(python、ruby...),越来越多易用、快速的开 
发框架都是这两点的体现。

>   以便对 IDE 和模块供应商形成长尾收益;
> 纯文本编辑环境,面向的是有一堆自个儿模块的程序员,帮助他们理性的快速调配出知根知底的软件/新模块出来,强调的是开发者的创造力;
>
>   
>> 其实不管做什么,哪个行业,都会有一些人持更"敬业"的态度,或者叫"专业"、"本来"等等,反正就是对人要求很高的那种。
>> 但是大量的这样的人(用户)会"劫持"技术的发展方向,快餐化和初级用户虽然"可笑",但是数量上却不可忽视。
>>
>> 我举几个例子:
>>
>> 手动曝光系统-->自动曝光系统
>> 手动对焦镜头-->自动变焦镜头
>> 强大的命令行界面-->GUI
>> 专业的图像编辑工具-->快餐式的图像处理软件
>> 手动档汽车-->自动档
>> MAKEFILE-->IDE
>> ……
>> 等等等等
>>
>> 一开始,后者都是发展得很不完善,被许多持传统论调的人所"耻笑"。但后者的发展会慢慢超越前者,有时是在用户数量上超越(比如GUI),有时是则在技术上超越了。
>>
>> 最终的结果是,厂家、标准委员会等都无法忽视这一大批用户的存在,向其妥协。
>>
>> P.S. 我曾经会写qt的makefile,但是现在我只会用qmake了
>>
>> 2008/9/27 Linker <linker.m.lin at gmail.com>
>>     
>>> 个人觉得微软的邪恶之处就在于把IDE做得很好用,从而绑定了很多程序员到windows平台.
>>> 其实用惯了命令行,感觉是非常的好的.
>>> 我现在主要用: cmake vim lua python 来干活.
>>> 感觉不错.
>>>
>>> 2008/9/27 莫华枫 <longshanksmo at gmail.com>
>>>       


-- 
夏清然
Xia Qingran
E-mail: qingran at zeuux.org
Gtalk: qingran.xia at gmail.com
MSN: supermanxqr at msn.com


[导入自Mailman归档:http://www.zeuux.org/pipermail/zeuux-universe]

如下红色区域有误,请重新填写。

    你的回复:

    请 登录 后回复。还没有在Zeuux哲思注册吗?现在 注册 !

    Zeuux © 2024

    京ICP备05028076号