从编程语言到框架的转变

时间:2023-02-11 21:57:58
个人感悟 - 简述
================
相信很多人一开始都是从原始Hello world程序开始, 从某种意义上也说明了编程语言的选择和重要性,
于是, 我们开始漫步在结构化程序设计中, 开始将自已的逻辑思维溶入代码中, 从本质上讲, 这个时代是编程时代.
终究, 编程语言将逐渐靠近人的思想语言, 所以,
再到后来, 我们开始使用成熟的框架工具, 帮助我们解决更为复杂的现实世界问题, 这是软件开发时代.而使用不同结构的框架和设计模式,
其实也就是最大限度的接近和满足人类的行为方式.
相信现在很多朋友早已经跳出了编程语言的束缚,开始在思考开创一种新的软件开发思维模式, 或者, 利用已有的框架平台在作更多的延伸.

118 个解决方案

#1


时间有限, 等我有了新想法再继续 : )
欢迎大家指正, 也希望起到一些抛砖引玉的效果.

#2


sf

#3


#4


这个主题太大了
up...

#5


学习!

#6


引用 4 楼 walkbywind 的回复:
这个主题太大了
up...

是大了点, 不过本帖不限于这个主题.

#7


大胆预言:以前是物理的天下,以后是生化的天下。程序和现有的硬件架构放到下一个5K年来看,就像我们现在看猿使用树叉捅白蚁窝。当人造出的东西运行效率和内存可以与人的大脑相媲美时,人造人将成为现实,当超越人的大脑时,... ...

PS: 不要扔砖头啊,就当我胡说八道-..-

#8


引用 7 楼 hxyman 的回复:
大胆预言:以前是物理的天下,以后是生化的天下。程序和现有的硬件架构放到下一个5K年来看,就像我们现在看猿使用树叉捅白蚁窝。当人造出的东西运行效率和内存可以与人的大脑相媲美时,人造人将成为现实,当超越人的大脑时,... ...

PS: 不要扔砖头啊,就当我胡说八道-..-

说得好啊!能不能摆脱框架的束缚,进入下一代软件开发的新模式呢?

#9


我要一个Windows,就出来了一个Windows操作系统

#10


记得以前看过一个小品叫:【跑题】

……

#11


引用 10 楼 zaodt 的回复:
记得以前看过一个小品叫:【跑题】

……

吹牛也行啊,呵呵

#12


??

#13


嗯嗯。。。所以我也蛮喜欢Javascript的,JS这个脚本虽然没有类,但是面向对象的味道十足,一个prototype可以实现继承,命名空间,私有等等。经典的框架和库:jQuery,Prototype等。

另外C#也不错,微软有一个操作系统内核是C#写的,包括内存管理,设备驱动等都是C#写的,除了系统引导和小部分HAL用了ASM/C以外,都是纯净的C#托管代码。很棒~~
大家可以在这里下载到代码:http://www.codeplex.com/singularity,并且可以在虚拟机中跑起来。

C#(或者说.net的语言集)都有很大的改进了,LINQ,spec#等更促进这些语言的发展。

至于JAVA,就不用多说了,我也用Java写过访问硬件的项目,速度也不错~它下面的框架最多也最成熟,例如人人都知道的:struct,spring,hibernate等。

相反个人感觉,C++在OO上面很缺乏支持,虽然都可以做,但是实现起来却非常麻烦,例如大部分语言都有委托,C++标准确没(不过快了,但是这个委托用起来复杂,标准库发展真的很慢,而且脱离实际应用)。还有RTTI也不行,例如wxWidgets,MFC等都是自己实现RTTI的,他们很少使用到C++的特性。

当然使用C++的话因为框架比较少,所以大家可以随心所欲地去设计,但是要真的作出一款优秀的软件却是非常难的,所以通常最后一个C++项目下来,开源库+别人的代码+一些自己的东西就出来了。

#14


感觉一门语言或者一项IT技术要有所发展,后面必须有大公司,大财团去支持。Java之前是sun去推动,所以发展还是相对缓慢的,但到了04年,IBM,甲骨文也加入到这个行列,JAVA发展神速啊!

