鄙视.net C# 程序猿，欢迎进来丢砖，拍不死我，算我赢

jmcooler 2014-05-08 10:12:07

中国程序员的通病—非常不专业。不知道是不是被那些资产阶级压榨和剥削的结果，编写软件的速度可观，质量却十分不敢恭维。真是被压榨的，还说的过去，可自己还得提高自身的修为，不然如何成长？

有一句话，经常成为程序员的贯口：现在内存那么大，不担心；现在 CPU 那么强，别担心
最终写出来的程序，运行速度超慢，用户体验很差，粗制滥造，和地摊货没啥区别。真是一个生产大国啊！！！

有了像 CSDN 这样的编程论坛，程序的工作就更简单了。除了问就是问，然后抄，抄完还人云亦云。能提高吗？
一个简单问题，从一个文件夹下，随机选取一个 txt 文件，也拿出来问，视.NET 的帮助而不见，要是该帮助是 E 文的，恐怕更被丢到九霄云外。
提问者白痴也就算了，刚入门嘛，能理解一层。看看高手是如何回答的：
var file = new DirectoryInfo(@"c:\path").GetFiles("*.txt", SearchOption.AllDirectories).OrderBy(x => Guid.NewGuid()).First();
功能实现了，也十分简洁。为何认定此人是高手，因为菜鸟写不出这么简洁的功能强大的语句。
我倒要问下，行不行啊？
为何要排序？不就是选取个随机文件，和排序扯得上半点关系么。
你恐怕回答说，反正是实现了，并且 CPU 够快了，你担心个鸟啊。
南辕北辙，这个中国古老的成语故事，大家不会陌生吧。
条条大路通罗马，可我就是不选最短的那条线路，反正盘缠多。你是不是有点杞人忧天啦，神经病！

如果你斟酌过，确保那个文件夹下的文件不多，上面的语句，偶尔用一用也无妨。如果这样的操作非常频繁，可就要当心了，或许要搞半天，界面阻塞，用户体验极差。你可以按这样辩解，但你总是回答说，“CPU够快的了”，我马上就会骂你个狗血喷头。

有的人，特别是程序员，非常固执。碰上这种问题，他们并不是就事论事，就技术论技术，反倒还要诡辩。我不过只是随便拧出来，往这里一贴，我平常不是这么用的。我给老板干活，为什么要写得那么好，写好了，我不就失业了嘛。和上面的“CPU够快了”如出一辙，理由很多，看似还牢不可破。
对于前者，我看来，你平常就是这么用的，这种用法已经深入了你的人心，还不知悔悟，这就非常可怕了。结果将是垃圾代码一大堆，慢如蜗牛，后续在性能改善上，花费的时间成几何级上升。你贴了出来，还非常误导人。
对于后者，问题的根本，不在于你堆砌了多少垃圾代码，而在于你对这些代码理解多少。你可以给老板写垃圾代码，但你自己时刻都知道这些代码确实很垃圾。人贵在有自知之明。
还有一句贯口，“先实现了功能再说”，言外之意是，想不到那么长远和周密。可恨，更可怜，没想好之前，你何以要动手？
就上面的事例来说，你写了一个非常简练的，功能完整的语句，而写这条语句耗费的时间，远比下面的语句多：
var files = new DirectoryInfo(@"c:\path").GetFiles("*.txt", SearchOption.AllDirectories);
if( file.Count > 0 )
FileInfo txtFileInfo = files[new Random().Next( 0, files.Count )];
从时间耗费，效率上考虑，你都在舍近求远。
不要跟我说，你的语句是某教科书抄来的，是非常经典的语句。又在那诡辩了，理解了么，抄会了么！
一个稍显功能的语句，你都不得不考虑数据结构和算法问题，真正也是举手之劳。

你可不要从这个极端走向另外一个极端，事事都搬高升的算法来解决问题，每个语句都字斟句酌，旷日持久，纯迂腐之人。
杀牛总是要用合适的刀，过大过小，都为过，牛虽然死了，肉却没法吃。
有规模的大一点的公司，都比较注重你对数据结构的掌握程度。到华为腾讯去应聘，你最好复习下数据机构，否则不上两关，就刷下来了。就平时也需要加强这方面的训练，一个不懂数据结构的程序员，不要说成为分析师，架构师，混碗饭吃都难。
而最重要的一点，知其然，还要知其所以然。
对于缺乏基本功，浮于表面的人，问题一旦复杂，从一开始技术选型就会错，架构会错，数据结构也跟着错，最后那个系统稀巴烂。

