好了知道你不懂计算机了，下一位

请教楼上懂计算机的讲讲该怎么办。愿闻其详。

1. 针对整个生态、各种情况...
这是写代码过程中需要考虑的事，修bug就是哪里有洞补哪里
2. 多测试...
多测试没错，但是，bug不是测试得够多就没有了的，bug就在那里，修是修不完的。你永远知道你修掉这一个bug的同时，又有几个新bug产生

bug确实修不完的，很多时候确实修好一个却引起另外几个bug，但那些明显的，影响大多数用户体验的得优先修复，安全漏洞优先修复，多测试能发现更多bug，所以多测试还是要很必要的。

我的现在还有一个双屏的bug还没修呢

本帖最后由 netzx 于 2017-12-24 20:49 编辑

4楼的兄弟，针对第一点：你的想法是理想的。可是修bug，打个比方就像动手术，首先你得弄清楚症结在哪儿，其次，不能损伤正常的部分，最后实施正确的修改，才能算是成功的手术。否则，一定是动了这里，伤了那里，问题越修越多。所以，从实施者角度，就需要对各种状况及可能产生的情况的了解。或者，你不清楚将产生的后果，就需要多做测试，以消除负面的影响。这样才能做到药到病除。只知头痛医头，脚痛医脚，好比是庸医，治标不治本。
针对第二点：那是未战先气馁。好比从事医生这个职业就是除病，天下是有医不完的病，可是我医好一个，就是一个小小的成功。至少，起码我要做到尽力而为。
以上两点意见，不知当否，请指教。

功能第一位，bug第二位，先加功能，快速迭代

如果发现bug，就用尽可能详尽的方式反馈一下。
多做点实事儿，少谈点主义，人都做操作系统了，常识还不如你？
所以，不要给自己加戏了。

回9楼的兄弟：我17年前就做过这行，也修改过程序bug，希望自己的一点点感受能对你们有用。没有别的意思，希望你们能把deepin做好。

操作系统和 一般的app 测试不同，现在除了一般的测试外 还有自动化测试、手动测试、社区采用内测、公测，当然 1 需要加强测试力度和质量体系，2 社区参与社区也是重要的一个环节，修复一个问题，可能会涉及其他组件，而推送一个bug可能涉及整个dde，这就是有些问题修复了但是要等下一次更新的原因。

回11楼的兄弟：关于这个话题有些深入讨论的意思了。我发此贴是为了参与社区的讨论与建议，也算是抛砖引玉。愿大家添砖加瓦，把我们自己的操作系统搞好。

BUG有很多种，向这种发布过的程序BUG基本上只有使用的人知道，然后反馈给工程师，然后针对性的改，很正常的逻辑;

楼上的兄弟，把bug交给使用者来发现，就难免会带来一个效果：客户体验度差。也就是我曾经提过的一个指标：系统健壮度受到影响。
显然，这不是个成熟的开发者应该使用的方法。

如果想要更好的服务，可以买专业版的deepin。不能出力就出钱呗

话说最新版的搜狗在ubuntu16.04上貌似有问题，就一个小小的输入法都搞不定稳定性。你希望deepin更好也可以和应用软件商反馈，很多时候不一定是操作系统的原因

本帖最后由 netzx 于 2017-12-26 15:28 编辑

回15楼的兄弟：靠客户为项目出力，就好像温室里的花朵。一旦遇到残酷的环境，其结局会如何呢？

其一，整个消费级软件行业都是如此，发展太快了，大家都不追求bug数最低，而是更看重功能、界面、性能。所以 deepin 的做法也没什么特别的，你的“威吓”恐怕也没什么用。

其二，你把自己遇到的bug当成普遍性的bug，自己遇到的bug增加了（是否真的如此也未必，你没有真的统计过吧）就认为这个软件的bug增加了，这都是不一定正确的。

回18楼的兄弟：关于第一点，可以这么说：冷风未吹来时，大家都过得很好。可是当寒冬过后，能生存下来的，只有那些生存力顽强的、对困难有准备的。
关于第二点，我仅表达个人观点，当然不代表我做过统计。这也是我所能够做到的。