C#也一样,微软在这方面投入不少。

开源产品,例如linux,apache,他们背后就是IBM等。。。但是其他开源项目就没那么幸运了,呵呵。

#15


编程语言还没完全掌握的飘过~~

#16


o

#17


我这个主题不是有意把事情复杂化和扩大化, 欢迎有过开发经验或架构经验的朋友多多发表自已的想法,把这个主题展开来就是一个个实战案例.
Kesummer里面提到一个RTTI的问题, Rutime type information, 为什么要实现这个东西呢(或者说存在)? 其实, 就是为了实现应用程序的灵活性, 我们知道,在写MFC程序中经常用到RTTI去检查类型信息, 找到特定的类, 实现程序运行时的动态绑定, 这个道理和现实生活或其它工程一样, 
e.g, 我们在超市去买牛奶, 不同牌子的牛奶就是RTTI .
c++本身有类型识别的特性,但是只有类型识别(recognise)是完全不够的...

#18


好东西

#19


冒昧的问一下,一般达到只见架构,不见语言,需要多少年的经验(人都是学的嘛)。
还要经过哪些实践呢

#20


n

#21


VC初学者,前来认识事物.
不知道多少年后我也会是一个C++高手.

#22


个人认为,比较高的境界是软件制造软件的时代,即软件会不断自我更新、复制并制造、更新其他的各种软件,同时成为真正意义的数据管理中心,形成图形级数拓展软件层次,而人需要做的只是以某种方式提供需求。当然,这个时代,软件的更新速度很快,可能一个软件只为一个线程计算而产生,完成后就消亡。软件的产生只为人类需求的各种功能,不需要人去思考软件本身,而是思考问题本身。

#23


1

#24


引用 22 楼 stef831018 的回复:
个人认为,比较高的境界是软件制造软件的时代,即软件会不断自我更新、复制并制造、更新其他的各种软件,同时成为真正意义的数据管理中心,形成图形级数拓展软件层次,而人需要做的只是以某种方式提供需求。当然,这个时代,软件的更新速度很快,可能一个软件只为一个线程计算而产生,完成后就消亡。软件的产生只为人类需求的各种功能,不需要人去思考软件本身,而是思考问题本身。


说得很好!

#25


我的妈呀

#26


以后都人工智能了,科学研究都让机器人去做了,大家要考虑的是如何不被机器人灭掉

#27


引用 26 楼 ypos 的回复:
以后都人工智能了,科学研究都让机器人去做了,大家要考虑的是如何不被机器人灭掉

好像你这个想法离主题似乎太远了点 : )

#28


n

#29


有没有人想开发一个跨平台的框架?可以作为开源项目,放在sourceforge.net?

#30


过,层次不够

#31


好高深啊,很有学习价值

#32


学习……

#33


楼主一席话真是于我心有戚戚焉啊
我是做运动控制软件的,关于这个行业的相关开发模式资料真是少的不能再少
很多时候根本就不是技术问题,就是设计问题,如果照搬一些网上或者那些著作上的条条框框根本就是死路一条
基本上都是我自己捉摸出来的,有的方式方法也是我误打误撞做出来的(事后才感觉做的好哈哈),呵呵其中有些数据交互方式我认为别人以前绝对没有提到
呵呵可是如果真让我说我是怎么做的,我还真说不出来,总是朦朦胧胧的,像隔着一层纱一样
希望加你为好友,以后我会关注你的帖子

#34


引用 22 楼 stef831018 的回复:
个人认为,比较高的境界是软件制造软件的时代,即软件会不断自我更新、复制并制造、更新其他的各种软件,同时成为真正意义的数据管理中心,形成图形级数拓展软件层次,而人需要做的只是以某种方式提供需求。当然,这个时代,软件的更新速度很快,可能一个软件只为一个线程计算而产生,完成后就消亡。软件的产生只为人类需求的各种功能,不需要人去思考软件本身,而是思考问题本身。