我也是个小老板，我允许下面的人给我写垃圾代码，一旦被我发现，你得正面应对，诡辩将会受到严厉的惩罚。这对你自己也有百利而无一害。
我发现个问题，和 .net 程序员合作非常困难，.NET 门槛很低，导致大量半罐水进入了编程大军。写出来的程序，界面一操作就阻塞或崩溃。最要命的是，问题依然，他们却熟视无睹，死不悔改。见过固执的人，没见过 .NET 程序员普遍这么固执的人。
再说到理解力，哎哟喂，你们随便翻一下 .NET 论坛里的回答，90% 都是答非所问，虽然有些夸张，但都揭示了这些人的理解力有多差。除去打酱油，说梦话，捞积分的人，那也有百分之七八十的人，理解力都非常差。真正的高手，都不在网上瞎混。

问题很白痴，理解很白痴，回答更白痴，看来白痴真的会传染，滥竽的人太多了。

我今天上来发发牢骚，欢迎拍砖，准备迎接暴风雨。也希望程序员们加强自身修为，提高技能技巧，你可不要硬撑，这行真不好混。

...全文

2266 83 打赏收藏转发到动态举报

写回复

用AI写文章

83 条回复

切换为时间正序

请发表友善的回复…

发表回复

相思梦 2014-06-02

打赏
举报

如今中国程序员普遍只是为了高工资而来，而并非为兴趣爱好而好，这是个现状或许是个悲哀。对于我而言编程只是爱好并非赚钱工具，对于Net本人只研究几个月，本抵是学习VC+，对于C#不属于机器语言感到非常不解，或许你会问我C#不是二次编译型语言？

我只能说这语言与JAVA字节码解释型语言没有任何区别，JIT动态编译机器代码与JAVA虚拟机解释字节码有什么区别，还真心没太大区别。

C#竟然不支持__asm，通过VirtualAlloc在虚内存中嵌入byte[]字节码，实现 __asm 易语言可行，Net 死程序，纠结如是 Net 托管内存堆保护。

Net中GC本人非常不感冒，去除delete关键字，必须通过GC垃圾管理自己回收。对于Net无故消耗内存行为感到非常不解，难道真的是内存足够大了？

Net COM，这我只能说无语，抽象反射繁琐，不知为何什马派生自_ComObject，其次在抽象实例化后调用其COM对象属性，呵呵保证错误，也就那么寥寥无几可以被支持，我当时就笑了。本来利用CreateWindowEX配合AtlAxGetControl
参数不能输出Object，而其类型却是_COMOBJECT，那么我请问OBJECT不是基类？为什么还不行，所以我笑了。

NET Struct 值类型派生自System.TypeValue，奇怪事情来了Typevlaue派生自System.Object，这不是烂套了吗？
值类型与引用类型完全是两个概念不是吗，一个固体缓冲区，一个动态缓冲区上述完全烂套了，Net内真有规则吗？

Net 错误检查机制，起初是好的但应为检查机制太多无故
浪费性能内存，我另可Net没有错误检查机制手动检查
也不愿意Net自身检查对于效率稳定性而言抛出错误太多
内存无故溢出死掉，真心对NET错误检查机制感到寒心

NET内存保护对于学习网站的朋友来讲那是好事，如果是
对于客户端程序员而讲那就是噁心无言，NET保护内存，
对于多进程客户端应用无疑就是封杀内存共享技术。
无故封闭管道扩展，更封杀C#利用SDK实现ASM汇编
那么你说我该有多恨它，因为它的原因我需要想其它办法
还要考虑效率。内存文件映射...无聊、

c电磁 2014-06-01

打赏
举报

如果真需要偏底层来写。那不如开发项目时候就直接 C++/ C+.NET 这样不是更好，有速度更可手动优化但只是说暂时建议如下，毕竟（Net Native）马上就要出来来，本地机器代码部署（Native Code）也就是说 C# 程序将在Win32内存堆进行布局，而不是在 Net 堆，相对的 C# 程序将达到甚至超过 C++ 程序性能，那么你如今还纠结性能，效率？

c电磁 2014-05-31

打赏
举报

楼主你为针对NET？其实没意思的对吧。请问楼主： var file = new DirectoryInfo(@"c:\path").GetFiles("*.txt", SearchOption.AllDirectories).OrderBy(x => Guid.NewGuid()).First(); 中 OrderBy 是哪里来的？ array 派生父类内有这么一个东西？笑而不语。其次再说：楼主你没看见这代码说的什么？ SearchOption.AllDirectories 搜索目录及子目录下所有 *.txt 文件，那么如果下面目录及其文件多卡顿是正常的。你跑过来骂NET程序猿垃圾作甚？你明明该知道NET查错机制太多。在某些方面是不如C++。如果你想快你可以找C++程序猿给你搞3。难道你为了效率还有NET程序猿给你用 FindFirstFile FindNextFile WinSDK 来写搜索文件夹？ C# 寻找文件

