五千年(敝帚自珍)

主题:【原创】也来说说Linux和Windows下的开发感受 -- 昔杨今雨

共:💬203 🌺502
分页树展主题 · 全看首页 上页
/ 14
下页 末页
        • 家园 呵呵,您进入了自己的悖论

          您意识到没有?既然每个人的活法不同, 模式也不同, 所以又怎么能以自己的模式去指责别人的模式优劣?

          我举自己的那个例子只是说明计算机技术的发展,已经可以让很多人更容易的来使用这一工具作为谋生手段。 大家站在食物链的位置不同,没必要强求一致。

          至于市场还是技术的问题就更不要说,模式不同,没什么好争的。我个人尝试过做小作坊,失败了,对于我来说,市场比技术关键的多,我年轻时因为不懂市场价值,做过一些小东西,都免费给人了,或者用完扔了,若干年以后看到别人的成功,很是郁闷。你看法不同,只能说明我们是不同类型的人,也没什么好争论的吧。

        • 家园 精英技术团队很难吧

          不是要抬杠, 不过这样的精英技术团队哪都不多吧.

          我们公司某个TEAM里个个都是牛人, 一个连经理在内是6个人. 他们一年到晚都在招人, 却N年也不能找到一个. 无它, 让他们看上眼的百中无一, 而那些百中无一到哪都是人见人爱, 爱来不来. 好, 就算那个TEAM很牛, 不过公司其它TEAM不见得都那么牛, 测试的也不一定跟得上. 要维持这TEAM, 花费也不诽,谤不容易啊.

    • 家园 UNIX下C和C++的编译环境几十年来都没什么变化

      就是vi编辑器编源码和MAKEFILE文件,十几年前互联网也不是太发达,UNIX书籍在中国也不好买。很多经验都得自己积累,光自己总结的有用的函数就好几百个。

      第一次看见别人使用微软VC++的时候,觉着简直太神奇了。

    • 家园 有请楼主详细谈一下持续集成

      您的第三点,Windows和Unix下,在持续集成方面的区别,请您详细谈谈。

      1〉您所指的是怎么样的一个“持续集成”

      2〉这样的一个持续集成环境,对操作系统的要求有哪些方面?Windows和Unix有哪些方面适合或不适合搭建这么一个持续集成的环境?

      • 家园 已经在楼下回复了
      • 家园 同望,以往似乎没有看到过这个概念
        • 家园 持续集成, 原文是Continuous Integration

          至于它的概念, 您只需要google一下.

          这样的一个持续集成环境,对操作系统的要求有哪些方面?Windows和Unix有哪些方面适合或不适合搭建这么一个持续集成的环境?

          这个问题简单回答一下, 搭建一个持续集成环境涉及的内容比较多, 例如:

          1)首先你需要有代码管理, 例如cvs/svn/git;

          2)其次你需要有自动编译环境, 需要从cvs啥的里面自动checkout指定的版本, 自动编译;

          3)在编译过程需要有错误管理, 例如在遇到错误时, 是退出编译过程, 还是进入下一个模块, 编译错误通过什么方式告知这段代码的管理者, 是通过email, 还是发布的内部网站上,而且必须要有详细的错误信息, 便于程序员排查;

          4)编译完毕后应该可以自动运行单元测试;

          5)单元测试完毕后, 应该可以自动进行递归测试; 同样, 测试结果应该有report;

          6)除此之外, 你可以还需要wiki, 需要bug tracker, 需要source code browser, 例如lxr这样的东东. 更进一步, 您可能还需要test case管理, knownledge management;

          7)最后, 这些东东应该可以互操作, 例如bug tracker里面bug状态的调整, 应该email通知相关人员; 自动测试过程中发生的问题, 应该可以自动进入bug tracker.

          为什么Unix下搭建这个环境比Window下更容易更成熟呢?

          首先上面提到的各种工具, 其中的佼佼者(至少开源的软件)大多数是运行在Unix平台上的, 在debian下一个apt-get可能就可以安装完毕;

          其次谈到互操作, 在Windows平台上简直就是恶梦, 你可以说出哪些Windows下的, 由不同公司或者团队开发的软件可以有深入的互操作的? 在Unix平台下, 再不济也有stdin+stdout+管道的方法. 更何况还有Unix平台的开放性, 原生的丰富多彩的script语言, 命令行的优势在这种情况下真是体现得淋漓尽致.

          这么做的效果嘛, 就是现在我所在的公司, 技术人员就3个, 一个专职开发, 一个专职测试, 还有一个一开始也是测试, 现在应他自己的要求, 给他分配了一些编程的工作. 维护着20个以上的功能模块, 100万行以上的代码, 超过3000个test case, 完成一次递归测试只需要8-12个小时. 因此俺们的版本发布频率大约可以到1星期1次, 任何客户需求, 只要我们决定去做, 我们的反应速度不超过一个礼拜.

          • 家园 涨见识 送花
          • 家园 送花,这个贴应该跟在主贴下面

            我还不知道这个方式叫做持续集成,可能我们的测试管理做的比较少吧。长知识。希望能看到更多这样的帖子:)

          • 家园 谢谢,再继续请教

            为什么Windows下缺乏这样的工具?是Windows内核天生的不适合,还是软件公司认为给Windows平台开发这样的工具无利可图?

            这是很不可思议的事,既然Windows的市场占有率这么大,而“持续集成”又是如此有效,这应该是很大的市场啊?

            • 家园 不在于有没有“持续集成”的工具,而在于有没有这种的思想

              自己的理解,持续集成的作用就是要把一些可以通过自动化的编译、测试工作发现的问题尽可能早地暴露出来,降低解决问题的成本(Bug越早解决,其解决成本就越低)。

              Windows下的开发,据我所知在DotNet平台下有几个持续构建工具,我用过CruiseControl.Net,感觉还不错。

              其实最关键的不在于工具,而在于有没有这种持续集成的思想;就算没有工具,用脚本也可以进行持续集成所需要的工作,再不行用批处理也能做;不过有多少公司真能做起来呢?很多小作坊式的公司连版本控制工具都没有用,何况持续集成?

分页树展主题 · 全看首页 上页
/ 14
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河