呵呵,比较远
我认为未来十年的软件发展趋势是往专业化,小型化发展,而不是像你说的一个软件什么都能做,能涵盖所有的行业
所谓专业化既像聊天软件,商务管理,金融,物流,GIS,当然也包括运动控制软件
现在很多软件发展模式恰恰违背了这点,大而全,像一些工业用的组态软件,程序过于臃肿
当然有些公司已经开始意识到了,像西门子它就推出了专门用于配变监测的组态软件
=========================================================================
另外关于你说的软件复制并制造,和自动更新其他的各种软件,现在就已经有了
工业组态软件就是,最著名的是labview呵呵可是二次平台开发出的软件效率与一次平台是没有办法比的

#35


你想说什么呢?

#36


从上面一直看到这34楼,很多东西都没有听过,软件行业面太广,或者可以说是太繁杂了。
个人对技术方面没有任何的发言权,只是想在这儿说说自己刚刚做完一个小小的项目的一些想法。
从6月份毕业直到9月份才找到工作,直到12月多,花了三个多月的时间自己一个人埋头做完一个功能非常简单的小软件,其中主要实现的功能有:通过RS232串口通信来控制硬件控制器,建立数据库记录控制器的运行状态,具有Windows风格的易操作UI。
用到的开发环境和一些技术:VS2005(C++.NET)+ACCESS2003+WINDOWS XP  MSComm控件+多线程实现与硬件的通信 ADO数据库访问技术

个人从一开始的头脑一片空白,经过一步步的慢慢尝试,花费了漫长的时间才完成了一点点简单的功能。
1,学校真正能学到的东西实在是太少了。
2,在网上查到的很多技术都是在2年,3年,甚至5,6年前别人就已经掌握了的,这样让自己很没有信心怎么办?
2,在找工作之前多做一些实例(基础知识也一定要先学好)。
3,遇到不懂问题有人能问一定要问不要怕没面子,没人问就查网页,查书。
4,项目一开始没有计划,到后面要增加一些功能时要费九牛二虎之力。
5,有没有可能在做项目的前期要做哪些方面的考虑和规划。


很期盼软件开发能很快达到你们说的那个层次,那么做上层开发将越来越简单,底层开发可能会更复杂。
不过基础还是很重要,经过次锻炼才发现自己懂的东西实在太少了。要学习学习再学习啊!

#37


"框架"的涵义延伸到什么范围呢?

#38


谢谢楼上几位发言, 我暂且抽象一下框架概念:

1. 语言级框架 - STL, Boost
2. 软件设计框架 - MFC, MVC
3. 应用型框架 - 系统应用,行业应用

前几周去SD2大会时,和一个软件开发人员聊到, 以后的软件发展趋势就是模块整合,
我认为, 而以后的软件盈利模式就在于此, 小公司有自已成熟的框架 - 主要是3.
大公司有自已成熟的框架 - 主要是2.
不管是2.,3., 基础都是1.


时间有限, 下次再继续...

#39


大家都是牛人啊
我才刚学习编程,前方的路还很漫长啊

#40


引用 38 楼 yjgx007 的回复:
谢谢楼上几位发言, 我暂且抽象一下框架概念: 

1. 语言级框架 - STL, Boost 
2. 软件设计框架 - MFC, MVC 
3. 应用型框架 - 系统应用,行业应用 

前几周去SD2大会时,和一个软件开发人员聊到, 以后的软件发展趋势就是模块整合, 
我认为, 而以后的软件盈利模式就在于此, 小公司有自已成熟的框架 - 主要是3. 
大公司有自已成熟的框架 - 主要是2. 
不管是2.,3., 基础都是1. 


时间有限, 下次再继续... 


STL,BOOST不应该算是一种框架,只能算是一种工具,程序库。

框架是一个应用程序的半成品。框架提供了可在应用程序之间共享的可覆用的公共结构。开发者把框架融入他们自己的应用程序,并加以扩展,以满足他们特定的需要。框架和工具包的不同之处在于,框架提供了一致的结构,而不仅仅是一组工具类。

例如用MFC做开发,你必须派生自己的CWinApp类(也就是扩展),去完善自己的CFrameWnd或者CDialog,那么MFC中的CWinApp等其实就是个半成品类,沿用MFC的设计思想去完成自己的程序。

明显STL和BOOST都不是框架。

MFC也不是基于STL和BOOST构建的。

