《Delphi编程专家门诊》终于出版了。 ( 积分: 0 )

  • 主题发起人 主题发起人 soul
  • 开始时间 开始时间
我一定要买一本,虽然我穷一点,但我对高手们的敬仰,如滔滔江水.....支持正版!
 
呵呵,今天才知道,来晚了。 :)
 
去china-pub上定了一本,75折,第一个发表评论,应该今天拿到书
 
小雨哥:你做了这么多工作是有目共睹的,也写了好多篇文章,也是有案可查的。作为一个重要作者,当然应该拿一本,否则我这里的10本总不见得我个人做收藏品吧。呵呵,这个您就不要客气了。
稿费一事,我知道如果硬是要和谁怎么样算清楚,那其实也是对你们的不尊重,你们所花费的精力和热忱难以用钱来衡量,但是我不见得独吞吧,我总得有个交待吧,您如果觉得稿费这样处理您比较为难,那也最多是您授权给我处置他,并不代表是我的。这些钱也许我会用于一些网站的发展,服务器的维持,也许我会以大富翁网站的名义为大富翁做点功德,为大富翁积积福。总之,即便您不要,这也是只能是属于大富翁网站的。
小小雪:我正有此意,门诊那块工作做好了,我会给大家发消息的,我会尽可能把一些选题拓展出去。另外也会增加一些选题。这次的书因为出版社要求面对中低用户,而且主要是低端用户,所以很多地方确实言犹未尽。其他作者他们有时间也会参与到那些选题的扩展中来,当然大家都很忙,是不可能象专职一样工作的,所以在实效上难免无法保障,这点请大家原谅。
 
先给你们泼点凉水:
----这本书与市面上的书相比,好象没什么优点。大部分内容早就在其它地方见过了。
----就象市面上的许多书是垃圾一样,这本书也会成为垃圾。
大富翁应拿出有档次的东西来。自认为是的后果,看看论坛今日的人气就知道了。
 