private List<string> selectFiles(string Path, string Filter) {
            string _Path = Path;
            List<string> _list = null;
            if (_Path.Substring(Path.Length - 1) != @"\") {
                _Path += @"\";
            }
            _Path += Filter;
            int hFile = 0, hSelect = 1;
            var FileData = new WIN32_FIND_DATA();
            hFile = FindFirstFile(_Path, ref FileData);
            if (hFile == INVALID_HANDLE_VALUE) {
                return _list;
            }
            _list = new List<string>();
            while (hSelect != 0) {
                _list.Add(FileData.cFileName);
                hSelect = FindNextFile(hFile, ref FileData);
            }
            return _list;
        }

goodluck_1016 2014-05-13

打赏
举报

我只是来打酱油的

五月春生 2014-05-12

打赏
举报

引用 75 楼 shawn_yang 的回复:

这个是大部分现象吧，不过为毛单说c# .net程序员？

因为此贴发在C#区，此举才能引起足够的重视，可见LZ还深知网络营销的真义，通过精准用户可能会关切的话题进行标题党式吸引眼球进行话题营销。

shawn_yang 2014-05-12

打赏
举报

这个是大部分现象吧，不过为毛单说c# .net程序员？

sjzjams 2014-05-12

打赏
举报

引用 72 楼 edcvf3 的回复:

感谢LZ鄙视,顺便也深深滴BS下自己,确实C#的优雅灵活导致了很多C#程序员都不去注重性能,反正JIT会自己优化,反正CPU够强,能完成功能就OK了。。。唉,其实挺悲剧的,都被微软整成傻瓜式的了,人也变傻了。。。

呵呵那你去开发个让别人变傻的工具如何？就先弄个orm吧，这个不管什么语言都有。

showjim 2014-05-12

打赏
举报

引用 72 楼 edcvf3 的回复:

感谢LZ鄙视,顺便也深深滴BS下自己,确实C#的优雅灵活导致了很多C#程序员都不去注重性能,反正JIT会自己优化,反正CPU够强,能完成功能就OK了。。。唉,其实挺悲剧的,都被微软整成傻瓜式的了,人也变傻了。。。

人玩工具，而不是被工具玩傻。

Cryking 2014-05-12

打赏
举报

感谢LZ鄙视,顺便也深深滴BS下自己,确实C#的优雅灵活导致了很多C#程序员都不去注重性能,反正JIT会自己优化,反正CPU够强,能完成功能就OK了。。。唉,其实挺悲剧的,都被微软整成傻瓜式的了,人也变傻了。。。

wxsxiaoK 2014-05-12

打赏
举报

你这觉悟还能当小老板？

失落的神庙 2014-05-12

打赏
举报

江湖的传说 2014-05-12

打赏
举报

各大家的讨论中学习

无常名 2014-05-12

打赏
举报

你敢曝一下你员工的工资吗？

Dogfish 2014-05-10

打赏
举报

有一个语言之争的问题。留名！！！

修仙之人 2014-05-10

打赏
举报

5#说的很在理呀。如果真要求程序效率的话，楼主我都建义你不要用VAR

以专业开发人员为伍 2014-05-10

打赏
举报

引用 57 楼 jmcooler 的回复:

我不怎么熟悉 C#，现在不得不熟悉有关 C# 下的设计模式当初没参与设计，这是原因之一，同时我也抽不开身哥们，你还没看出来，我们在做一个功能明确的产品啊，也不太担心开发周期。首选瀑布模式，最多 6 个月。各位借鉴吧，反正我暂时搞失败了。高估了他们，低估了 C#，我的责任重大。 “先实现功能”在我这不合用，市场上这种模式占绝对，貌似已经深入人心，事事都来个“先实现功能”。 “先实现功能”有前提，那就是选用了原型法

“先实现功能”如果是菜鸟说的，那么你就可以说“你还不如搞个最垃圾的瀑布开发，尽量拖延时间，然后发布后一遍遍推倒重来。但是如果是有经验的人做的，我建议你先看看人家进行架构重构的技术你到底懂不懂再说。人总是会首先找到”瀑布开发模型”的理由的，这是人之常情。但愿他会找到一个宁愿等他5、6年成长、等他懂得如何经常进行架构重构的老板。