MVC只能算是一种设计模式或者说设计方案。

模式是一种指导,在一个良好的指导下,有助于你完成任务,有助于你作出一个优良的设计方案,达到事半功倍的效果。而且会得到解决问题的最佳办法。 

MVC的代表作之一就是MFC啦。。~~当然asp.net,jsp这些也都强调MVC。。


貌似现在软件就等同于服务了,典型的如杀毒软件,MySQL数据库,现在很热的云计算等等~~软件模块组合是微软很早就提出的概念,这个概念最早应用到COM上面。而模块整合在硬件生产早也实现啦~~例如某个工控机没有以太网功能,给个以太网模块插上就拥有这个功能了,事实上光卖模块根本不赚钱,连同模块的整合+软件服务才赚钱啊~~

#41


以上是个人观点~~有错请指正~谢谢~~

#42


学习~~~~~~~~~

#43


引用 40 楼 KeSummer 的回复:
STL,BOOST不应该算是一种框架,只能算是一种工具,程序库。 


STL, BOOST应该也算是框架. 例如 STL的find_if,你就要自己去提供一个谓词来完成判断.只不过你提供的类不需要从STL中的某个类派生出来而已,而你提供的代码又确实在STL内部运行.

#44


引用 40 楼 KeSummer 的回复:
引用 38 楼 yjgx007 的回复:
谢谢楼上几位发言, 我暂且抽象一下框架概念:

1. 语言级框架 - STL, Boost
2. 软件设计框架 - MFC, MVC
3. 应用型框架 - 系统应用,行业应用

前几周去SD2大会时,和一个软件开发人员聊到, 以后的软件发展趋势就是模块整合,
我认为, 而以后的软件盈利模式就在于此, 小公司有自已成熟的框架 - 主要是3.
大公司有自已成熟的框架 - 主要是2.
不管是2.,3., 基础都是1.


时间有限, 下次再继续…

这么多的框架,五花八门,请问我们如何能想出办法,让自己做的事情更简单
通过什么策略才能不使自己陷入过多的技术细节,到底什么是框架:我认为把它定义为解决问题的一个范畴更合理一些
很多时候我们是在做软件,但是更多的时候我们是在解决问题
你所说的整合我深有同感,但是从技术层面上讲个人认为很难,或许软件根本就不存在简单的方式
很多时候我们总是从地基开始盖楼,即使你拥有再成熟的程序框架也是这样子,因为应用是不同的,程序终归是一行一行堆出来的
Java就是一个例子,几年前还有人说它比C简单,可是现在看看估计这样说的人都是不懂的,它的库太庞大了
一些Sun的技术人员也谈到了需要对Java进行模块整合,因为启动一个HelloWorld的简单程序也需要100毫秒,呵呵个人认为除非重构否则根本就不现实
因为太多的模块已经商业应用了,如果整合出新的模块保留老的模块会让它的库变得更庞大,何况谁去为维护的成本负责
==========================================
而在框架一级进行整合更不可能,各个公司都有各个公司的利益各个公司都有各个公司推崇的技术和优势,遵循的协议更是让人眼花缭乱
而且大多数公司都互相排挤,几年前有人预言开源会怎么怎么样,mysql不是被收购了嘛,现在不也是推出了企业版的mysql嘛,ACE很著名,可是这种库
究竟有多少公司再用,整合那只是一个遥不可及的梦而已
到软件流水生产的那一天,或许我们都老了!我们的后代或许能享受到,但也只是或许吧

#45


STL  BOOST 仅仅是一个 库
WTL 是ATL 基础上 发展起来的一个 frame, 
每个公司根据自己的特点封装一个 

但是最后 platform 需要很多support. 以后的趋势是 platform

也就是你的东西 是在某个 platform上run
.
大公司 有几家啊, microsoft, google. IBM 还有几个能做出来的

微软肯定会做的,其他的 就不知道那家能做到了

#46


看不懂,up,暂时加精,看看反响

#47


我认为以后的软件发展趋势就是专业化发展
就像嵌入式操作系统一样,根据行业需要自己裁剪
定制属于自己的平台,开发只应用于自己行业的系统,不求大而全只求专
MFC这类的库会变得不像以前那样的重要
至于所说的模块整合嘛,也只能是针对这一专业系统的模块整合