虽然书没看,但先恭喜诸位作者,里面好几个家伙都是赫赫有名啊[8D]
只是看了目录,很遗憾,没有我想要的东东 [:(]
唯一感兴趣的是《附录A 莫迷信面向对象》,soul可否贴出来看看?最好是另开帖,届时估计会有一场龙争虎斗..............[:D]
 
  这个周末回家了,在省城的新华书店里翻了翻这本书,看的出是花了一定的心血的,书也是不错的.不过要成为经典恐怕不大可能,书的每个参与者的功底都是很高的,基本上都可以独立出书,大多的水平也估计比Nicrosoft要高,但是Nicrosoft的<Delphi高手突破>我想要比这本书要强.个中原因就不说了,就好比鼎鼎大名的"红皮书",业界有这么一种说法,封皮上的人物越少,书就越经典.
  至于说
"l 懒惰想少写点代码,结果却花费了大量无益的思考时间
常常会有这么一种情况,碰到一个问题,马上想到了一个解决方案,那个方案是最直接的,但需要写很多代码,不原意,于是拼命思考如何构造一个精巧的方法使得能花费很少的代码解决这个问题。在大富翁论坛上,经常可以看见提问者嫌回答者的答案代码太长,而反复问还有没有更简单的方法。并且一问就是很长时间,我很怀疑这些问题是否是为了项目,一个项目怎么经得起在这么一个小问题上如此耗费时间呢?我们这个时代不再是AppleII的时代,一个字节都可能要珍惜,CPU的速度也已经足够惊人,无需我们过分为速度担心,编程本身的效率才是我们该去关心的事情。"
还是不大同意,小雨哥的话也不大妥当,

“垃圾代码”和“直接了当的方案”的用词,是上述讨论出现分歧的根本。当你写一个问题的解决方案时,已经到了不加思索就可以用面向对象的方法完成解决方案的时候,你一定会同意书中的观点,就象现在有人告诉你:“数据无非就是内存中的一块空间”一样。""
"不加思索就可以用面向对象的方法完成解决方案"那的要多久啊,我所见的一个所谓的牛人,写程序写了7年了,还是把面想对象说的一文不值,写的代码也还是“垃圾代码”一堆,干了三个月让公司给开了,我的理解,
  如果你在入行时候或者是先期就养成了代码只是为了实现,Code大多就是Ctrl+c或者Ctrl+v来做成的,那么试问他又怎么会"不加思索就可以用面向对象的方法完成解决方案"呢?
  XP开发中有一条是"极限编程人员不允许他的程序中有重复的代码",试问你从来不对你的代码进行重构,那么如何才能达到"不加思索就可以用面向对象的方法完成解决方案"呢?
  再说了,如果程序只是为了实现而实现,那么学习设计模式又有什么用呢?
  Soul和小雨哥是我在论坛中很佩服的程序高手,尤其是看小雨哥的回帖学了很多,我是从半路转行过来的,磕磕碰碰一路走来,入行前看了不下20本的程序设计的书,大多数是垃圾,当然有我的原因存在,走了很多的弯路,回头想来,还是很生气.
  既然书是面对的入门和提升级别的,那么就应该从入门来考虑,"懒惰想少写点代码,结果却花费了大量无益的思考时间",入行的人很相信有经验的建议的,那么这个建议会带来多大的后果呢?请大家考虑
 
能不能不讨论水平高不高的问题?
除了电脑我们还需要一些其它的东西。
 
有一个朋友问到了这样一个问题:

在设计一个系统的时候,我常会想哪个类应该负责什么,做什么,需不需要其它类!
我不知道如何很好的地安排它们,怎样去做一个类,请问我该怎样做才能很好的设计呢?

我回复的时候是这样回答的:

非常典型的现象。
不能说这种思维本身有什么错误,但当把问题中“类”这个字改成“函数”,就会发现,这
个问题实际上是把面向过程的思维引入到了面向对象。
面向过程是我们解决一个实际问题时最容易想通的一种思维方式,如果才开始考虑改换思维
方式,beta提出的方法无疑是比较好的方法,也就是说,不需要把问题解析得水落石出,有
了一定的方向先动手做起来,船到桥头自然直。如果已经做了很多项目,思维依然是这样,
那只说明时机还没有到,暂时也就只能这样去思考,继续坚持,自然有一天豁然开朗。
为加快思维的改换,我建议你不要去考虑实现,改成考虑输出输入的逻辑,把真正的实现看
做已经完成的黑盒子(方块图),而着重分析这些个盒子的输出输入是否满足需要和是否恰
当。

有很多人喜欢这样去思考,即便是写代码写了很久。他不习惯脱离具体的代码去推理,他习
惯先有连接然后才能访问。这是一个思维习惯,因为符合我们的常规思维,大家都容易接受。
但这个思维本身不是面向对象的,要用这个思维去畅游面向对象,困惑在所难免。
正好,我还回答了另一个题目:

如何看待内存泄漏。

在下面的回答里,我没有误导的意思,但确实是我现在的做法:

很早的时候,我看到“内存泄漏”这四个字,就感觉我有义务去消除它,看了很多资料,也
尝试定量定性地去分析,直到表面上看不出泄漏为止。这样的习惯保持了很多年。
如今,我已经不太在意内存是否泄漏,因为我觉得,泄漏总是会存在,但99%的泄漏都不会
对程序造成妨碍,只有1%的泄漏会累积而造成麻烦,但当这个1%发生的时候,我自己几乎可
以明显地感觉到哪些代码发生了问题。
我知道忽视内存泄漏不是一个值得推荐的好习惯,但真的也不是太令人惊讶的习惯。程序代
码中的内存泄漏,严重时会妨碍程序的正常运行,尤其是长时间保持工作状态的程序,但是
这类程序为得到更好的运行,我常常向Microsoft学习:适当的时候重启工作进程,把内存
管理权返回给系统。

讲这些看起来与上面的讨论没有任何关系,但我确切地知道其中还是有些关系的。
 
网事如风:您好,本来觉得这里继续争论不太好,因为我正在制作书的论坛扩展部分,那里探讨会更好。不过既然您几次提到这个问题。我不妨说说我的真正的看法。
一篇文章总是有个主题的,那篇文章叫“编程的艺术”其中包含了对编程艺术的综合看法,因此文中某段总是要契合这个主题的。并不见得面面俱到。因为说实在的您说的并不是这篇文章主题,而是“如何学习编程”。关于这点,其实在另外一篇文章里面有更加声色俱厉的言辞。所以其实所有的讨论都是有其背景的,脱离开这个背景,很多问题自然有非常多的答案。这篇文章里面极力的告诫读者不要沉迷在局部技巧之中,并且局部技巧可能就是伤害全局的罪魁祸首,这才是重要的。
您所说的不妥,是否是如下的意思,一个学习编程的人,在设计一段程序的时候,要反复推敲,反复思考,反复修改,力求完美无缺。以此锻炼自己的编程技巧和能力,增长自己的经验和学识。如果您说的是这个,我非常赞成。当然,显然的,那篇文章不是谈如何学编程,而是就编程整体而言的。编程不是个人的玩具,他最终要服务于人类才是有价值的东西,正因为如此,他也必然和项目紧密结合在一起,否则也就不需要软件工程了等诸如此类的东西了。每个人只要精敲细打自己的程序就可以了。事实上绝非如此。程序确实需要精炼,但不能以整体效率为代价。这里有个价值平衡的原则。做个比方,如果学过机械的人都知道,任何一个东西都是有一定粗糙度的,并不是越光洁越好,只要在公差范围之内就好,这样可以到达实际应用的目的,同时产生最高的经济效益,即在合用的质量要求下,用最低的成本作事情,这个就是经济原则。或者也可以说是奥卡姆剃刀原则。经济原则也是爱因斯坦及其推崇的原则,本来嘛,这个宇宙的法则本来就是如此。总是会寻求一种最低的,最经济的方式去完成一件事情。最短路径也好,表面张力也好,能量守恒也好,都强烈地遵守这个原则。
说白了,效率最高的就是最优美和谐的。仿生学也就是学习动物如何效率最高。很多效率的产生是不可思议的。这就不多说了。同样对于编程也是。我们学习编程的时候为什么要尽可能地越精致越好呢?因为只有这样,你才能学到越多的东西,发现越多的问题,对知识的理解越透彻,对自己的能力提高越有帮助。但是在真的写程序,做项目的时候,需求、效率、成本就成为最重要的东西,程序没有实用价值是一无是处的,那么整体效益自然要远远大于局部的精巧程度,一个程序局部再精巧,使用者是感觉不到地,更何况,精巧和有效,和效率常常是对立的,这个时候,对于大多数学习编程,但还没有从学生气中脱离出来的人来说,几乎就是致命的问题。因此,那篇文章正是针对这种流弊的。
很多年来一直收藏了一篇文章,不妨一起贴出来给大家看看。警醒警醒。谢谢。

从一VC站点转贴的两篇文章,希望大家都看一下,思考一下。
这是第一篇:印度软件水平和中国的程序员
印度软件开发
我在工作中,接触到印度软件公司开发出来的软件:整个体系架构非常清晰,按照我们的要求实现了全部功能,而且相当稳定。 但是打开具体的代码一看,拖沓冗长,水平不咋样。我们自己的一些程序员就有怪话了,说他们水平真低。但是! 印度人能够把软件整体把握得很好,能够完成软件,并得到相当好的设计文档。而中国人在那里琢磨数据结构、算法,界面人员就还没编码就想着是Outlook式的 ,还是Visual Studio式的界面。到最后就成为Code高手,对某些特定的开发工具精通,但是就是不能保证能够把一个软件稳当、完整的开发出来。
举个简单的例子:软件中需要一个列表,用来表示我们处理的事务。该类表在业务繁忙的时候将变得很大。中国人就用双向链表,抱着《数据结构》书在那里写链表的类。 印度人开了一个大数组,然后就开始干。为什么印度人不用链表,他们说:1、你们给出的设备(小型机),最少具备512M内存,浪费一些没有什么。 2、数组方式访问方便、效率高。看出了一拿到东西就吭哧吭哧作Code,和好好进行软件分析的不同了吗? 正好前几天我有几个同事从印度回来和我们交流,那家公司是CMM4级公司. 我感受的几点:
1,流程重于项目
2,QC(就是QA)独立于研发部门,专门检查研发部门的开发流程是不是按照既定流程 走.如果QC觉得流程不对,他会直接上报高层,项目肯定就此停止.
3,所谓的项目经理(PC)一般也是从编码人员升上来的,并不是所谓的不懂技术,一般 都至少有四年以上的经验
4,PC主要就是制定开发计划,负责协调,填写各种表格.
5,所有的东西(包括草稿)都有文档.
6,详细文档要求达到只有这个文档就可以编码的程度,一般写文档时间占60%,编码 时间极少
7,有各种详细的review(同行评审),项目组内的,项目组之间的,客户的...
8,计划很详细,的确能达到小时级,但是实际情况还是误差比较大,所以他们也有加班.
先学习UML和Rose以及RUP,不要总是要找着证据。在中国的软件开发水平下,很难给你一个好的例子,OK? 中国人总是要看到一个东西有了试验田,而且稻子长得好,才换稻种。要知道在国外上述的软件开发模式的应用,大可以看看Rational网页上的story。 Justdo
it! 一句话,中国的软件开发水平低得很。 赶不上印度人,印度的软件公司可以让高中生编代码,它的软件工程水平可想而知。当然,你如果是个很牛的程序员。估计够呛,因为中国的气氛中,很牛的程序员都很难接受软件工程的。你可以测试一下自己,看看自己适不适合现在学习软件工程:
1、你是不是不能忍受一个编程序不如你的人做你的项目经理?
2、你是不是觉得你的老板对客户吹牛皮、夸大自己而感到不舒服?
3、你是不是一个拿到一个需求脑袋里第一念头就是如何实现的人?
4、你是不是很崇拜Stallman,Linus,很讨厌Microsoft?
5、你是不是曾经在深夜编码的时候,突然感觉到一种乏味,对Code的生涯感到一种无趣?
以管窥豹──印度神话 作者:"Kino"
我们现在处于深深的自卑当中,感到中国的软件工程水平的低下已经是牵涉到民族劣根 性的问题了。
1、他们的软件教育水平: 我们招聘印度人,给应聘者出了一份与国内差不多的试卷,有基础概念和编程题目。 等到他们完成后,我们这些中国的自认高手惊呆了!他们的编程题目简直象是抄袭的。 程序结构,注释,变量命名就不说了吧,全部都是极其类似! 反观中国的牛人、高手,每个人有自己的一套。到了新的岗位,先把前任的程序贬损一通,然后自己再开发更多的问题的代码来代替。我的公司统计,一个软件中有4个以上 CSocket版本,每个人都觉得 别人做得差,自己再搞一套。中国人,就是这个样子,还会辩解说“我们这样有创造性”。 其实软件发展,早就走过了求伯君那个编码英雄的年代,程序员已经是个坐办公室的蓝领了。你具备拧好一个螺丝钉的能力就可以了。Code是最低级的事情了。
2、他们许多公司的项目经理根本就不懂技术。中国的项目经理如果不能在技术上压服下属,那么下属将与他搞鬼,越是高手越喜欢搞鬼,根本不知道作软件的终极目的是从别人兜里掏钱,而在内部搞不团结。技术高手都会纠集一些对他技术上崇拜的菜鸟,与管理层作对。 而印度的软件经理根本就不懂正在做的东西,许多甚至直接就是MBA,或者是领域专家 (工业设计、地理专家等),而不是编码的专家。但是却能够领导大群素质良好的程序员把工作做好,没有内部不团结的情况。 许多印度的程序员加入一个公司很长时间,都不知道自己整天编的代码是干什么用的。 给他们的任务可能就是一个函数的声明以及该函数要实现的功能。我们呢?
3、他们的编程人员的流动率达到30%! 他们的编程人员流动率(包括内部项目之间的流动)高达30%,可以想见他们的文档水平如何。他们的产品不依赖任何一个人,谁都可以立即辞职,产品的开发还是会正常进行。而中国,是老板怕总工。技术骨干拥兵自重,抗拒管理。任何制定好的计划,都有可能被技术人员推翻或者跟你消极怠工。 4、他们的开发计划能够做到小时级别。 如果一个印度公司的项目经理没有上班,那么他的下属将可能不知道作什么。他们的计划一般都定到天,每个基层开发人员每天的工作量就是8小时。 而我们能够给出月度计划的公司就很少,而给出的月度计划要么不可能实现,要么就可能被取消。开发人员被初略的给个任务,他在月初,可以慢慢琢磨是做成什么样子,然后上上网,聊聊天。到了月中和月末,就开始熬夜编码。 看到每年,从各大高校不尽牛人滚滚来,我们是不得不要召人,同时又是不抱希望。我公司现在有意以后将核心软件开发外包给印度公司,中国人?做做界面吧,中国人做界面会极尽奇技淫巧,搞得花里胡哨的。 BTW,我公司非外企,大家不要误会我们有什么种族歧视。但是我们现在就是对自己歧视,自卑得很。中科院那么多研究院,连个能用的操作系统都搞不定。北大开发一些东西,比如什么青鸟CASE,就是给一帮人评职称的。杨芙清院士整天搞来搞去,搞出了什么东西?B大,T大的人最难管理,牛得看不见人。 中国的程序员骂微软,追Linux是全世界最恨得,可是我们除了汉化Linux,做了什么东西出来。CDE是瑞典人写的,Linus是芬兰的,GNome是墨西哥人写的。哎,我们曾经是多么的瞧不起印度人。

这是第二篇:程序员不是我得最终目标
【 原文由骄傲的中国人所发表 】就象 ken_qian 所说的 , “ 出了国门,大家都在变。”短短半年间,自己确实在观念上改变了许多。回想起来,以前在国内自己只是一部不停运作的编程机器, 整天写code,写code,写code,写code!一旦灵感一来,就想方设法地把所想的写出来,根本就没有考虑到编程以外的事情,结果,光是写出来的soucecode足用十几M,真是写得昏天黑地,日月无光!!:)可是,到了硅谷,情形突变!自以为能在鬼老面前,炫耀一下编程的能耐,好让他们对中国人刮目相看。可惜我错了!他们根本就不屑一顾!上的课多了,与不少在世界闻名的大电脑公司任职的教授也交谈过,发现自己是多么的无知,多么的肤浅。:(在上projectmanagement课时,已经明显体现出观念的差别。在上client/serveroverview时,更加突出了,整本教材(在这里这本书是专业人员必读的)没有一行code,几乎涵盖了现在所有流行的先进client/server(2/3-tiers)技术。从软件的角度分析它们的起源,发展和前途,还有各种功能相似技术的对比。整本书贯穿着一种思想,它与国内被绝大多数人奉行为至理名言的一句话-"不管黑猫白猫,只要抓到老鼠就是好猫!"--截然相反:“即使能抓到老鼠的黑猫白猫,也不一定是好猫!”。而这堂课的project就是做一个3-tierclient/server的项目,不用写code,只是要详细写出用到的结构和技术,为什么要用这而不用那?其实就是让你对各种相近技术进行详细比较,清楚地认识各种技术的优劣!!
短短半年研究生学习,与本科时确实是天壤之别。人家认为本科只是写code的时期,给出一个项目,只要能完成就算成功了。而到了研究生阶段,就要学会分析比较,对所用技术一定要能说出个道理:“在众多技术中,为什么你要选择这个?”还要经得起别人的“穷追猛打”。举个例子:抓到老鼠的黑猫白猫,白的一天能抓10只老鼠,而黑的只能抓5只,但是白的饭量很大,是黑的两倍。黑的比白的要便宜一倍。。。那么到底谁是好猫呢??:)象vcc所说的“程序员最重要的是思维能力,只有想不出,没有编不出”。在如今,internet流行,和控件泛滥的年代,对于大多数程序已经不是能不能写出来的问题了。我不是什么绝顶高手,也不是一个博学多才的人,有许多编程的问题还是不懂,但狂妄的说一句,现在只要能给我钻研上几天,长的几周,就没有什么不能编不出来的。可惜这有什么用呢,充其量只是一部编程机器。只会给人牵着走,整天做牛做马。这里培养的是具有大局观的人才,编程水平可能不高,但是活跃的思维,管理的能力和高瞻远瞩的眼界是我自愧不如的。就象BILLGATES当年若没有超凡的管理头脑,他现在可能也只是一部顶级的编程机器。对于中国,以前没有internet,资料奇缺。我以前学C++的时候,周围的人还不知道是什么玩意!靠的就是ONLINEHELP和以后的MSDN,想问别人,也没人懂!就象我在签名档所写的“孤身走我路...”。如今,internet的流行,我认为技术已经不是一个主要问题了,不懂的,上网查询,问人,什么最新的资料,sourcecode,控件应有尽有,还怕写不出来?!作为过来人,我只是想努力地把硅谷的一丁点文化,一丁点精神带给国内的同行。君不见,我所发表的每一长篇“大论”,全都是从大局出发,从观念出发,很少涉及到具体的编程代码。我也是中国人,我深知在“有中国特色”的制度下,硅谷的文化和精神是很难实现的。但是我总认为,虽然不能在现实社会中实现,但是可以在网上,在这虚拟的世界中营造一种气氛,使大伙能体会一下这种感觉。学C的毕竟是编程的正宗,有不少高手,而且是中国计算机业的中流砥柱。所以我选择了C版作为开始。可惜我错了,大家也许受现实工作生活的压力,在网上也不能够摆脱。就如我当年一样,“只是一部不停运作的编程机器”。
你们总是抱怨现实的中国怎样怎样,个人如何如何渺小。可是到了网上,到了这个自由的天地,根本没有什么污腐制度的束缚,什么文凭证书的限制,完全可以靠 大伙每个人的力量来实现,却不见有什么实际的行动。哈哈,怨天尤人有什么用,根本就不从自身找找原因,那么即使是给你一个很好的环境,一个很好的制度,结果又是怎样呢??我不希望这就是中国人的劣性,若是这样,我也无话可说了。写完这遍文章,我也累了。也许,不!应该是肯定会招不少人的反感,你们也许不屑一顾,也许破口大骂。不过我真的累了!!个人力量的确很渺小,要改变中国人的固有观念,的确不是我力所能及的。况且我本身也有许多不 足。也许就象国歌所唱的:“中华民族到了最危险的时候”,每个人才被迫“发出最后的吼声,起来,起来,起来!! 。。。”最后,还是象我在签名档所写的:“孤身走我路...”Goodnight,everybody!
/Crazyjava孤身走我路... 其实,路,两个人一起走比一个人要好
 
讨论做好了,大家可以在那里提问了。
http://www.delphibbs.com/book/subject.asp
 
这本书好多地方都没卖的
 
希望出一些口袋系列书.就一个专题写一本小册.价格九,十元所左右最好.让读者几天内完全钻透这一个主题涉及的问题.即然是大富翁出书,可以事先在网站上征集一下那一部分或一类问题,甚至那一个问题,网友们最需要补养,然后出一本相关的小册子,最终形成系列.这样前景非常广,可以是一个大的或都关心的第三方控件,也可以是一个非常基础的问题或是一个完整项目的剖析.现在买书最头终的是好书本来就不多,而且有时为了几个精采的章节而买书,而又不得不硬着头皮去读一下,"DELPHI是宝兰公司开发出的...."这类见过N遍的字样.但不知道出版从经济利益角度怎么看.
 

Similar threads

D
回复
0
查看
2K
DelphiTeacher的专栏
D
D
回复
0
查看
2K
DelphiTeacher的专栏
D
S
回复
0
查看
3K
SUNSTONE的Delphi笔记
S
D
回复
0
查看
1K
DelphiTeacher的专栏
D
后退
顶部