7,765
社区成员
发帖
与我相关
我的任务
分享应届毕业生：选择C++还是C#
C#+SqlServer 因为做过不少项目，所以稍微熟悉一些，但是没有系统的锻炼还不够深入
但是自己倾向于以后往C/C++/Linux方向发展，但是C语言只懂基础没有项目经验，C++也只是有语言基础没有项目经验，STL，WTL，COM，Boost等了解很少，Linux只是用过Ubuntu但还不会安装卸载程序，shell编程以前用过，MFC只是看过孙鑫的VC视频，没有实际的项目经验。
所以想找工作必须在.Net方面才有竞争力,但是可能心里认为.Net越来越简单人性化难以形成自己的核心竞争力,所以以后想往C/C++方向发展....
真诚请教各位大牛,不知北京情况如何...
但是自己倾向于以后往C/C++/Linux方向发展，但是C语言只懂基础没有项目经验，C++也只是有语言基础没有项目经验，STL，WTL，COM，Boost等了解很少，Linux只是用过Ubuntu但还不会安装卸载程序，shell编程以前用过，MFC只是看过孙鑫的VC视频，没有实际的项目经验。
所以想找工作必须在.Net方面才有竞争力,但是可能心里认为.Net越来越简单人性化难以形成自己的核心竞争力,所以以后想往C/C++方向发展....
真诚请教各位大牛,不知北京情况如何...
...全文
请发表友善的回复…
发表回复
cllover 2012-03-05
- 打赏
- 举报
C++吧，先练好技术，先在北京稳定下来，有饭吃在好好打拼。。。just follow your heart。。
大雷神 2012-03-05
- 打赏
- 举报
再给一次机会 我就当初就选择搞实施了
周期短 见效快 提成高 人缘广
周期短 见效快 提成高 人缘广
loopzxl 2012-03-05
- 打赏
- 举报
学C++吧 楼主听我的肯定没错 看看这个帖子里 你不学C++ 学C++的越来越少 以后老板们都不用C++做东西了
我们这些学C++的也不好混了
我们这些学C++的也不好混了
rainman48 2012-03-04
- 打赏
- 举报
使用哪种工具主要看你以后干哪行。。
Canvas 2012-03-04
- 打赏
- 举报
楼主别学c++了，没前途，真的没前途。相信我，你学了，竞争就大了
lvNotOnlyForShe 2012-03-04
- 打赏
- 举报
转载：http://news.cnblogs.com/n/72565/
1.1.21.1 简介
作为架构师和设计者，我们常把手头的事情作为工作焦点，很少反思过去如何。我们应该温故而知新。我从作为skype架构组领导的55 个月经历中总结了6个经验。其中一些是技术性的，另外一些是架构师较为软性的观点。首先介绍一下Skype的背景资料。
1.1.21.2 Skype背景
Skype是让用户可以进行音频视频通话的软件，也可以拨打普通电话以及发送短消息。公司成立于2003年，从成立以后就有令人难以置信的成长曲线。公司现在有超过五亿两千万注册用户，大约650名员工。这些用户同时产生平均21万个通话，其中大约三分之一包含视频。这个数字大致上是全世界国际通话的 8%。
不用多加说明也能知道，这个通讯量产生了罕见的扩展性挑战。在Skype一直使用端对端（peer to peer）技术作为处理类似挑战的主要武器。对等网络（核心用C语言实现）主要是由C++编写的服务器端服务及Postgre数据库支持组成，并结合强大的Python脚本。Web服务使用PHP搭建。
1.1.21.3 技术方面
经验法则不适用
在作为软件工程师的职业生涯中，一些模式会慢慢浮现出来，一些经验规则会显现出来。显然，你愿意无论何时何地都一直使用这些规则。毕竟它们过去都很有效，是不是？
事实证明，即使你有好用的锤子，也不要把身边所有东西都当成钉子。在快速变更的现代科技社会，经验法则不会一直适用。例如，我们看看Skype数据库是如何架构的。
传统智慧说永远不要在数据库里面实现业务逻辑。为何这个说法传播如此广泛？大多数架构师都有类似经验，这会导致原始数据库在硬件方面如巨兽般增长，无法运行，也非常难维护。
这个假冒克苏鲁恐怖神出现的原因是主要数据库平台常常缺乏两个重要而且立等可用的特性：横向划分数据库的能力（比如根据数据实体划分数据）和纵向划分数据库的能力（不同的数据库实体放入不同数据库中）。当然，我们可以自己建立这两种特性，但是数据库管理团队以外的人常常也想处理类似问题。对于DBA来说这是赖以生存的手段而不是用于解决问题的能力。也就是说，对数据库做划分或者队列的技术常常要存在于数据库之外，使得开发者需要自己处理协议转换、多种接口、数据集成等问题。
在Skype，维护数据库的这些人恰巧也是Postgre的重要贡献者。从很早开始他们就拒绝把数据库看成是系统架构角落一个大而无当的罐子，反而以积极地态度去学习技术，解决他们遇到的扩展性、性能及可维护性方面的问题。像你猜想的一样，这些还不够，即使最好的数据库架构也会在轻率地编码中被废掉。幸运的是，Skype数据库管理员从很早开始就掌控了需要进入数据库层的开发工作，在执行了一系列非功能需求、代码实现、同事评审过程来确保实现代码适合数据库层以及其他相关部分的设计之前，Skype的DBA不放弃控制。
图一解释了他们如何使用这些工具建立Skype数据库架构。
这里由四层构成：
• 接入层提供了接入数据库的能力，而且也处理数据库分区问题（pIProxy）和连接池（pgBouncer）。并且让开发者可以透明的使用这些功能。
• 联机事务处理层，是OLTP数据库存在的地方。
• 队列层，负责层与层之间数据库传送数据和复制数据。
• 内部服务器层，包含了用于记录、统计、检视、批处理和ETL目的的数据库。
所有这些都是为了保证数据库可扩展性对于开发者不是问题。我们把必要的业务逻辑尽量贴近数据，让它最有效的工作，也就是"业务逻辑应该远离数据库”的经验法则并不适用。当然会有类似发布、调试以及单元测试之类的困难，但是我们不害怕原始数据库肆虐发威。
图一：数据库层
架构模式也是一样。在工程师之间建立通用技术词汇表、提供验证过的常见技术问题处方是非常重要的事，应该小心对待。Skype的端到端网络就是很好的例子。如果问题以“设计互联网电话”这种方式提出，多数情况下，人们会设计使用SIP来实现要求。但是如果Skype通过基于SIP实现服务就不会给通讯工业带来变化。Skype早期的工程师不愿把自己限制于这件事通常如何完成，而是找到他们能建立的最佳可能方案。
总之，略微不同的组织和技能，就可能有必要建立完全不同的架构模式的应用。你应该随时欢迎这些差异对自己的传统思维挑战。
忽视功能架构吃尽苦头
我们很少有机会在项目初期搭建阶段就作为首席设计师参与工作。大多数工作是修改已有的系统，变更管理就成为架构师工作中很重要的部分。现在我们大多数变更管理关注在技术架构和有效地设计系统，以确保在实现变化以后设计依然有意义。
可惜是这不是故事的全部。
所有技术变化来源于功能上的变化。我们很少仅仅为了重构而修改系统。通常情况下会有一些外部驱动力，需要系统在某些行为上表现得不一样。这可能是市场上有了新产品，也可能是法律变更或者是运营部门的人需要更好的扩展。无论如何，技术变更常常伴随着功能上的变化。
所以我们的系统和流程需要保证技术变化更容易，我们也希望这个管理过程比较有序，对于接手的人来说不是象意大利面条一样杂乱。可是什么是功能性变化？谁来关注系统的功能性以及确保变化不会让系统更混乱？
我用例子来说明一下。
在过去四年一直常常有人强烈要求我修改Skype的网络存储架构，即使我证明每个微小的变化都会伴随痛苦。在互联网上销售四个产品不是什么复杂的事情，大多数时间整个系统就是照常运行，即使有一些问题被发现，紧接着就解决了。
这就是原因。
图2展示所有Skype网络存储的功能组件。大约有200个。图表不是很清晰准确，只想展示整个应用系统的功能性和复杂度。这是不计其数的变化、添加、修改、法律问题、微调造成的结果。所有这些当然是都有事出有因和有价值的。
相当多的架构师没有仔细考量技术变化，结果导致意大利面条般的混乱，应用系统因为不加思考的变化在功能上变得混乱。这不意味着作为软件架构师，我有意从开始就阻止这些问题。但是如果不对系统功能性架构足够小心，就会导致功能架构的支离破碎。结果只能是凌乱的技术架构。
图2：网络存储功能架构
总而言之，应该时刻对你要维护的系统功能保持关注。修改技术架构，也要经常维护功能架构。
1.1.21.1 简介
作为架构师和设计者，我们常把手头的事情作为工作焦点，很少反思过去如何。我们应该温故而知新。我从作为skype架构组领导的55 个月经历中总结了6个经验。其中一些是技术性的，另外一些是架构师较为软性的观点。首先介绍一下Skype的背景资料。
1.1.21.2 Skype背景
Skype是让用户可以进行音频视频通话的软件，也可以拨打普通电话以及发送短消息。公司成立于2003年，从成立以后就有令人难以置信的成长曲线。公司现在有超过五亿两千万注册用户，大约650名员工。这些用户同时产生平均21万个通话，其中大约三分之一包含视频。这个数字大致上是全世界国际通话的 8%。
不用多加说明也能知道，这个通讯量产生了罕见的扩展性挑战。在Skype一直使用端对端（peer to peer）技术作为处理类似挑战的主要武器。对等网络（核心用C语言实现）主要是由C++编写的服务器端服务及Postgre数据库支持组成，并结合强大的Python脚本。Web服务使用PHP搭建。
1.1.21.3 技术方面
经验法则不适用
在作为软件工程师的职业生涯中，一些模式会慢慢浮现出来，一些经验规则会显现出来。显然，你愿意无论何时何地都一直使用这些规则。毕竟它们过去都很有效，是不是？
事实证明，即使你有好用的锤子，也不要把身边所有东西都当成钉子。在快速变更的现代科技社会，经验法则不会一直适用。例如，我们看看Skype数据库是如何架构的。
传统智慧说永远不要在数据库里面实现业务逻辑。为何这个说法传播如此广泛？大多数架构师都有类似经验，这会导致原始数据库在硬件方面如巨兽般增长，无法运行，也非常难维护。
这个假冒克苏鲁恐怖神出现的原因是主要数据库平台常常缺乏两个重要而且立等可用的特性：横向划分数据库的能力（比如根据数据实体划分数据）和纵向划分数据库的能力（不同的数据库实体放入不同数据库中）。当然，我们可以自己建立这两种特性，但是数据库管理团队以外的人常常也想处理类似问题。对于DBA来说这是赖以生存的手段而不是用于解决问题的能力。也就是说，对数据库做划分或者队列的技术常常要存在于数据库之外，使得开发者需要自己处理协议转换、多种接口、数据集成等问题。
在Skype，维护数据库的这些人恰巧也是Postgre的重要贡献者。从很早开始他们就拒绝把数据库看成是系统架构角落一个大而无当的罐子，反而以积极地态度去学习技术，解决他们遇到的扩展性、性能及可维护性方面的问题。像你猜想的一样，这些还不够，即使最好的数据库架构也会在轻率地编码中被废掉。幸运的是，Skype数据库管理员从很早开始就掌控了需要进入数据库层的开发工作，在执行了一系列非功能需求、代码实现、同事评审过程来确保实现代码适合数据库层以及其他相关部分的设计之前，Skype的DBA不放弃控制。
图一解释了他们如何使用这些工具建立Skype数据库架构。
这里由四层构成：
• 接入层提供了接入数据库的能力，而且也处理数据库分区问题（pIProxy）和连接池（pgBouncer）。并且让开发者可以透明的使用这些功能。
• 联机事务处理层，是OLTP数据库存在的地方。
• 队列层，负责层与层之间数据库传送数据和复制数据。
• 内部服务器层，包含了用于记录、统计、检视、批处理和ETL目的的数据库。
所有这些都是为了保证数据库可扩展性对于开发者不是问题。我们把必要的业务逻辑尽量贴近数据，让它最有效的工作，也就是"业务逻辑应该远离数据库”的经验法则并不适用。当然会有类似发布、调试以及单元测试之类的困难，但是我们不害怕原始数据库肆虐发威。
图一：数据库层
架构模式也是一样。在工程师之间建立通用技术词汇表、提供验证过的常见技术问题处方是非常重要的事，应该小心对待。Skype的端到端网络就是很好的例子。如果问题以“设计互联网电话”这种方式提出，多数情况下，人们会设计使用SIP来实现要求。但是如果Skype通过基于SIP实现服务就不会给通讯工业带来变化。Skype早期的工程师不愿把自己限制于这件事通常如何完成，而是找到他们能建立的最佳可能方案。
总之，略微不同的组织和技能，就可能有必要建立完全不同的架构模式的应用。你应该随时欢迎这些差异对自己的传统思维挑战。
忽视功能架构吃尽苦头
我们很少有机会在项目初期搭建阶段就作为首席设计师参与工作。大多数工作是修改已有的系统，变更管理就成为架构师工作中很重要的部分。现在我们大多数变更管理关注在技术架构和有效地设计系统，以确保在实现变化以后设计依然有意义。
可惜是这不是故事的全部。
所有技术变化来源于功能上的变化。我们很少仅仅为了重构而修改系统。通常情况下会有一些外部驱动力，需要系统在某些行为上表现得不一样。这可能是市场上有了新产品，也可能是法律变更或者是运营部门的人需要更好的扩展。无论如何，技术变更常常伴随着功能上的变化。
所以我们的系统和流程需要保证技术变化更容易，我们也希望这个管理过程比较有序，对于接手的人来说不是象意大利面条一样杂乱。可是什么是功能性变化？谁来关注系统的功能性以及确保变化不会让系统更混乱？
我用例子来说明一下。
在过去四年一直常常有人强烈要求我修改Skype的网络存储架构，即使我证明每个微小的变化都会伴随痛苦。在互联网上销售四个产品不是什么复杂的事情，大多数时间整个系统就是照常运行，即使有一些问题被发现，紧接着就解决了。
这就是原因。
图2展示所有Skype网络存储的功能组件。大约有200个。图表不是很清晰准确，只想展示整个应用系统的功能性和复杂度。这是不计其数的变化、添加、修改、法律问题、微调造成的结果。所有这些当然是都有事出有因和有价值的。
相当多的架构师没有仔细考量技术变化，结果导致意大利面条般的混乱，应用系统因为不加思考的变化在功能上变得混乱。这不意味着作为软件架构师，我有意从开始就阻止这些问题。但是如果不对系统功能性架构足够小心，就会导致功能架构的支离破碎。结果只能是凌乱的技术架构。
图2：网络存储功能架构
总而言之，应该时刻对你要维护的系统功能保持关注。修改技术架构，也要经常维护功能架构。
cdcjk 2012-03-04
- 打赏
- 举报
用哪种语言关键看自己的兴趣，有兴趣才有动力嘛
孤灯残云 2012-03-04
- 打赏
- 举报
个人倾向于C++
shijeff1992 2012-03-04
- 打赏
- 举报
[Quote=引用 69 楼 a15857401484 的回复:]
这位兄台对信管很熟悉啊 我也是2012届的毕业生 信管的 对.net也不怎么看好 现在的方向是java 与楼主共勉
引用 24 楼 magic121 的回复:
莫非难道说lz是信管毕业生？
[/Quote]
我是10级信管的啊、、觉得前途迷茫啊、、还请各位学长指点啊、、、
这位兄台对信管很熟悉啊 我也是2012届的毕业生 信管的 对.net也不怎么看好 现在的方向是java 与楼主共勉
引用 24 楼 magic121 的回复:
莫非难道说lz是信管毕业生？
[/Quote]
我是10级信管的啊、、觉得前途迷茫啊、、还请各位学长指点啊、、、
Redice_7 2012-03-04
- 打赏
- 举报
握手楼主，我和你一届 。我是在C++和java 上纠结。个人比较倾向C++，但是Java 会稍微好点。
alanwang112 2012-03-04
- 打赏
- 举报
我更加低了 还在萝莉和正太间纠结
cheniwantyou 2012-03-04
- 打赏
- 举报
大学入门是C++，非常有感觉。后来一直学JAVA，但工作后用了C#感觉非常不错，目前主要用C#，偶尔工作中会用到JAVA。本人C#，JAVA都会。
努力奋发的小农 2012-03-03
- 打赏
- 举报
怎么去学c和c++还是个问题呢？呵呵~~~
fafafabbb 2012-03-03
- 打赏
- 举报
总是有初学者在质疑徘徊中浪费自己的时间青春，你看看那些c，c++大牛那个成天怀疑自己以后有没有饭碗。在你用你愚蠢的脑袋浅薄的阅历女人般软弱的性格打算考虑一些大事前，请先真正弄清楚你自己到底会什么，你到底有没有资格或者说足够的证据决定自己的未来。
X_Holden 2012-03-03
- 打赏
- 举报
路过。。。
lv_ws 2012-03-03
- 打赏
- 举报
我也是信管专业的，C#，C++，JAVA……同样迷茫中。。。
cllover 2012-03-02
- 打赏
- 举报
[Quote=引用 110 楼 zanfeng 的回复:]
无论你先择c#还是c++。如果你做应用软件不是做网站.c++是必须的。
[/Quote]
谢谢大牛指点
无论你先择c#还是c++。如果你做应用软件不是做网站.c++是必须的。
[/Quote]
谢谢大牛指点
足球中国 2012-03-02
- 打赏
- 举报
无论你先择c#还是c++。如果你做应用软件不是做网站.c++是必须的。
xaobaobao 2012-03-02
- 打赏
- 举报
唉，，，心酸啊。。。
peng111hn 2012-03-02
- 打赏
- 举报
看你兴趣来 我个人觉得C++ 然后往linux走
加载更多回复（107）