#48


up
]

#49


too high

#50


最近在读程序设计语言与编绎,原来没感觉到它的重要性,现在看来,这才是最基础的东西(对软件而言)。我觉得ATL和BOOST提供的主要还是封装的方法库,它们还是面向运用的,只是这个封装方式是基础性的。

#1


时间有限, 等我有了新想法再继续 : )
欢迎大家指正, 也希望起到一些抛砖引玉的效果.

#2


sf

#3


#4


这个主题太大了
up...

#5


学习!

#6


引用 4 楼 walkbywind 的回复:
这个主题太大了
up...

是大了点, 不过本帖不限于这个主题.

#7


大胆预言:以前是物理的天下,以后是生化的天下。程序和现有的硬件架构放到下一个5K年来看,就像我们现在看猿使用树叉捅白蚁窝。当人造出的东西运行效率和内存可以与人的大脑相媲美时,人造人将成为现实,当超越人的大脑时,... ...

PS: 不要扔砖头啊,就当我胡说八道-..-

#8


引用 7 楼 hxyman 的回复:
大胆预言:以前是物理的天下,以后是生化的天下。程序和现有的硬件架构放到下一个5K年来看,就像我们现在看猿使用树叉捅白蚁窝。当人造出的东西运行效率和内存可以与人的大脑相媲美时,人造人将成为现实,当超越人的大脑时,... ...

PS: 不要扔砖头啊,就当我胡说八道-..-

说得好啊!能不能摆脱框架的束缚,进入下一代软件开发的新模式呢?

#9


我要一个Windows,就出来了一个Windows操作系统

#10


记得以前看过一个小品叫:【跑题】

……

#11


引用 10 楼 zaodt 的回复:
记得以前看过一个小品叫:【跑题】

……

吹牛也行啊,呵呵

#12


??

#13


嗯嗯。。。所以我也蛮喜欢Javascript的,JS这个脚本虽然没有类,但是面向对象的味道十足,一个prototype可以实现继承,命名空间,私有等等。经典的框架和库:jQuery,Prototype等。

另外C#也不错,微软有一个操作系统内核是C#写的,包括内存管理,设备驱动等都是C#写的,除了系统引导和小部分HAL用了ASM/C以外,都是纯净的C#托管代码。很棒~~
大家可以在这里下载到代码:http://www.codeplex.com/singularity,并且可以在虚拟机中跑起来。

C#(或者说.net的语言集)都有很大的改进了,LINQ,spec#等更促进这些语言的发展。

至于JAVA,就不用多说了,我也用Java写过访问硬件的项目,速度也不错~它下面的框架最多也最成熟,例如人人都知道的:struct,spring,hibernate等。

相反个人感觉,C++在OO上面很缺乏支持,虽然都可以做,但是实现起来却非常麻烦,例如大部分语言都有委托,C++标准确没(不过快了,但是这个委托用起来复杂,标准库发展真的很慢,而且脱离实际应用)。还有RTTI也不行,例如wxWidgets,MFC等都是自己实现RTTI的,他们很少使用到C++的特性。

当然使用C++的话因为框架比较少,所以大家可以随心所欲地去设计,但是要真的作出一款优秀的软件却是非常难的,所以通常最后一个C++项目下来,开源库+别人的代码+一些自己的东西就出来了。

#14


感觉一门语言或者一项IT技术要有所发展,后面必须有大公司,大财团去支持。Java之前是sun去推动,所以发展还是相对缓慢的,但到了04年,IBM,甲骨文也加入到这个行列,JAVA发展神速啊!

C#也一样,微软在这方面投入不少。

开源产品,例如linux,apache,他们背后就是IBM等。。。但是其他开源项目就没那么幸运了,呵呵。

#15


编程语言还没完全掌握的飘过~~

#16


o

#17


我这个主题不是有意把事情复杂化和扩大化, 欢迎有过开发经验或架构经验的朋友多多发表自已的想法,把这个主题展开来就是一个个实战案例.
Kesummer里面提到一个RTTI的问题, Rutime type information, 为什么要实现这个东西呢(或者说存在)? 其实, 就是为了实现应用程序的灵活性, 我们知道,在写MFC程序中经常用到RTTI去检查类型信息, 找到特定的类, 实现程序运行时的动态绑定, 这个道理和现实生活或其它工程一样, 
e.g, 我们在超市去买牛奶, 不同牌子的牛奶就是RTTI .
c++本身有类型识别的特性,但是只有类型识别(recognise)是完全不够的...

#18


好东西

#19


冒昧的问一下,一般达到只见架构,不见语言,需要多少年的经验(人都是学的嘛)。
还要经过哪些实践呢

#20


n

#21


VC初学者,前来认识事物.
不知道多少年后我也会是一个C++高手.

#22


个人认为,比较高的境界是软件制造软件的时代,即软件会不断自我更新、复制并制造、更新其他的各种软件,同时成为真正意义的数据管理中心,形成图形级数拓展软件层次,而人需要做的只是以某种方式提供需求。当然,这个时代,软件的更新速度很快,可能一个软件只为一个线程计算而产生,完成后就消亡。软件的产生只为人类需求的各种功能,不需要人去思考软件本身,而是思考问题本身。

#23


1

#24


引用 22 楼 stef831018 的回复:
个人认为,比较高的境界是软件制造软件的时代,即软件会不断自我更新、复制并制造、更新其他的各种软件,同时成为真正意义的数据管理中心,形成图形级数拓展软件层次,而人需要做的只是以某种方式提供需求。当然,这个时代,软件的更新速度很快,可能一个软件只为一个线程计算而产生,完成后就消亡。软件的产生只为人类需求的各种功能,不需要人去思考软件本身,而是思考问题本身。


说得很好!

#25


我的妈呀

#26


以后都人工智能了,科学研究都让机器人去做了,大家要考虑的是如何不被机器人灭掉

#27


引用 26 楼 ypos 的回复:
以后都人工智能了,科学研究都让机器人去做了,大家要考虑的是如何不被机器人灭掉

好像你这个想法离主题似乎太远了点 : )

#28


n

#29


有没有人想开发一个跨平台的框架?可以作为开源项目,放在sourceforge.net?

#30


过,层次不够

#31


好高深啊,很有学习价值

#32


学习……

#33


楼主一席话真是于我心有戚戚焉啊
我是做运动控制软件的,关于这个行业的相关开发模式资料真是少的不能再少
很多时候根本就不是技术问题,就是设计问题,如果照搬一些网上或者那些著作上的条条框框根本就是死路一条
基本上都是我自己捉摸出来的,有的方式方法也是我误打误撞做出来的(事后才感觉做的好哈哈),呵呵其中有些数据交互方式我认为别人以前绝对没有提到
呵呵可是如果真让我说我是怎么做的,我还真说不出来,总是朦朦胧胧的,像隔着一层纱一样
希望加你为好友,以后我会关注你的帖子

#34


引用 22 楼 stef831018 的回复:
个人认为,比较高的境界是软件制造软件的时代,即软件会不断自我更新、复制并制造、更新其他的各种软件,同时成为真正意义的数据管理中心,形成图形级数拓展软件层次,而人需要做的只是以某种方式提供需求。当然,这个时代,软件的更新速度很快,可能一个软件只为一个线程计算而产生,完成后就消亡。软件的产生只为人类需求的各种功能,不需要人去思考软件本身,而是思考问题本身。

呵呵,比较远
我认为未来十年的软件发展趋势是往专业化,小型化发展,而不是像你说的一个软件什么都能做,能涵盖所有的行业
所谓专业化既像聊天软件,商务管理,金融,物流,GIS,当然也包括运动控制软件
现在很多软件发展模式恰恰违背了这点,大而全,像一些工业用的组态软件,程序过于臃肿
当然有些公司已经开始意识到了,像西门子它就推出了专门用于配变监测的组态软件
=========================================================================
另外关于你说的软件复制并制造,和自动更新其他的各种软件,现在就已经有了
工业组态软件就是,最著名的是labview呵呵可是二次平台开发出的软件效率与一次平台是没有办法比的

#35


你想说什么呢?

#36


从上面一直看到这34楼,很多东西都没有听过,软件行业面太广,或者可以说是太繁杂了。
个人对技术方面没有任何的发言权,只是想在这儿说说自己刚刚做完一个小小的项目的一些想法。
从6月份毕业直到9月份才找到工作,直到12月多,花了三个多月的时间自己一个人埋头做完一个功能非常简单的小软件,其中主要实现的功能有:通过RS232串口通信来控制硬件控制器,建立数据库记录控制器的运行状态,具有Windows风格的易操作UI。
用到的开发环境和一些技术:VS2005(C++.NET)+ACCESS2003+WINDOWS XP  MSComm控件+多线程实现与硬件的通信 ADO数据库访问技术

个人从一开始的头脑一片空白,经过一步步的慢慢尝试,花费了漫长的时间才完成了一点点简单的功能。
1,学校真正能学到的东西实在是太少了。
2,在网上查到的很多技术都是在2年,3年,甚至5,6年前别人就已经掌握了的,这样让自己很没有信心怎么办?
2,在找工作之前多做一些实例(基础知识也一定要先学好)。
3,遇到不懂问题有人能问一定要问不要怕没面子,没人问就查网页,查书。
4,项目一开始没有计划,到后面要增加一些功能时要费九牛二虎之力。
5,有没有可能在做项目的前期要做哪些方面的考虑和规划。


很期盼软件开发能很快达到你们说的那个层次,那么做上层开发将越来越简单,底层开发可能会更复杂。
不过基础还是很重要,经过次锻炼才发现自己懂的东西实在太少了。要学习学习再学习啊!

#37


"框架"的涵义延伸到什么范围呢?

#38


谢谢楼上几位发言, 我暂且抽象一下框架概念:

1. 语言级框架 - STL, Boost
2. 软件设计框架 - MFC, MVC
3. 应用型框架 - 系统应用,行业应用

前几周去SD2大会时,和一个软件开发人员聊到, 以后的软件发展趋势就是模块整合,
我认为, 而以后的软件盈利模式就在于此, 小公司有自已成熟的框架 - 主要是3.
大公司有自已成熟的框架 - 主要是2.
不管是2.,3., 基础都是1.


时间有限, 下次再继续...

#39


大家都是牛人啊
我才刚学习编程,前方的路还很漫长啊

#40


引用 38 楼 yjgx007 的回复:
谢谢楼上几位发言, 我暂且抽象一下框架概念: 

1. 语言级框架 - STL, Boost 
2. 软件设计框架 - MFC, MVC 
3. 应用型框架 - 系统应用,行业应用 

前几周去SD2大会时,和一个软件开发人员聊到, 以后的软件发展趋势就是模块整合, 
我认为, 而以后的软件盈利模式就在于此, 小公司有自已成熟的框架 - 主要是3. 
大公司有自已成熟的框架 - 主要是2. 
不管是2.,3., 基础都是1. 


时间有限, 下次再继续... 


STL,BOOST不应该算是一种框架,只能算是一种工具,程序库。

框架是一个应用程序的半成品。框架提供了可在应用程序之间共享的可覆用的公共结构。开发者把框架融入他们自己的应用程序,并加以扩展,以满足他们特定的需要。框架和工具包的不同之处在于,框架提供了一致的结构,而不仅仅是一组工具类。

例如用MFC做开发,你必须派生自己的CWinApp类(也就是扩展),去完善自己的CFrameWnd或者CDialog,那么MFC中的CWinApp等其实就是个半成品类,沿用MFC的设计思想去完成自己的程序。

明显STL和BOOST都不是框架。

MFC也不是基于STL和BOOST构建的。

MVC只能算是一种设计模式或者说设计方案。

模式是一种指导,在一个良好的指导下,有助于你完成任务,有助于你作出一个优良的设计方案,达到事半功倍的效果。而且会得到解决问题的最佳办法。 

MVC的代表作之一就是MFC啦。。~~当然asp.net,jsp这些也都强调MVC。。


貌似现在软件就等同于服务了,典型的如杀毒软件,MySQL数据库,现在很热的云计算等等~~软件模块组合是微软很早就提出的概念,这个概念最早应用到COM上面。而模块整合在硬件生产早也实现啦~~例如某个工控机没有以太网功能,给个以太网模块插上就拥有这个功能了,事实上光卖模块根本不赚钱,连同模块的整合+软件服务才赚钱啊~~

#41


以上是个人观点~~有错请指正~谢谢~~

#42


学习~~~~~~~~~

#43


引用 40 楼 KeSummer 的回复:
STL,BOOST不应该算是一种框架,只能算是一种工具,程序库。 


STL, BOOST应该也算是框架. 例如 STL的find_if,你就要自己去提供一个谓词来完成判断.只不过你提供的类不需要从STL中的某个类派生出来而已,而你提供的代码又确实在STL内部运行.

#44


引用 40 楼 KeSummer 的回复:
引用 38 楼 yjgx007 的回复:
谢谢楼上几位发言, 我暂且抽象一下框架概念:

1. 语言级框架 - STL, Boost
2. 软件设计框架 - MFC, MVC
3. 应用型框架 - 系统应用,行业应用

前几周去SD2大会时,和一个软件开发人员聊到, 以后的软件发展趋势就是模块整合,
我认为, 而以后的软件盈利模式就在于此, 小公司有自已成熟的框架 - 主要是3.
大公司有自已成熟的框架 - 主要是2.
不管是2.,3., 基础都是1.


时间有限, 下次再继续…

这么多的框架,五花八门,请问我们如何能想出办法,让自己做的事情更简单
通过什么策略才能不使自己陷入过多的技术细节,到底什么是框架:我认为把它定义为解决问题的一个范畴更合理一些
很多时候我们是在做软件,但是更多的时候我们是在解决问题
你所说的整合我深有同感,但是从技术层面上讲个人认为很难,或许软件根本就不存在简单的方式
很多时候我们总是从地基开始盖楼,即使你拥有再成熟的程序框架也是这样子,因为应用是不同的,程序终归是一行一行堆出来的
Java就是一个例子,几年前还有人说它比C简单,可是现在看看估计这样说的人都是不懂的,它的库太庞大了
一些Sun的技术人员也谈到了需要对Java进行模块整合,因为启动一个HelloWorld的简单程序也需要100毫秒,呵呵个人认为除非重构否则根本就不现实
因为太多的模块已经商业应用了,如果整合出新的模块保留老的模块会让它的库变得更庞大,何况谁去为维护的成本负责
==========================================
而在框架一级进行整合更不可能,各个公司都有各个公司的利益各个公司都有各个公司推崇的技术和优势,遵循的协议更是让人眼花缭乱
而且大多数公司都互相排挤,几年前有人预言开源会怎么怎么样,mysql不是被收购了嘛,现在不也是推出了企业版的mysql嘛,ACE很著名,可是这种库
究竟有多少公司再用,整合那只是一个遥不可及的梦而已
到软件流水生产的那一天,或许我们都老了!我们的后代或许能享受到,但也只是或许吧

#45


STL  BOOST 仅仅是一个 库
WTL 是ATL 基础上 发展起来的一个 frame, 
每个公司根据自己的特点封装一个 

但是最后 platform 需要很多support. 以后的趋势是 platform

也就是你的东西 是在某个 platform上run
.
大公司 有几家啊, microsoft, google. IBM 还有几个能做出来的

微软肯定会做的,其他的 就不知道那家能做到了

#46


看不懂,up,暂时加精,看看反响

#47


我认为以后的软件发展趋势就是专业化发展
就像嵌入式操作系统一样,根据行业需要自己裁剪
定制属于自己的平台,开发只应用于自己行业的系统,不求大而全只求专
MFC这类的库会变得不像以前那样的重要
至于所说的模块整合嘛,也只能是针对这一专业系统的模块整合

#48


up
]

#49


too high

#50


最近在读程序设计语言与编绎,原来没感觉到它的重要性,现在看来,这才是最基础的东西(对软件而言)。我觉得ATL和BOOST提供的主要还是封装的方法库,它们还是面向运用的,只是这个封装方式是基础性的。