[竹马推荐]旧话重提：开发过程中的软件质量保证（88TechReview提供）
2005-03-10 14:54
435 查看
旧话重提：开发过程中的软件质量保证
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
bird 于 Sun Jul 25 14:23:56 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
最近，在开发过程中，软件质量的问题似乎变得越来越严重。
最直接的表现就是提交给用户的产品，即使是试用，bug一大堆。
回过头来看的话，其实从最初的需求分析、系统设计……，
一直最后的编码、测试，虽然是按部就班来的，但感觉都是流于形式。
当然，这必然会导致最终软件质量的下降，甚至是低劣。
软件工程的道理大家都明白，但项目一个紧跟着一个，
直接的后果就是开发周期被急剧压缩，所有的程序员、测试员都在赶工。
所以，我知道，真正要想解决软件质量的问题，必须从这方面着手。
但是，这也仅限于理论层面上，实际中，当一个利润相对丰厚的项目摆在面前时，
我们凭什么去和老板讲，“为了保证质量，我们需要放弃这个项目”？
市场在这里，这次错过了，下次就不一定有机会了。
所以说，感觉这是一个很突出的矛盾，而程序员对此似乎无能为力。
那么，在这种前提下，想和大家讨论一下如何尽可能地保证软件质量的问题。
你可能会说，一个高质量的软件需要高质量的分析、设计、编码、测试……
等等，还是那句话，这些道理我们都很明白。我想在一些的前提下讨论这个问题。
假设我们的需求分析做得已经足够好了，与客户的沟通不成问题，
那么，怎么样保证开发出来的软件产品确实满足需求，不会出现让用户抓狂的bug？
先谈一点个人的看法，在需求确定之后，我们假设后面不会再有所变动。
然后是整个系统的设计，我们也假设这个设计是可行的并且合理的。
接下来，应该是系统的实现，我把各个功能模块的设计归在这个过程中完成，
具体的细节完全由程序员自由发挥。当然，编码也在这个阶段完成。
最后是系统测试，其中包括各种类型、规模的测试，
可以说，测试是软件产品交付使用之前最重要的环节。
如果测试做得好，从理论上说测出了各种各样潜在问题的话，
那么我们可以很自信地说，我们的软件产品是高质量的。
但这都是不现实的，而且做为程序开发人员来说，我不想*过多*地依赖测试员。
还是希望能够尽量在前面我提到的完全由程序员参与的系统实现的过程中
扼杀一些潜在的可能导致软件质量下降的因素。
因此想听听大家的高见，在开发人员是一个由三五个人组成的group的情况下，
究竟怎么样才能够在纯粹的开发过程中尽可能地生产出高质量的软件？
欢迎讨论！
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
lostar 于 Sun Jul 25 15:50:13 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
提高价格，是提高质量的途径之一
如果一个项目两三个人，优秀的程序员所起到的作用不比软件工程低。
这时候，人是决定软件质量的一个重要因素。
钱多，用高质量开发人员，是一个不错的途径。
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 最近，在开发过程中，软件质量的问题似乎变得越来越严重。
: 最直接的表现就是提交给用户的产品，即使是试用，bug一大堆。
: 回过头来看的话，其实从最初的需求分析、系统设计……，
: 一直最后的编码、测试，虽然是按部就班来的，但感觉都是流于形式。
: 当然，这必然会导致最终软件质量的下降，甚至是低劣。
: 软件工程的道理大家都明白，但项目一个紧跟着一个，
: 直接的后果就是开发周期被急剧压缩，所有的程序员、测试员都在赶工。
: 所以，我知道，真正要想解决软件质量的问题，必须从这方面着手。
: 但是，这也仅限于理论层面上，实际中，当一个利润相对丰厚的项目摆在面前时，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
westmoon 于 Sun Jul 25 16:03:07 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
测试的人员和时间是必须的
毕竟总有考虑不到的地方
理想与现实啊~~
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 最近，在开发过程中，软件质量的问题似乎变得越来越严重。
: 最直接的表现就是提交给用户的产品，即使是试用，bug一大堆。
: 回过头来看的话，其实从最初的需求分析、系统设计……，
: 一直最后的编码、测试，虽然是按部就班来的，但感觉都是流于形式。
: 当然，这必然会导致最终软件质量的下降，甚至是低劣。
: 软件工程的道理大家都明白，但项目一个紧跟着一个，
: 直接的后果就是开发周期被急剧压缩，所有的程序员、测试员都在赶工。
: 所以，我知道，真正要想解决软件质量的问题，必须从这方面着手。
: 但是，这也仅限于理论层面上，实际中，当一个利润相对丰厚的项目摆在面前时，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
bird 于 Sun Jul 25 17:50:12 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
单纯对于开发来说，优秀的程序员肯定是必须的。
因此，可以说提高程序员水平是一方面。
那么，从管理上，或者从整个过程上来说，
有没有一些可行的控制手段来尽量保证质量呢？
【 在 lostar (lostar@createsun.com) 的大作中提到: 】
: 提高价格，是提高质量的途径之一
: 如果一个项目两三个人，优秀的程序员所起到的作用不比软件工程低。
: 这时候，人是决定软件质量的一个重要因素。
: 钱多，用高质量开发人员，是一个不错的途径。
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
bird 于 Sun Jul 25 17:51:42 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
是的，测试肯定是不能少的。其中考虑不到确实是一方面，
在这方面，测试员与程序员考虑问题的角度不同，
他们确实会提供一些很有建设性的意见和建议。
现在我的意思是，不考虑想法方面的问题，纯粹技术上的开发，
如何才能保证质量。
举个naive的例子，一个while循环，如果在条件后面多加了一个分号，
我想即使再有经验的程序员在编码的过程中也不敢保证一定不会出这样的错误，
但是如果在这段代码提交后，由另外一个程序员来check这段代码，
甚至单步跟踪调试，这种问题遗留的概率就很小了。
当然，这个例子属于极端初级的错误，一般程序员自己细心debug就会发现了。
只是想通过这个说明一点，我们是不是可以从一些管理的角度考虑提高质量。
毕竟，每个程序员的水平有限，不能指望所有的人一夜之间都变得优秀。
【 在 westmoon (Java Step by Step) 的大作中提到: 】
: 测试的人员和时间是必须的
: 毕竟总有考虑不到的地方
: 理想与现实啊~~
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 18:03:48 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
unit test + nightly build
测试结果第二天就在memeber的邮箱里了
Opensource都这么做的
我们也在努力做auto nighly build
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 是的，测试肯定是不能少的。其中考虑不到确实是一方面，
: 在这方面，测试员与程序员考虑问题的角度不同，
: 他们确实会提供一些很有建设性的意见和建议。
: 现在我的意思是，不考虑想法方面的问题，纯粹技术上的开发，
: 如何才能保证质量。
: 举个naive的例子，一个while循环，如果在条件后面多加了一个分号，
: 我想即使再有经验的程序员在编码的过程中也不敢保证一定不会出这样的错误，
: 但是如果在这段代码提交后，由另外一个程序员来check这段代码，
: 甚至单步跟踪调试，这种问题遗留的概率就很小了。
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
westmoon 于 Sun Jul 25 18:36:58 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
类似这种细节的问题xp结队应该能够解决
但是大局上的系统级测试就很难找到相应的办法
大概只有靠需求和分析设计阶段的细致工作了
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 是的，测试肯定是不能少的。其中考虑不到确实是一方面，
: 在这方面，测试员与程序员考虑问题的角度不同，
: 他们确实会提供一些很有建设性的意见和建议。
: 现在我的意思是，不考虑想法方面的问题，纯粹技术上的开发，
: 如何才能保证质量。
: 举个naive的例子，一个while循环，如果在条件后面多加了一个分号，
: 我想即使再有经验的程序员在编码的过程中也不敢保证一定不会出这样的错误，
: 但是如果在这段代码提交后，由另外一个程序员来check这段代码，
: 甚至单步跟踪调试，这种问题遗留的概率就很小了。
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 18:41:30 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
让我想起阿豆的那篇文章,哈哈
说说你的xp结对实践,我们看到一些缺点
【 在 westmoon (Java Step by Step) 的大作中提到: 】
: 类似这种细节的问题xp结队应该能够解决
: 但是大局上的系统级测试就很难找到相应的办法
: 大概只有靠需求和分析设计阶段的细致工作了
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
Jackle 于 Sun Jul 25 18:54:36 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
说说看啊。
缺点
【 在 hijack (孤读一身) 的大作中提到: 】
: 让我想起阿豆的那篇文章,哈哈
: 说说你的xp结对实践,我们看到一些缺点
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
Jackle 于 Sun Jul 25 19:00:43 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
我对这个比较感兴趣，能提供一些资料或者经验吗？
ps:你们有没有让用户参到整个项目中来的啊？
在XP中用户的参与很重要啊。
【 在 hijack (孤读一身) 的大作中提到: 】
: unit test + nightly build
: 测试结果第二天就在memeber的邮箱里了
: Opensource都这么做的
: 我们也在努力做auto nighly build
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
adoal 于 Sun Jul 25 19:06:48 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
你这个例子确实不好，因为它用lint这种机械化的办法就可以解决，:p
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 是的，测试肯定是不能少的。其中考虑不到确实是一方面，
: 在这方面，测试员与程序员考虑问题的角度不同，
: 他们确实会提供一些很有建设性的意见和建议。
: 现在我的意思是，不考虑想法方面的问题，纯粹技术上的开发，
: 如何才能保证质量。
: 举个naive的例子，一个while循环，如果在条件后面多加了一个分号，
: 我想即使再有经验的程序员在编码的过程中也不敢保证一定不会出这样的错误，
: 但是如果在这段代码提交后，由另外一个程序员来check这段代码，
: 甚至单步跟踪调试，这种问题遗留的概率就很小了。
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
westmoon 于 Sun Jul 25 19:09:59 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
牟实践，看了一些网上资料的结果
纸上谈兵而已-_-bb
【 在 hijack (孤读一身) 的大作中提到: 】
: 让我想起阿豆的那篇文章,哈哈
: 说说你的xp结对实践,我们看到一些缺点
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
lostar 于 Sun Jul 25 19:24:23 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
高质量的开发人员用上合适的工具，可以事半功倍 ：）
【 在 adoal (Isn't CMB crazy?) 的大作中提到: 】
: 你这个例子确实不好，因为它用lint这种机械化的办法就可以解决，:p
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
lostar 于 Sun Jul 25 19:25:25 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
对过程的关注可以减少一点，因为这方面我想现在你们做得已经差不多了。
管理并不是制定制度让别人去遵守，管理更重要的还是具体问题具体分析，
在计划、组织、控制、评估几个方面都需要花心思去考虑。
有时候一个员工评价指标的改变能导致意想不到的结果，有时候一个完善的
切实的计划能够保证项目风险的大大降低。
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 单纯对于开发来说，优秀的程序员肯定是必须的。
: 因此，可以说提高程序员水平是一方面。
: 那么，从管理上，或者从整个过程上来说，
: 有没有一些可行的控制手段来尽量保证质量呢？
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 19:28:16 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
去订阅一个开源项目developer的maillist或者参与开发
你就会亲身感受了
PS:我们的用户没有理想中的那样主动
不过我们还是使用了use story的跟踪系统
【 在 Jackle (睡睡~~WindForce) 的大作中提到: 】
: 我对这个比较感兴趣，能提供一些资料或者经验吗？
: ps:你们有没有让用户参到整个项目中来的啊？
: 在XP中用户的参与很重要啊。
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 19:23:12 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
公司的项目在技术上一般都会有一定的延续，
比如就开发语言可能一直是用c＋＋或者是java等等（还包括其他方面)
就某一技术领域内，
很多导致软件质量低下的情况往往雷同，
也就是低水平的设计和代码都会有一些常见的问题，
或者说经验不足者通常会范一些常见的错误，
从另外一个方面来说，
高水平低bug的设计和代码都会有一些共同之处，
（比如一些模式的应用就来源于这样的想法）
所以，在技术上，应该逐渐通过一些措施的引导，
建立起一些设计和code的标准，
鼓励使用优秀的习惯，杜绝不良的设计和编码风格，
从而避免一些容易导致软件质量低下的问题，
在我们公司，任何一个正式的软件流程都会有比较正式的
review，尽可能保证该过程成果的高质量，
设计的review当然是重中之中，
就代码而言，也会有比较正式的review，
查看代码的常见问题和风格，以及逻辑上的一些问题，
是否存在比较大的问题等等，
当然这些都需要比较大的精力投入，
我现在感觉老外做软件各方面投入真的是非常大，
如果是同样大的项目，
叫中国的公司来做可能一般的老板肯投个1/3都差不多了（个人感觉：）
也难怪他们的质量比较高（当然换了中国的公司就算给同样的
投入做出的软件质量也达不到那个水平，有了这么多投入说不定还
不知道怎么用呢：）
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 单纯对于开发来说，优秀的程序员肯定是必须的。
: 因此，可以说提高程序员水平是一方面。
: 那么，从管理上，或者从整个过程上来说，
: 有没有一些可行的控制手段来尽量保证质量呢？
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 19:48:09 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
建立起一些设计和code的标准，
鼓励使用优秀的习惯，杜绝不良的设计和编码风格，
?@.@?
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 公司的项目在技术上一般都会有一定的延续，
: 比如就开发语言可能一直是用c＋＋或者是java等等（还包括其他方面)
: 就某一技术领域内，
: 很多导致软件质量低下的情况往往雷同，
: 也就是低水平的设计和代码都会有一些常见的问题，
: 或者说经验不足者通常会范一些常见的错误，
: 从另外一个方面来说，
: 高水平低bug的设计和代码都会有一些共同之处，
: （比如一些模式的应用就来源于这样的想法）
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 19:49:31 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
说漏了？（大侠指点一下）
标准不可能细到所有的程度的吧？
（现实没这么理想的吧，我觉得）
标准一般说来还是比较high-level层次，
对于具体的情况，肯定还是有一些事情要具体问题具体分析，
这些时候就要靠经验丰富者指点的优良风格和优良习惯了，
通常是,技术老大看到下面的人写的代码和设计，
然后说，这样的设计可能会出现如何如何的问题，
应该如何如何设计和写如何如何的代码，
然后把原因解释一通，
说的一般都很圆，有的时候觉得蛮有道理的，
有的时候又不知道真正的情况，对于这个具体的问题，
是否真的如其所言呢：）
【 在 hijack (孤读一身) 的大作中提到: 】
: 建立起一些设计和code的标准，
: 鼓励使用优秀的习惯，杜绝不良的设计和编码风格，
: ?@.@?
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 19:55:04 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
而且，建立标准真的是一个漫长的过程，
不容易做到，不容易做好，
我个人觉得开始也就是避免那些常见错误，在那些典型情况下
应该如何做，
我看到的review主要还是依靠人，依靠他们在开发过程中
积累的经验
要真的做的比较好，可能需要在一个技术领域内有比较长的
开发历史吧，
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 说漏了？（大侠指点一下）
: 标准不可能细到所有的程度的吧？
: （现实没这么理想的吧，我觉得）
: 标准一般说来还是比较high-level层次，
: 对于具体的情况，肯定还是有一些事情要具体问题具体分析，
: 这些时候就要靠经验丰富者指点的优良风格和优良习惯了，
: 通常是,技术老大看到下面的人写的代码和设计，
: 然后说，这样的设计可能会出现如何如何的问题，
: 应该如何如何设计和写如何如何的代码，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 19:57:58 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
一个公司有7年编程经验的程序员(现在还在写程序)到底有多少阿?
5年的有多少?
3年的有多少?
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 说漏了？（大侠指点一下）
: 标准不可能细到所有的程度的吧？
: （现实没这么理想的吧，我觉得）
: 标准一般说来还是比较high-level层次，
: 对于具体的情况，肯定还是有一些事情要具体问题具体分析，
: 这些时候就要靠经验丰富者指点的优良风格和优良习惯了，
: 通常是,技术老大看到下面的人写的代码和设计，
: 然后说，这样的设计可能会出现如何如何的问题，
: 应该如何如何设计和写如何如何的代码，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
bird 于 Sun Jul 25 20:04:37 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
哪里可以找到这些相关的工具？以前真没怎么用过，打算试试看。
【 在 lostar (lostar@createsun.com) 的大作中提到: 】
: 高质量的开发人员用上合适的工具，可以事半功倍 ：）
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
bird 于 Sun Jul 25 20:05:20 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
所以也正在考虑使用一些机械化的办法，来专门处理类似的问题，
或者不能叫处理，防患于未然吧。
能否推荐几个比较好的工具？
【 在 adoal (Isn't CMB crazy?) 的大作中提到: 】
: 你这个例子确实不好，因为它用lint这种机械化的办法就可以解决，:p
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
bird 于 Sun Jul 25 20:08:32 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
听起来很好，可实际上一般同时会处理n个项目，似乎可行性值得商榷。
【 在 hijack (孤读一身) 的大作中提到: 】
: unit test + nightly build
: 测试结果第二天就在memeber的邮箱里了
: Opensource都这么做的
: 我们也在努力做auto nighly build
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
bird 于 Sun Jul 25 20:10:12 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
非常同意你的观点。
1. 投入少，少到没法说了，呵呵。
2. 必须要进行各种形式详尽的review，实际上我们做得很不够。
3. 编码规范，有是有的，效果不是特别好，总不成强制勒令每个人都这样，
在这点上，可能要讲究一点人员管理的策略了。似乎大家都不够积极。
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 公司的项目在技术上一般都会有一定的延续，
: 比如就开发语言可能一直是用c＋＋或者是java等等（还包括其他方面)
: 就某一技术领域内，
: 很多导致软件质量低下的情况往往雷同，
: 也就是低水平的设计和代码都会有一些常见的问题，
: 或者说经验不足者通常会范一些常见的错误，
: 从另外一个方面来说，
: 高水平低bug的设计和代码都会有一些共同之处，
: （比如一些模式的应用就来源于这样的想法）
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 20:02:34 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
我们这里的arch，听说要求是25年软件开发经验（当然都在国外）
算起来至少是79年前了，
刚来一个leader，中国人，好像到现在差不多也快20年了，
他说他95开始学java，在第一线又干了几年，当然现在不在第一线了，
有7年编程经验还写代码的还是有一些的，
有一些已经不写代码了，但是在review的时候
是主要人物，部门成立小组专门做标准（一方面是标准，
另外希望最终可以达到peer review）也要这样的人来领导
经验主要在这个时候体现作用，现在是不是还在写代码不重要，
ms你说的好像是开发人员的素质问题，
写代码的人可以没有太多的经验，
但是递交的代码专门有人review，还是可以在一定程度上保证质量的，
当然，招人的时候有严格的过程，也尽量保证进来写代码的人
写出来的代码质量比较高，回到前面说的开发人员素质问题了，
【 在 hijack (孤读一身) 的大作中提到: 】
: 一个公司有7年编程经验的程序员(现在还在写程序)到底有多少阿?
: 5年的有多少?
: 3年的有多少?
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
mwong 于 Sun Jul 25 20:17:02 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
JTest for java code
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 所以也正在考虑使用一些机械化的办法，来专门处理类似的问题，
: 或者不能叫处理，防患于未然吧。
: 能否推荐几个比较好的工具？
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 20:16:14 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
我说的恰恰事你要阐述的问题背后的因素
程序员经验到底有多少可以继承下来的?
你们部门你可以权衡一下
7年经验的占?%
5年?%
3年?%
还有,我理解不了你的表达, 你一方面说你们的质量 主要看review
一方面有说主要看程序员自己的素质
那主要看什么那?
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 我们这里的arch，听说要求是25年软件开发经验（当然都在国外）
: 算起来至少是79年前了，
: 刚来一个leader，中国人，好像到现在差不多也快20年了，
: 他说他95开始学java，在第一线又干了几年，当然现在不在第一线了，
: 有7年编程经验还写代码的还是有一些的，
: 有一些已经不写代码了，但是在review的时候
: 是主要人物，部门成立小组专门做标准（一方面是标准，
: 另外希望最终可以达到peer review）也要这样的人来领导
: 经验主要在这个时候体现作用，现在是不是还在写代码不重要，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
lostar 于 Sun Jul 25 20:18:40 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
这个就看开发者的经验了
对于工具，hijack比较熟的，可以咨询他。呵呵
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 哪里可以找到这些相关的工具？以前真没怎么用过，打算试试看。
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 20:19:40 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
没有监督,标准都是狗屁
不在第一线工作的人定的标准同样是狗屁文件
只是给ISO等一些用的
我们最有用永远是在team cvs里的代码规范
每个team都不一样的
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 我们这里的arch，听说要求是25年软件开发经验（当然都在国外）
: 算起来至少是79年前了，
: 刚来一个leader，中国人，好像到现在差不多也快20年了，
: 他说他95开始学java，在第一线又干了几年，当然现在不在第一线了，
: 有7年编程经验还写代码的还是有一些的，
: 有一些已经不写代码了，但是在review的时候
: 是主要人物，部门成立小组专门做标准（一方面是标准，
: 另外希望最终可以达到peer review）也要这样的人来领导
: 经验主要在这个时候体现作用，现在是不是还在写代码不重要，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 20:15:36 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
对于投入，我最近感受非常深刻，
觉得以前对于高质量软件开发所需要的工程量
的估计一直都过低的厉害，
有的时候ms急进也可以做出来，
尤其是土生土长的中国人，很喜欢这样（当然又聪明又能干也是一个方面：）
但是感觉这事实上是非常危险的做完
明显的特点是华为跳槽过来的员工，
经常干活特别的快，leader说这个礼拜我们先
做一些research的事情，然后大家讨论一下如何设计，
下周我们拿个方案出来，但是下个礼拜那哥们说，
我已经全部做完了，我们都晕倒。。
当然个人能力可能是一个方面，但是总的感觉是国外回来的人
通常喜欢按部就班一点，一步一步慢慢来，
另外就是他们不喜欢一次做太多的东西，怕风险太大，
万一失败了底线都完不成，
而且他们一般喜欢考虑万一这个
方案到时候实现的时候发现都太多的困难没想到，
有没有备用的非常保险的方案，华为过来那哥们常说的就是，
这个方案就不能失败，他这样有的时候是蛮好的，干活特别快，
但我总担心他那天会出问题
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 非常同意你的观点。
: 1. 投入少，少到没法说了，呵呵。
: 2. 必须要进行各种形式详尽的review，实际上我们做得很不够。
: 3. 编码规范，有是有的，效果不是特别好，总不成强制勒令每个人都这样，
: 在这点上，可能要讲究一点人员管理的策略了。似乎大家都不够积极。
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 20:25:12 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
说说你们review是怎样进行的吧
review的结果怎样传递?
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 而且，建立标准真的是一个漫长的过程，
: 不容易做到，不容易做好，
: 我个人觉得开始也就是避免那些常见错误，在那些典型情况下
: 应该如何做，
: 我看到的review主要还是依靠人，依靠他们在开发过程中
: 积累的经验
: 要真的做的比较好，可能需要在一个技术领域内有比较长的
: 开发历史吧，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
bird 于 Sun Jul 25 20:28:36 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
C++呢？
【 在 mwong (罐头米糕の在人间) 的大作中提到: 】
: JTest for java code
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 20:28:01 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
哈哈,你们的员工招聘后的适应期我不敢恭维了
拿华为的那个来说,我甚至觉得你们是失败的,
你们是个team,应该有自己的culture吧,
向我们曾经为自己的team设计了图标和slogan
可以看出华为在这点成功的,因为他们把程序员往他们的文化去塑造
你们用人太急了吧
还没有把它往你们的文化这边塑造,就敢用阿
所以开发节奏肯定会不一致
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 对于投入，我最近感受非常深刻，
: 觉得以前对于高质量软件开发所需要的工程量
: 的估计一直都过低的厉害，
: 有的时候ms急进也可以做出来，
: 尤其是土生土长的中国人，很喜欢这样（当然又聪明又能干也是一个方面：）
: 但是感觉这事实上是非常危险的做完
: 明显的特点是华为跳槽过来的员工，
: 经常干活特别的快，leader说这个礼拜我们先
: 做一些research的事情，然后大家讨论一下如何设计，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 20:27:06 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
我也是刚过来，这里差不多每天都有开会，
但是都讨论有内容的东西，
如果review一个人的工作，
会让他把他整个过程介绍给参加讨论的人，
（负责review的人就是那些经验很丰富的人）
然后大家开始讨论，基本上开完会每个人都知道他做的
设计成果的大体流程了，
（当然象我这样的人也就努力听听懂，基本没有什么建设性的意见
可以提）
那些老大级的人物有些时候会指出存在的问题，提出
修改意见，一些槽糕的设计会被否定，然后下面的人
回去继续修改，下次再拿出方案大家继续讨论，直到
老大觉得技术上ok了，没什么问题了，
设计基本就是这样，
代码的review我还没参加过，
但是ms这个在公司蛮重要的，
【 在 hijack (孤读一身) 的大作中提到: 】
: 说说你们review是怎样进行的吧
: review的结果怎样传递?
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
adoal 于 Sun Jul 25 20:35:37 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
【 在 hijack (孤读一身) 的大作中提到: 】
: 哈哈,你们的员工招聘后的适应期我不敢恭维了
: 拿华为的那个来说,我甚至觉得你们是失败的,
: 你们是个team,应该有自己的culture吧,
: 向我们曾经为自己的team设计了图标和slogan
: 可以看出华为在这点成功的,因为他们把程序员往他们的文化去塑造
这倒不一定式华为刻意塑造出来的。
华为毕竟不是软件公司，软件开发在华为这一派系的公司
（譬如从华为出来的人办的港湾）里的作用，和在专门的
软件公司里毕竟是不一样的。在港湾的程序员告诉我说，
他现在用到的最复杂的数据结构是线性数组……：）
: 你们用人太急了吧
: 还没有把它往你们的文化这边塑造,就敢用阿
: 所以开发节奏肯定会不一致
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 20:36:07 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
如果按你那样说,很耗时间的,
耗时间 == 耗开发人员的激情
我得感觉,你们的机构可能有点臃肿
我们曾经一段时间也做过code review
用cvs来做的,自己弄了个eclipse plugin
后来还是消失了, 因为我觉得运行相应的测试代码就OK了
需要修改的打个TODO的标签
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 我也是刚过来，这里差不多每天都有开会，
: 但是都讨论有内容的东西，
: 如果review一个人的工作，
: 会让他把他整个过程介绍给参加讨论的人，
: （负责review的人就是那些经验很丰富的人）
: 然后大家开始讨论，基本上开完会每个人都知道他做的
: 设计成果的大体流程了，
: （当然象我这样的人也就努力听听懂，基本没有什么建设性的意见
: 可以提）
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 20:36:02 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
【 在 hijack (孤读一身) 的大作中提到: 】
: 我说的恰恰事你要阐述的问题背后的因素
: 程序员经验到底有多少可以继承下来的?
（这个我对软件行业了解还太少，但是我想可以继承下来的肯定还是蛮多的吧，
如果在技术领域上有一脉相承的话，应该是很多继承的）
: 你们部门你可以权衡一下
: 7年经验的占?%
: 5年?%
: 3年?%
: 还有,我理解不了你的表达, 你一方面说你们的质量 主要看review
: 一方面有说主要看程序员自己的素质
: 那主要看什么那?
我想review和程序员的素质对于软件质量保证都很重要吧，
我如果前面有表达了一个更重要的意思，那是我表达有误，逻辑不严密，
但是楼主说到过程上的一些保证软件质量的方法，
我当然说到了把review作为一个重要过程了，因为程序员素质不是软件开发过程的事情
（上面的话没什么太多的漏洞吧？）
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
lostar 于 Sun Jul 25 20:41:59 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
这些各有各的做法，并不要求每个team都一致啊
某个工作在你这个team切实解决问题的，那你们就会去做，相反则不会。
所以不必强求
【 在 hijack (孤读一身) 的大作中提到: 】
: 如果按你那样说,很耗时间的,
: 耗时间 == 耗开发人员的激情
: 我得感觉,你们的机构可能有点臃肿
: 我们曾经一段时间也做过code review
: 用cvs来做的,自己弄了个eclipse plugin
: 后来还是消失了, 因为我觉得运行相应的测试代码就OK了
: 然后打个TODO的标签
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 20:43:46 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
KISS
我不知道这里有没有喜欢每天开会的开发人员?
如果有,出来交流一下好么?
我比较好奇
【 在 lostar (lostar@createsun.com) 的大作中提到: 】
: 这些各有各的做法，并不要求每个team都一致啊
: 某个工作在你这个team切实解决问题的，那你们就会去做，相反则不会。
: 所以不必强求
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
lostar 于 Sun Jul 25 20:47:10 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
我喜欢开会，不过我不是开发人员，哈哈
但是估计让我每天开会，我也很难受的，估计会以质量也就不高了
【 在 hijack (孤读一身) 的大作中提到: 】
: KISS
: 我不知道这里有没有喜欢每天开会的开发人员?
: 如果有,出来交流一下好么?
: 我比较好奇
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 20:43:52 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
【 在 hijack (孤读一身) 的大作中提到: 】
: 如果按你那样说,很耗时间的,
需要比较多的时间投入，但就我目前的感觉而言，这应该是值得的
: 耗时间 == 耗开发人员的激情
首先，我想投入比较多的时间不等于你说的“耗时间”，ms我没看到
开发人员没有激情，
: 我得感觉,你们的机构可能有点臃肿
我的感觉相反，高质量的软件或许正是需要大量的投入才可以保证一定可以做出来，
降低风险，
我以前的对于软件开发需要的工程量的估计过于偏低了（很可能你的也是）
当然，可能不同的项目其他方面的压力和限制不一样，
尤其是市场因素引起的时间限制等
: 我们曾经一段时间也做过code review
: 用cvs来做的,自己弄了个eclipse plugin
: 后来还是消失了, 因为我觉得运行相应的测试代码就OK了
: 需要修改的打个TODO的标签
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 20:50:07 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
你们做产品?
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 需要比较多的时间投入，但就我目前的感觉而言，这应该是值得的
: 首先，我想投入比较多的时间不等于你说的“耗时间”，ms我没看到
: 开发人员没有激情，
: 我的感觉相反，高质量的软件或许正是需要大量的投入才可以保证一定可以做出来，
: 降低风险，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
adoal 于 Sun Jul 25 20:44:33 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: （这个我对软件行业了解还太少，但是我想可以继承下来的肯定还是蛮多的吧，
: 如果在技术领域上有一脉相承的话，应该是很多继承的）
经验的继承不外乎有两种方法，一是在实践中口耳相传，
就像工艺领域的师徒那样，一是系统化，理论化，成文
传于后世。
如果一个开发团队的人员构成不够稳定，有多年工作经验
的人占的比例很少，那么口耳相传的方式就有很大问题，
一则师父自己的经验积累起来没多久可能就溜掉了，二则
本来可以做师父的人也许还没达到做师父的境界就走了，:p
至于系统化的方式……系统化本身就是比直接经验继承更
需要时间的事情，:p
Microsoft的十多个Chief Architect，里面大多数都是在
MS工作了十年以上甚至和公司接近同龄的人。
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 20:49:00 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
恩，你说的问题可能的确有，
因为我看到有同事打开outlook时经常说，
又开会！
但是，这里的会的确和我以前概念中的会不太一样，
真的每次讨论都是有非常实在的内容，
有leader的指点，同时也发挥team的力量，
大家都贡献自己的想法，无论是否正确，
【 在 hijack (孤读一身) 的大作中提到: 】
: KISS
: 我不知道这里有没有喜欢每天开会的开发人员?
: 如果有,出来交流一下好么?
: 我比较好奇
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 20:51:22 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
是的，inventor,3维机械设计软件，
如果你不知道的话就想象是3dmax或者是autocad，
那是另外部门做的，使用上看的话和3dmax共同处多一些
我虽然不知道他们部门的开发过程，但是我想一个公司
里面应该相差不太大，
【 在 hijack (孤读一身) 的大作中提到: 】
: 你们做产品?
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 20:53:43 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
呵呵,我不是说你们的公司,我也没权利,我是不知情的
我不知道我得观点对不对:
用最简单的方式去做事
可能我们的team比你们小的多吧
因为简单对我们而言就是高效
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 恩，你说的问题可能的确有，
: 因为我看到有同事打开outlook时经常说，
: 又开会！
: 但是，这里的会的确和我以前概念中的会不太一样，
: 真的每次讨论都是有非常实在的内容，
: 有leader的指点，同时也发挥team的力量，
: 大家都贡献自己的想法，无论是否正确，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 20:55:36 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
【 在 adoal (Isn't CMB crazy?) 的大作中提到: 】
: 经验的继承不外乎有两种方法，一是在实践中口耳相传，
: 就像工艺领域的师徒那样，一是系统化，理论化，成文
: 传于后世。
: 如果一个开发团队的人员构成不够稳定，有多年工作经验
: 的人占的比例很少，那么口耳相传的方式就有很大问题，
: 一则师父自己的经验积累起来没多久可能就溜掉了，二则
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
lostar 于 Sun Jul 25 20:56:26 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
说到这个，就需要提提企业的知识管理了。。。
以下内容为转载
知识管理大致包括以下6个内容：(1)知识管理的基础措施：它是知识管理的支持部
分，如数据库、知识库、多库协调系统、网络等基本技术手段以及人与人之间的各
种联系渠道等；(2)企业业务流程的重组：其目的是使企业的知识资源更加合理地
在知识链上形成畅通无阻的知识流，让每一个员工在获取与业务有关知识的同时，
都能为企业贡献自己的知识、经验和专长；(3)知识管理的方法：内容管理、文件
管理、记录管理、通信管理等；(4)知识的获取和检索：包括各种各样的软件应用
工具，例如智能客体检索、多策略获取、多模式获取和检索、多方法多层次获取和
检索、网络搜索工具等；(5)知识的传递：如建立知识分布图、电子文档、光盘、
DVD及网上传输、打印等；(6)知识的共享和评测：如建立一种良好的企业文化，激
励员工参与知识共享、设立知识总管、促进知识的转换、建立知识产生效益的评测
条例等。如何进行知识管理是我们首先要解决的理论和实际问题。
为此，我们把企业的业务流程看作是一个紧密连接的供应链，并将企业内部划分成
几个相互协同作业的支持子系统。将企业知识管理系统设计为：以知识生产、分配
，交换、获取、利用为主线，建立企业知识库系统。该系统还包括非知识资源子系
统、财务运作子系统、供给子系统、生产制造子系统、服务维护子系统、工程技术
子系统、市场营销子系统。
【 在 adoal (Isn't CMB crazy?) 的大作中提到: 】
: 经验的继承不外乎有两种方法，一是在实践中口耳相传，
: 就像工艺领域的师徒那样，一是系统化，理论化，成文
: 传于后世。
: 如果一个开发团队的人员构成不够稳定，有多年工作经验
: 的人占的比例很少，那么口耳相传的方式就有很大问题，
: 一则师父自己的经验积累起来没多久可能就溜掉了，二则
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
adoal 于 Sun Jul 25 20:57:39 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
有时候，某一方面的复杂是为了另一方面的简单，:p
【 在 hijack (孤读一身) 的大作中提到: 】
: 呵呵,我不是说你们的公司,我也没权利,我是不知情的
: 我不知道我得观点对不对:
: 用最简单的方式去做事
: 可能我们的team比你们小的多吧
: 因为简单对我们而言就是高效
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 20:59:14 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
嗯,有道理, 这就是封装,然后提供简单接口, 呵呵
【 在 adoal (Isn't CMB crazy?) 的大作中提到: 】
: 有时候，某一方面的复杂是为了另一方面的简单，:p
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
adoal 于 Sun Jul 25 21:00:37 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
而且对不同工作量、不同复杂程度的任务来说，
究竟哪种方式代价更小也是需要具体分析的。
【 在 hijack (孤读一身) 的大作中提到: 】
: 嗯,有道理, 这就是封装,然后提供简单接口, 呵呵
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 20:59:49 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
哦，可能我的理解有误，
我不知道hijack的继承究竟是你说的还是我说的，
我说的继承是指对于一个人本身，
他在这个领域内做了很多年，会积累一些经验，
这些经验他自己可以保留下来以后看到别人的设计，代码
等都会有用，可以很快的分辨出优良的和拙劣的
ms这里现在起作用的主要就是这些经验，
你说的继承是从一个人继承到另外一个人，
这个我不太清楚，这个部门在中国的分部建立还没超过一年，
我过来更是一个月都没，
目前看到的主要还是口耳相传为主，
但是也有一些培训和一些成文档的东西，
【 在 adoal (Isn't CMB crazy?) 的大作中提到: 】
: 经验的继承不外乎有两种方法，一是在实践中口耳相传，
: 就像工艺领域的师徒那样，一是系统化，理论化，成文
: 传于后世。
: 如果一个开发团队的人员构成不够稳定，有多年工作经验
: 的人占的比例很少，那么口耳相传的方式就有很大问题，
: 一则师父自己的经验积累起来没多久可能就溜掉了，二则
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 21:05:24 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
adoal和我表达的是一个意思
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 哦，可能我的理解有误，
: 我不知道hijack的继承究竟是你说的还是我说的，
: 我说的继承是指对于一个人本身，
: 他在这个领域内做了很多年，会积累一些经验，
: 这些经验他自己可以保留下来以后看到别人的设计，代码
: 等都会有用，可以很快的分辨出优良的和拙劣的
: ms这里现在起作用的主要就是这些经验，
: 你说的继承是从一个人继承到另外一个人，
: 这个我不太清楚，这个部门在中国的分部建立还没超过一年，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
adoal 于 Sun Jul 25 21:12:35 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
嗯。所以还是要有经验的，hoho
【 在 hijack (孤读一身) 的大作中提到: 】
: 这个...
: 理性分析颗粒度不能无穷下去
: 作产品有市场压力
: 做工程有客户压力
: 做开源也有市场压力啊
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 21:13:31 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
【 在 hijack (孤读一身) 的大作中提到: 】
: 没有监督,标准都是狗屁
: 不在第一线工作的人定的标准同样是狗屁文件
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~这个我不敢赞同，
他以前一直都在写代码，知道写代码的常见的问题，
虽然他现在不是第一线了，我觉得定的标准还是有指导意义的吧？
我觉得你说的是不是从来没在第一线工作过的人定的是狗屁？
: 只是给ISO等一些用的
: 我们最有用永远是在team cvs里的代码规范
: 每个team都不一样的
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 21:16:14 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
我不知道你为什么会提到这个继承？
这个继承难度比较大的吧？
直接依靠他自己积累的丰富经验的比较多吧？
【 在 hijack (孤读一身) 的大作中提到: 】
: adoal和我表达的是一个意思
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 21:34:39 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
这个可以看出一个公司很多东西了啊;)
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 我不知道你为什么会提到这个继承？
: 这个继承难度比较大的吧？
: 直接依靠他自己积累的丰富经验的比较多吧？
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 21:35:28 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
今天一个在苏州工作的同学,跟我说了他们老板的一句话:
老板也会犯错的...
我不是说这种标准不好,我得意思是不要把它看成红宝书,圣经
如果把它放到wiki或者大家都可以来完善的地方,我会觉得很好
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~这个我不敢赞同，
: 他以前一直都在写代码，知道写代码的常见的问题，
: 虽然他现在不是第一线了，我觉得定的标准还是有指导意义的吧？
: 我觉得你说的是不是从来没在第一线工作过的人定的是狗屁？
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
ArtWalker 于 Sun Jul 25 22:54:05 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
推荐一个
【 在 hijack (孤读一身) 的大作中提到: 】
: 去订阅一个开源项目developer的maillist或者参与开发
: 你就会亲身感受了
: PS:我们的用户没有理想中的那样主动
: 不过我们还是使用了use story的跟踪系统
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
ArtWalker 于 Sun Jul 25 22:57:18 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
你现在在哪实习啊？貌似是个牛公司
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 我们这里的arch，听说要求是25年软件开发经验（当然都在国外）
: 算起来至少是79年前了，
: 刚来一个leader，中国人，好像到现在差不多也快20年了，
: 他说他95开始学java，在第一线又干了几年，当然现在不在第一线了，
: 有7年编程经验还写代码的还是有一些的，
: 有一些已经不写代码了，但是在review的时候
: 是主要人物，部门成立小组专门做标准（一方面是标准，
: 另外希望最终可以达到peer review）也要这样的人来领导
: 经验主要在这个时候体现作用，现在是不是还在写代码不重要，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Mon Jul 26 10:11:47 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
好的开发环境，和好的PM
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 最近，在开发过程中，软件质量的问题似乎变得越来越严重。
: 最直接的表现就是提交给用户的产品，即使是试用，bug一大堆。
: 回过头来看的话，其实从最初的需求分析、系统设计……，
: 一直最后的编码、测试，虽然是按部就班来的，但感觉都是流于形式。
: 当然，这必然会导致最终软件质量的下降，甚至是低劣。
: 软件工程的道理大家都明白，但项目一个紧跟着一个，
: 直接的后果就是开发周期被急剧压缩，所有的程序员、测试员都在赶工。
: 所以，我知道，真正要想解决软件质量的问题，必须从这方面着手。
: 但是，这也仅限于理论层面上，实际中，当一个利润相对丰厚的项目摆在面前时，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Mon Jul 26 10:12:30 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
同意，不过还有的问题就是，上层管理者的素质
如果管理者不能下放足够的权限，而是用各个条条框框约束你
并且PM也非常的无能，一切都需要看Coder背地里使用更好的方法
那么，我想技术Coder再牛也没什么用
【 在 lostar (lostar@createsun.com) 的大作中提到: 】
: 提高价格，是提高质量的途径之一
: 如果一个项目两三个人，优秀的程序员所起到的作用不比软件工程低。
: 这时候，人是决定软件质量的一个重要因素。
: 钱多，用高质量开发人员，是一个不错的途径。
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Mon Jul 26 10:14:48 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 标 题: Re: 旧话重提：开发过程中的软件质量保证
: 发信站: 飘渺水云间 (Sun Jul 25 17:58:58 2004), 转信
:
:
: 是的，测试肯定是不能少的。其中考虑不到确实是一方面，
: 在这方面，测试员与程序员考虑问题的角度不同，
: 他们确实会提供一些很有建设性的意见和建议。
:
: 现在我的意思是，不考虑想法方面的问题，纯粹技术上的开发，
: 如何才能保证质量。
:
: 举个naive的例子，一个while循环，如果在条件后面多加了一个分号，
: 我想即使再有经验的程序员在编码的过程中也不敢保证一定不会出这样的错误，
: 但是如果在这段代码提交后，由另外一个程序员来check这段代码，
: 甚至单步跟踪调试，这种问题遗留的概率就很小了。
你这个例子和编程风格有关，如果你用
while(){
}
代替
while()
{
}
我想这个问题就不会发生了吧？所以在软件开发中，团队采用统一的，经过精心
设计的风格也非常重要，当然review代码也很重要，但是review的效率应该是很
低的，我现在做得东西对公司来说非常重要，但是PM至今未找到合适的人给我
review代码，完全靠我自己。我认为结对编程应该可以提高coding和review的效
率，不过一直没尝试，因为结对编程的成本也很高。
:
: 当然，这个例子属于极端初级的错误，一般程序员自己细心debug就会发现了。
: 只是想通过这个说明一点，我们是不是可以从一些管理的角度考虑提高质量。
:
: 毕竟，每个程序员的水平有限，不能指望所有的人一夜之间都变得优秀。
:
:
:
:
: --
: ═╮═╬═══╬═ ║ ╠═══════╯╭══╦═╦══╮
: ╰ ╭═╮╭═╮ ╰══╮║╭══╯╯║ ║ ║ ║ ╰══╩═╩══╯
: ═╮ ╰═╯╰═╯ ╭╯║╰╮ ╬═╬═╬═╬ ╰══╣ ╠══╯
: ╰╭╯══╬═╯ ╭╯ ║ ╰╮ ═╩═╩═╩═╩═╰══╣ ╠══╯
: ╭ ║══╬═╯╰╯ ║ ╰╯ ║ ║ ║ ║ ╰══╣ ╠══╯
: ═╯ ╯══╩═╯ ╰╯ ╯ ╯ ╰ ╰ ╯ ╯
:
: ※ 来源:·飘渺水云间 freecity.cn·[FROM: bird]
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Mon Jul 26 10:19:22 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
必须和一批优秀的人在一起才能这么做
否则系统的设计完全达不到unit test的要求
我现在想在现有系统中添如unit test都非常困难
因为没有足够的接口支持
【 在 hijack (孤读一身) 的大作中提到: 】
: unit test + nightly build
: 测试结果第二天就在memeber的邮箱里了
: Opensource都这么做的
: 我们也在努力做auto nighly build
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Mon Jul 26 10:20:52 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
呵呵，我回上面的帖子，谈结对编程的时候，满脑子也都是adoal的那篇文章:P
也许是国内大部分企业都没有结对编程的环境:)
【 在 hijack (孤读一身) 的大作中提到: 】
: 让我想起阿豆的那篇文章,哈哈
: 说说你的xp结对实践,我们看到一些缺点
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Mon Jul 26 10:24:01 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
这个让人非常沮丧，我想在7年后依然可以coding，
但是我想那时我肯定因为环境的原因被迫去做管理，或是别的事情
虽然这些也是我喜欢的:)
【 在 hijack (孤读一身) 的大作中提到: 】
: 一个公司有7年编程经验的程序员(现在还在写程序)到底有多少阿?
: 5年的有多少?
: 3年的有多少?
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Mon Jul 26 10:28:13 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
ms中国的程序员不够懒，嘿嘿
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 对于投入，我最近感受非常深刻，
: 觉得以前对于高质量软件开发所需要的工程量
: 的估计一直都过低的厉害，
: 有的时候ms急进也可以做出来，
: 尤其是土生土长的中国人，很喜欢这样（当然又聪明又能干也是一个方面：）
: 但是感觉这事实上是非常危险的做完
: 明显的特点是华为跳槽过来的员工，
: 经常干活特别的快，leader说这个礼拜我们先
: 做一些research的事情，然后大家讨论一下如何设计，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Mon Jul 26 10:32:02 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
那天yy跟我说过的，我忘了:(上海某公司
【 在 ArtWalker (直觉艺术家.Evolution) 的大作中提到: 】
: 你现在在哪实习啊？貌似是个牛公司
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
lostar 于 Mon Jul 26 10:53:24 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
开发人员应该包含PM和Coder
其实我比较提倡这样的小团队不要把职务定的这样死，
我提倡分工明确、各方面都有一个人负责就行了。
而PM并不是领导，只是负责一些计划等工作。
刚刚看到一句话叫作“天下兴亡，我的责任”
大家都以出色的完成项目为己任的话，这个项目团队会更具有战斗力。
【 在 LazyCoder (未婚好男人) 的大作中提到: 】
: 同意，不过还有的问题就是，上层管理者的素质
: 如果管理者不能下放足够的权限，而是用各个条条框框约束你
: 并且PM也非常的无能，一切都需要看Coder背地里使用更好的方法
: 那么，我想技术Coder再牛也没什么用
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Mon Jul 26 10:59:15 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
【 在 lostar (lostar@createsun.com) 的大作中提到: 】
: 开发人员应该包含PM和Coder
: 其实我比较提倡这样的小团队不要把职务定的这样死，
: 我提倡分工明确、各方面都有一个人负责就行了。
: 而PM并不是领导，只是负责一些计划等工作。
: 刚刚看到一句话叫作“天下兴亡，我的责任”
这句话ms只能对自己要求，如果作为PM，你硬要说“天下兴亡 ，每个人的责任”
我想肯定作不好的，而仅仅一个Coder这么认为，当然也是作不好的
你有什么办法让每个Coder都这么认为吗？我想这应该是PM的管理能力的体现
: 大家都以出色的完成项目为己任的话，这个项目团队会更具有战斗力。
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
lostar 于 Mon Jul 26 11:04:59 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
现在都强调team work，3个人，如果是一个管另外两个，我倒觉得不如三个人
是一个团队来的更好。当然，前提是成员都是高素质的。
【 在 LazyCoder (未婚好男人) 的大作中提到: 】
: 这句话ms只能对自己要求，如果作为PM，你硬要说“天下兴亡 ，每个人的责任”
: 我想肯定作不好的，而仅仅一个Coder这么认为，当然也是作不好的
: 你有什么办法让每个Coder都这么认为吗？我想这应该是PM的管理能力的体现
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Mon Jul 26 11:07:18 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
【 在 lostar (lostar@createsun.com) 的大作中提到: 】
: 现在都强调team work，3个人，如果是一个管另外两个，我倒觉得不如三个人
: 是一个团队来的更好。当然，前提是成员都是高素质的。
这样的前提太理想化了，一般软件公司能招到多少这样的人？
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
lazydog 于 Mon Jul 26 12:14:44 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
是AutoDesk，你个土鳖，这么牛×的公司都记不住
【 在 LazyCoder (未婚好男人) 的大作中提到: 】
: 那天yy跟我说过的，我忘了:(上海某公司
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
ArtWalker 于 Mon Jul 26 12:29:46 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
寒
狂admire
【 在 lazydog (流浪的懒狗) 的大作中提到: 】
: 是AutoDesk，你个土鳖，这么牛×的公司都记不住
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Mon Jul 26 12:39:04 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
这个公司是干吗的？我不知道
【 在 lazydog (流浪的懒狗) 的大作中提到: 】
: 是AutoDesk，你个土鳖，这么牛×的公司都记不住
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
westmoon 于 Mon Jul 26 15:22:04 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
做autocad的那个。。。
【 在 LazyCoder (未婚好男人) 的大作中提到: 】
: 这个公司是干吗的？我不知道
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Mon Jul 26 18:35:05 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
为公司宣传一下：）
autodesk是世界领先的数字化设计软件和数字内容供应商，
她和ms是世界上仅有的两家生存了20年以上的软件公司，
公司产品很多，最出名的恐怕就是autocad和3dmax了，
现在上海这里也是做产品的
【 在 LazyCoder (未婚好男人) 的大作中提到: 】
: 这个公司是干吗的？我不知道
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Mon Jul 26 18:51:52 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
^_^,好像什么公司都说世界领先的
joke
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 为公司宣传一下：）
: autodesk是世界领先的数字化设计软件和数字内容供应商，
: 她和ms是世界上仅有的两家生存了20年以上的软件公司，
: 公司产品很多，最出名的恐怕就是autocad和3dmax了，
: 现在上海这里也是做产品的
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
huangxuhao 于 Mon Jul 26 18:52:14 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
不错不错，不过AutoDesk ms对大陆有技术封锁 啊
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 为公司宣传一下：）
: autodesk是世界领先的数字化设计软件和数字内容供应商，
: 她和ms是世界上仅有的两家生存了20年以上的软件公司，
: 公司产品很多，最出名的恐怕就是autocad和3dmax了，
: 现在上海这里也是做产品的
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
mwong 于 Mon Jul 26 18:54:13 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
你们公司今年业绩很不错啊：）
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 为公司宣传一下：）
: autodesk是世界领先的数字化设计软件和数字内容供应商，
: 她和ms是世界上仅有的两家生存了20年以上的软件公司，
: 公司产品很多，最出名的恐怕就是autocad和3dmax了，
: 现在上海这里也是做产品的
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
huangxuhao 于 Mon Jul 26 18:53:52 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
宣传嘛，我们公司喜欢用"亚太区最大的"...
【 在 hijack (孤读一身) 的大作中提到: 】
: ^_^,好像什么公司都说世界领先的
: joke
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
lazydog 于 Mon Jul 26 19:07:52 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
牛dd，以后招我进去打杂
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 为公司宣传一下：）
: autodesk是世界领先的数字化设计软件和数字内容供应商，
: 她和ms是世界上仅有的两家生存了20年以上的软件公司，
: 公司产品很多，最出名的恐怕就是autocad和3dmax了，
: 现在上海这里也是做产品的
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Mon Jul 26 19:49:50 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
晕，我admire你都不知道到什么程度了
【 在 ArtWalker (直觉艺术家.Evolution) 的大作中提到: 】
: 寒
: 狂admire
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Mon Jul 26 19:52:14 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
恩，有一定share的都爽死了
【 在 mwong (罐头米糕の在人间) 的大作中提到: 】
: 你们公司今年业绩很不错啊：）
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Mon Jul 26 19:58:42 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
我是要被赶出去的那种：（【 在 lazydog (流浪的懒狗) 的大作中提到: 】
: 牛dd，以后招我进去打杂
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
adoal 于 Mon Jul 26 20:10:41 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
几乎所有人都把3ds max叫成3d max……:p
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 为公司宣传一下：）
: autodesk是世界领先的数字化设计软件和数字内容供应商，
: 她和ms是世界上仅有的两家生存了20年以上的软件公司，
: 公司产品很多，最出名的恐怕就是autocad和3dmax了，
: 现在上海这里也是做产品的
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
mwong 于 Mon Jul 26 20:23:17 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
你做产品开发吗？
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 恩，有一定share的都爽死了
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Mon Jul 26 20:34:16 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
上面说了,作产品
【 在 mwong (罐头米糕の在人间) 的大作中提到: 】
: 你做产品开发吗？
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
mwong 于 Mon Jul 26 20:37:23 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
知道阿，产品team里也有不同role的嘛
【 在 hijack (孤读一身) 的大作中提到: 】
: 上面说了,作产品
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
ArtWalker 于 Mon Jul 26 21:11:28 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
还好偶是玩3DS 4.0长大的
【 在 adoal (Isn't CMB crazy?) 的大作中提到: 】
: 几乎所有人都把3ds max叫成3d max……:p
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Tue Jul 27 09:06:05 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
所以我很崇拜尼～
【 在 ArtWalker (直觉艺术家.Evolution) 的大作中提到: 】
: 还好偶是玩3DS 4.0长大的
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
marong 于 Tue Jul 27 10:17:35 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
谁说的？？
ESRI快生存了30年了。1975年开始做GIS软件。
世界头号地理信息系统提供商
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 为公司宣传一下：）
: autodesk是世界领先的数字化设计软件和数字内容供应商，
: 她和ms是世界上仅有的两家生存了20年以上的软件公司，
: 公司产品很多，最出名的恐怕就是autocad和3dmax了，
: 现在上海这里也是做产品的
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
lionheart 于 Tue Jul 27 11:45:27 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
1) 轮换制编程：一个人不能连续编程超过三天
2) 每天REVIEW：第二次发现同样错就扣钱给PM
3) 每两天开会：校验进度、发现异常点
4) 每三天BUILD
5) SHADOW团队：保持对现职团队的压力
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 最近，在开发过程中，软件质量的问题似乎变得越来越严重。
: 最直接的表现就是提交给用户的产品，即使是试用，bug一大堆。
: 回过头来看的话，其实从最初的需求分析、系统设计……，
: 一直最后的编码、测试，虽然是按部就班来的，但感觉都是流于形式。
: 当然，这必然会导致最终软件质量的下降，甚至是低劣。
: 软件工程的道理大家都明白，但项目一个紧跟着一个，
: 直接的后果就是开发周期被急剧压缩，所有的程序员、测试员都在赶工。
: 所以，我知道，真正要想解决软件质量的问题，必须从这方面着手。
: 但是，这也仅限于理论层面上，实际中，当一个利润相对丰厚的项目摆在面前时，
: >> .................<以下省略>............
[首页, 上一页, 下一页; 目录 ]
4.3 比较想说的一些话
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Tue Jul 27 21:14:52 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
我是个程序员,很普通,走到大街上肯定谁都不认识的那种.
或许和大家一样,我也很喜欢技术,喜欢挑战,甚至"变态"的喜欢难题.
下面是我近来的一些感想,不全对.
我先说说我所理解的程序员的道路吧:
技术追求 --> 问题域分析 --> 问题域建模 --> 创造自己的技术
承然,我想我和大家都在走技术追求这一点,
我不否认,这是必经历的, 因为这是以后的资本积累.
但是我想说的是:不要盲目的技术积累.当你觉得技术积累到一定程度, 比如当你能够
承担一个开发小组的主力时,我想大家应该考虑进入一个问题域.思考一下,你的
技术能够解决那些问题域的难题,这些问题域的市场前景如何,你对这些问题域
感兴趣么.
考虑这些问题的价值并不亚于你苦苦的追求一种技术
我现在的感觉,比起技术,我更加喜欢方法论,就是"技术追求"后面的那几个阶段
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
mwong 于 Tue Jul 27 21:34:43 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
问题域的两个阶段如何帮助到创造自己的技术这一步的？
创造技术需要在问题域有多少程度的投入？
靠这些投入就足够了吗？
【 在 hijack (孤读一身) 的大作中提到: 】
: 我是个程序员,很普通,走到大街上肯定谁都不认识的那种.
: 或许和大家一样,我也很喜欢技术,喜欢挑战,甚至"变态"的喜欢难题.
: 下面是我近来的一些感想,不全对.
: 我先说说我所理解的程序员的道路吧:
: 技术追求 --> 问题域分析 --> 问题域建模 --> 创造自己的技术
: 承然,我想我和大家都在走技术追求这一点,
: 我不否认,这是必经历的, 因为这是以后的资本积累.
: 但是我想说的是:不要盲目的技术积累.当你觉得技术积累到一定程度, 比如当你能够
: 承担一个开发小组的主力时,我想大家应该考虑进入一个问题域.思考一下,你的
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Tue Jul 27 21:37:43 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
我没有完完全全的走,但好像在迭代
问题域可以说是无穷尽的吧,看看现在的JSR,它已经不仅仅涉及技术,
甚至它在问题域建模. 只要你精通一个问题域,你肯定会发现现在模型的
缺陷,那时候用既有的技术来写自己的东西也不是难事
好比jini,javaspace其实他们都不是新技术,仅仅是为解决问题的特化技术而已
【 在 mwong (罐头米糕の在人间) 的大作中提到: 】
: 问题域的两个阶段如何帮助到创造自己的技术这一步的？
: 创造技术需要在问题域有多少程度的投入？
: 靠这些投入就足够了吗？
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Tue Jul 27 21:42:56 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
jakarta的很多项目都是问题域专家捐赠的代码
【 在 hijack (孤读一身) 的大作中提到: 】
: 我没有完完全全的走,但好像在迭代
: 问题域可以说是无穷尽的吧,看看现在的JSR,它已经不仅仅涉及技术,
: 甚至它在问题域建模. 只要你精通一个问题域,你肯定会发现现在模型的
: 缺陷,那时候用既有的技术来写自己的东西也不是难事
: 好比jini,javaspace其实他们都不是新技术,仅仅是为解决问题的特化技术而已
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
mwong 于 Tue Jul 27 21:44:16 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
你对“问题域”的定义是什么？
【 在 hijack (孤读一身) 的大作中提到: 】
: 我没有完完全全的走,但好像在迭代
: 问题域可以说是无穷尽的吧,看看现在的JSR,它已经不仅仅涉及技术,
: 甚至它在问题域建模. 只要你精通一个问题域,你肯定会发现现在模型的
: 缺陷,那时候用既有的技术来写自己的东西也不是难事
: 好比jini,javaspace其实他们都不是新技术,仅仅是为解决问题的特化技术而已
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Tue Jul 27 21:48:15 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
我不想去google一段问题域的定义
说说我自己的理解吧,不对给我指出来
1.问题域是有颗粒度的.
2.问题域有行业背景,就是所谓的专业知识壁垒
3.问题域应该有对应的解域
【 在 mwong (罐头米糕の在人间) 的大作中提到: 】
: 你对“问题域”的定义是什么？
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Tue Jul 27 21:55:39 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
等待时机成熟,我想88可以开设一个DomailModel板块
讨论不同问题域的软件建模
【 在 hijack (孤读一身) 的大作中提到: 】
: 我不想去google一段问题域的定义
: 说说我自己的理解吧,不对给我指出来
: 1.问题域是有颗粒度的.
: 2.问题域有行业背景,就是所谓的专业知识壁垒
: 3.问题域应该有对应的解域
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
mwong 于 Tue Jul 27 21:53:29 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
没有什么不对呵呵，
我只是想首先确定一下后面的讨论基于同一个对问题域的理解
回到前面的问题，我想知道的是问题域，尤其是第二点，是如何对技术创新起到帮助的
之所以问这个问题
今天有人问我，AOP在电信行业里怎么应用，我一下子懵了
因为我概念中的技术一般是跨问题域而存在的
【 在 hijack (孤读一身) 的大作中提到: 】
: 我不想去google一段问题域的定义
: 说说我自己的理解吧,不对给我指出来
: 1.问题域是有颗粒度的.
: 2.问题域有行业背景,就是所谓的专业知识壁垒
: 3.问题域应该有对应的解域
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Tue Jul 27 21:59:55 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
汗,上回刚刚和swear谈起他们的项目
不知道是不是他们的商业机密啊
他们打算建一个分布式的weave系统,呵呵,那样客户端的代码可以
减少很多
那个问题,我想已经回答了. 我想某技术所以能够保存活力
因为她解决了特定的问题
所以技术创新的灵感,来源于你对问题域太了解了
【 在 mwong (罐头米糕の在人间) 的大作中提到: 】
: 没有什么不对呵呵，
: 我只是想首先确定一下后面的讨论基于同一个对问题域的理解
: 回到前面的问题，我想知道的是问题域，尤其是第二点，是如何对技术创新起到帮助的
: 之所以问这个问题
: 今天有人问我，AOP在电信行业里怎么应用，我一下子懵了
: 因为我概念中的技术一般是跨问题域而存在的
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Tue Jul 27 22:06:16 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
经验不够:(
aspectwerkz的founder在bea才算是senior software engineer
汗,多牛的人啊
【 在 swear (达人甲) 的大作中提到: 】
: 来做research吧，haha
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
mwong 于 Tue Jul 27 22:07:16 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
汗。。。再说说你对“技术”的定义？
我理解的技术可不是解决了“特定”问题的，而是可以解决一堆问题
例如网格，可以用在教育上，医疗，金融……
例如J2EE，同样跟问题域是正交的
这个例子里更多的是一种solution？
【 在 hijack (孤读一身) 的大作中提到: 】
: 汗,上回刚刚和swear谈起他们的项目
: 不知道是不是他们的商业机密啊
: 他们打算建一个分布式的weave系统,呵呵,那样客户端的代码可以
: 减少很多
: 那个问题,我想已经回答了. 我想某技术所以能够保存活力
: 因为她解决了特定的问题
: 所以技术创新的灵感,来源于你对问题域太了解了
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Tue Jul 27 22:12:01 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
更正
特定 ---> 一类
我说的颗粒度肯定比你理解的要细
【 在 mwong (罐头米糕の在人间) 的大作中提到: 】
: 汗。。。再说说你对“技术”的定义？
: 我理解的技术可不是解决了“特定”问题的，而是可以解决一堆问题
: 例如网格，可以用在教育上，医疗，金融……
: 例如J2EE，同样跟问题域是正交的
: 这个例子里更多的是一种solution？
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
nimbus 于 Tue Jul 27 22:35:37 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
做技术咨询吧，以技术为基础，以行业知识为背景，两者结合
应该说职业的基础条件就比较完备了，至少比较有方向感。
【 在 hijack (孤读一身) 的大作中提到: 】
: 我是个程序员,很普通,走到大街上肯定谁都不认识的那种.
: 或许和大家一样,我也很喜欢技术,喜欢挑战,甚至"变态"的喜欢难题.
: 下面是我近来的一些感想,不全对.
: 我先说说我所理解的程序员的道路吧:
: 技术追求 --> 问题域分析 --> 问题域建模 --> 创造自己的技术
: 承然,我想我和大家都在走技术追求这一点,
: 我不否认,这是必经历的, 因为这是以后的资本积累.
: 但是我想说的是:不要盲目的技术积累.当你觉得技术积累到一定程度, 比如当你能够
: 承担一个开发小组的主力时,我想大家应该考虑进入一个问题域.思考一下,你的
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
Jackle 于 Wed Jul 28 00:01:13 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
我觉得为技术分领域好像不妥
不过系统的分析和建模以及一些
解决方案有领域性性或者
在几个相似的领域内可以互通
作consulting应该也就是因为
有某个领域的实施经验所以
能牛比吧
【 在 hijack (孤读一身) 的大作中提到: 】
: 我是个程序员,很普通,走到大街上肯定谁都不认识的那种.
: 或许和大家一样,我也很喜欢技术,喜欢挑战,甚至"变态"的喜欢难题.
: 下面是我近来的一些感想,不全对.
: 我先说说我所理解的程序员的道路吧:
: 技术追求 --> 问题域分析 --> 问题域建模 --> 创造自己的技术
: 承然,我想我和大家都在走技术追求这一点,
: 我不否认,这是必经历的, 因为这是以后的资本积累.
: 但是我想说的是:不要盲目的技术积累.当你觉得技术积累到一定程度, 比如当你能够
: 承担一个开发小组的主力时,我想大家应该考虑进入一个问题域.思考一下,你的
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Wed Jul 28 00:19:48 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
其实我要主要表达的意思是:
不要总是跟着别人的技术走,不要麻木掉
其实慢慢的,我们也可以来创造我们的技术
【 在 Jackle (睡睡~~WindForce) 的大作中提到: 】
: 我觉得为技术分领域好像不妥
: 不过系统的分析和建模以及一些
: 解决方案有领域性性或者
: 在几个相似的领域内可以互通
: 作consulting应该也就是因为
: 有某个领域的实施经验所以
: 能牛比吧
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Wed Jul 28 00:23:12 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
也不是刻意去划分,或者刻意去追求
就像Oberg,不知不觉就成了CMS expert.
可能自己把握的吧
自己觉得感兴趣就进去
但这段时间有人很短,有人很长
【 在 hijack (孤读一身) 的大作中提到: 】
: 其实我要主要表达的意思是:
: 不要总是跟着别人的技术走,不要麻木掉
: 其实慢慢的,我们也可以来创造我们的技术
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Wed Jul 28 08:58:32 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
这个要看兴趣的，其实你说的只是程序员发展的一个方向而已，一个小小的方向
【 在 hijack (孤读一身) 的大作中提到: 】
: 我是个程序员,很普通,走到大街上肯定谁都不认识的那种.
: 或许和大家一样,我也很喜欢技术,喜欢挑战,甚至"变态"的喜欢难题.
: 下面是我近来的一些感想,不全对.
: 我先说说我所理解的程序员的道路吧:
: 技术追求 --> 问题域分析 --> 问题域建模 --> 创造自己的技术
: 承然,我想我和大家都在走技术追求这一点,
: 我不否认,这是必经历的, 因为这是以后的资本积累.
: 但是我想说的是:不要盲目的技术积累.当你觉得技术积累到一定程度, 比如当你能够
: 承担一个开发小组的主力时,我想大家应该考虑进入一个问题域.思考一下,你的
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
gzhzjk 于 Wed Jul 28 08:57:31 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
强烈的re啊，至少在java方面，感觉中国拿得出手的东西好像不多，
也许被项目耗着的程序员太多了吧，也许是技术的进步太快，让我们跟着都很费力了
【 在 hijack (孤读一身) 的大作中提到: 】
: 其实我要主要表达的意思是:
: 不要总是跟着别人的技术走,不要麻木掉
: 其实慢慢的,我们也可以来创造我们的技术
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Wed Jul 28 09:05:47 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
【 在 gzhzjk (chandler) 的大作中提到: 】
: 强烈的re啊，至少在java方面，感觉中国拿得出手的东西好像不多，
: 也许被项目耗着的程序员太多了吧，也许是技术的进步太快，让我们跟着都很费力了
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
是的,所以导致很多技术我们只知道怎么用,但是不知道为什么会有这个技术
人家花了10几年研究出来的技术,并不是看源代码就可以全部领会的.
因为我们抛弃了技术的context.
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Wed Jul 28 09:11:54 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
构思技术不是那么容易的，我觉得我不是那样的天才，
或许几十年后，我可以凭经验弥补我天资不不足
【 在 hijack (孤读一身) 的大作中提到: 】
: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: 是的,所以导致很多技术我们只知道怎么用,但是不知道为什么会有这个技术
: 人家花了10几年研究出来的技术,并不是看源代码就可以全部领会的.
: 因为我们抛弃了技术的context.
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Wed Jul 28 09:33:21 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
几十年后,你还会写程序?我不信
【 在 LazyCoder (未婚好男人) 的大作中提到: 】
: 构思技术不是那么容易的，我觉得我不是那样的天才，
: 或许几十年后，我可以凭经验弥补我天资不不足
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Wed Jul 28 09:43:54 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
我想，但估计不会，哈哈
【 在 hijack (孤读一身) 的大作中提到: 】
: 几十年后,你还会写程序?我不信
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
mifeng 于 Wed Jul 28 10:00:16 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
感觉java方面中国应该可以出一些东西啊
可能真的是程序员没有时间和精力去做自己喜欢的那些东西。
大家都在为一些商业的软件，项目忙个不停。
【 在 gzhzjk (chandler) 的大作中提到: 】
: 强烈的re啊，至少在java方面，感觉中国拿得出手的东西好像不多，
: 也许被项目耗着的程序员太多了吧，也许是技术的进步太快，让我们跟着都很费力了
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
FishInSky 于 Wed Jul 28 10:03:40 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
中国程序员的生活像民工，太多民工型的程序员，太多人把程序员当民工
【 在 mifeng (是。非。黑。白。) 的大作中提到: 】
: 感觉java方面中国应该可以出一些东西啊
: 可能真的是程序员没有时间和精力去做自己喜欢的那些东西。
: 大家都在为一些商业的软件，项目忙个不停。
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Wed Jul 28 10:06:50 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
早上有翻了翻人月神话，非常向往外科手术队伍～
程序员可以从非创造性的事务中解放出来
【 在 FishInSky (鱼鱼也飞翔&蝴蝶效应的受害者) 的大作中提到: 】
: 中国程序员的生活像民工，太多民工型的程序员，太多人把程序员当民工
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
xuchuan 于 Wed Jul 28 10:18:32 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
怎么可能，民工活实在太多了，程序员不做叫谁去做？难道真的雇佣民工来做？
【 在 LazyCoder (未婚好男人) 的大作中提到: 】
: 早上有翻了翻人月神话，非常向往外科手术队伍～
: 程序员可以从非创造性的事务中解放出来
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Wed Jul 28 10:19:08 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
而关键是自己也把自己看作了民工
【 在 FishInSky (鱼鱼也飞翔&蝴蝶效应的受害者) 的大作中提到: 】
: 中国程序员的生活像民工，太多民工型的程序员，太多人把程序员当民工
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Wed Jul 28 10:20:07 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
看什么活了，你觉得让一个架构师或首席程序员在思考怎么写程序的同时
还要写好那些程序的文档，处理好一些规范话的东西，能受得了吗？
至于技术含量低的活，当然是训练一批专业的人来做，而不是程序员
【 在 xuchuan (xuchuan) 的大作中提到: 】
: 怎么可能，民工活实在太多了，程序员不做叫谁去做？难道真的雇佣民工来做？
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
xuchuan 于 Wed Jul 28 10:23:49 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
什么是程序员？
【 在 LazyCoder (未婚好男人) 的大作中提到: 】
: 看什么活了，你觉得让一个架构师或首席程序员在思考怎么写程序的同时
: 还要写好那些程序的文档，处理好一些规范话的东西，能受得了吗？
: 至于技术含量低的活，当然是训练一批专业的人来做，而不是程序员
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Wed Jul 28 10:22:44 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
一个好的文档是一个好的opensource存活的关键
也是出论文的好地方,呵呵
这是必须的.不过我很少看到国外有架构师的称呼,senior software engineer
上面就是scientist?
什么叫技术含量低的活?比如...
【 在 LazyCoder (未婚好男人) 的大作中提到: 】
: 看什么活了，你觉得让一个架构师或首席程序员在思考怎么写程序的同时
: 还要写好那些程序的文档，处理好一些规范话的东西，能受得了吗？
: 至于技术含量低的活，当然是训练一批专业的人来做，而不是程序员
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Wed Jul 28 10:35:46 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
好的文档，由架构师口述或草稿，专业的文档书写者整理，规范，这样更好，不是吗？
【 在 hijack (孤读一身) 的大作中提到: 】
: 一个好的文档是一个好的opensource存活的关键
: 也是出论文的好地方,呵呵
: 这是必须的.不过我很少看到国外有架构师的称呼,senior software engineer
: 上面就是scientist?
: 什么叫技术含量低的活?比如...
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Wed Jul 28 10:37:06 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
在软件开发上，必须强调专业分工，不能让好的程序员干所有的事，应该物尽其用
【 在 LazyCoder (未婚好男人) 的大作中提到: 】
: 好的文档，由架构师口述或草稿，专业的文档书写者整理，规范，这样更好，不是吗？
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
devis 于 Wed Jul 28 12:11:03 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
牛人是学生还是工作了，我觉的你超越一般的水平
【 在 hijack (孤读一身) 的大作中提到: 】
: 我是个程序员,很普通,走到大街上肯定谁都不认识的那种.
: 或许和大家一样,我也很喜欢技术,喜欢挑战,甚至"变态"的喜欢难题.
: 下面是我近来的一些感想,不全对.
: 我先说说我所理解的程序员的道路吧:
: 技术追求 --> 问题域分析 --> 问题域建模 --> 创造自己的技术
: 承然,我想我和大家都在走技术追求这一点,
: 我不否认,这是必经历的, 因为这是以后的资本积累.
: 但是我想说的是:不要盲目的技术积累.当你觉得技术积累到一定程度, 比如当你能够
: 承担一个开发小组的主力时,我想大家应该考虑进入一个问题域.思考一下,你的
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
apple 于 Wed Jul 28 17:11:12 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
good，那和我一样了
写设计文档，拿下去给coder做，他们做好了我检查
【 在 mifeng (是。非。黑。白。) 的大作中提到: 】
: 我？现在就是写文档，检查，测试等等，反正就是周边的事情。
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
tomsgang 于 Wed Jul 28 17:13:51 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
强的，我们都是老板和我们谈想法，然后我们做，我们写文档
【 在 apple (疲惫的大苹果※为什么会是这样..) 的大作中提到: 】
: good，那和我一样了
: 写设计文档，拿下去给coder做，他们做好了我检查
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
noden 于 Thu Jul 29 10:54:10 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
re。
不过，感觉到了问题建模这个阶段，技术倒不是太重要了，尤其是粒度较大的问题域。
这时候考虑的是整个模型的架构，整个模型的运行机制，这时候和技术、甚至计算机本
身都没有什么关联了。
至于自己创造的技术，我觉得倒可以称为自己创造的模型或者解决方案比较好。
当然，如果自己创造出一种语言，那倒是的，^_^。
【 在 hijack (孤读一身) 的大作中提到: 】
: 我是个程序员,很普通,走到大街上肯定谁都不认识的那种.
: 或许和大家一样,我也很喜欢技术,喜欢挑战,甚至"变态"的喜欢难题.
: 下面是我近来的一些感想,不全对.
: 我先说说我所理解的程序员的道路吧:
: 技术追求 --> 问题域分析 --> 问题域建模 --> 创造自己的技术
: 承然,我想我和大家都在走技术追求这一点,
: 我不否认,这是必经历的, 因为这是以后的资本积累.
: 但是我想说的是:不要盲目的技术积累.当你觉得技术积累到一定程度, 比如当你能够
: 承担一个开发小组的主力时,我想大家应该考虑进入一个问题域.思考一下,你的
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
bird 于 Sun Jul 25 14:23:56 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
最近，在开发过程中，软件质量的问题似乎变得越来越严重。
最直接的表现就是提交给用户的产品，即使是试用，bug一大堆。
回过头来看的话，其实从最初的需求分析、系统设计……，
一直最后的编码、测试，虽然是按部就班来的，但感觉都是流于形式。
当然，这必然会导致最终软件质量的下降，甚至是低劣。
软件工程的道理大家都明白，但项目一个紧跟着一个，
直接的后果就是开发周期被急剧压缩，所有的程序员、测试员都在赶工。
所以，我知道，真正要想解决软件质量的问题，必须从这方面着手。
但是，这也仅限于理论层面上，实际中，当一个利润相对丰厚的项目摆在面前时，
我们凭什么去和老板讲，“为了保证质量，我们需要放弃这个项目”？
市场在这里，这次错过了，下次就不一定有机会了。
所以说，感觉这是一个很突出的矛盾，而程序员对此似乎无能为力。
那么，在这种前提下，想和大家讨论一下如何尽可能地保证软件质量的问题。
你可能会说，一个高质量的软件需要高质量的分析、设计、编码、测试……
等等，还是那句话，这些道理我们都很明白。我想在一些的前提下讨论这个问题。
假设我们的需求分析做得已经足够好了，与客户的沟通不成问题，
那么，怎么样保证开发出来的软件产品确实满足需求，不会出现让用户抓狂的bug？
先谈一点个人的看法，在需求确定之后，我们假设后面不会再有所变动。
然后是整个系统的设计，我们也假设这个设计是可行的并且合理的。
接下来，应该是系统的实现，我把各个功能模块的设计归在这个过程中完成，
具体的细节完全由程序员自由发挥。当然，编码也在这个阶段完成。
最后是系统测试，其中包括各种类型、规模的测试，
可以说，测试是软件产品交付使用之前最重要的环节。
如果测试做得好，从理论上说测出了各种各样潜在问题的话，
那么我们可以很自信地说，我们的软件产品是高质量的。
但这都是不现实的，而且做为程序开发人员来说，我不想*过多*地依赖测试员。
还是希望能够尽量在前面我提到的完全由程序员参与的系统实现的过程中
扼杀一些潜在的可能导致软件质量下降的因素。
因此想听听大家的高见，在开发人员是一个由三五个人组成的group的情况下，
究竟怎么样才能够在纯粹的开发过程中尽可能地生产出高质量的软件？
欢迎讨论！
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
lostar 于 Sun Jul 25 15:50:13 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
提高价格，是提高质量的途径之一
如果一个项目两三个人，优秀的程序员所起到的作用不比软件工程低。
这时候，人是决定软件质量的一个重要因素。
钱多，用高质量开发人员，是一个不错的途径。
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 最近，在开发过程中，软件质量的问题似乎变得越来越严重。
: 最直接的表现就是提交给用户的产品，即使是试用，bug一大堆。
: 回过头来看的话，其实从最初的需求分析、系统设计……，
: 一直最后的编码、测试，虽然是按部就班来的，但感觉都是流于形式。
: 当然，这必然会导致最终软件质量的下降，甚至是低劣。
: 软件工程的道理大家都明白，但项目一个紧跟着一个，
: 直接的后果就是开发周期被急剧压缩，所有的程序员、测试员都在赶工。
: 所以，我知道，真正要想解决软件质量的问题，必须从这方面着手。
: 但是，这也仅限于理论层面上，实际中，当一个利润相对丰厚的项目摆在面前时，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
westmoon 于 Sun Jul 25 16:03:07 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
测试的人员和时间是必须的
毕竟总有考虑不到的地方
理想与现实啊~~
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 最近，在开发过程中，软件质量的问题似乎变得越来越严重。
: 最直接的表现就是提交给用户的产品，即使是试用，bug一大堆。
: 回过头来看的话，其实从最初的需求分析、系统设计……，
: 一直最后的编码、测试，虽然是按部就班来的，但感觉都是流于形式。
: 当然，这必然会导致最终软件质量的下降，甚至是低劣。
: 软件工程的道理大家都明白，但项目一个紧跟着一个，
: 直接的后果就是开发周期被急剧压缩，所有的程序员、测试员都在赶工。
: 所以，我知道，真正要想解决软件质量的问题，必须从这方面着手。
: 但是，这也仅限于理论层面上，实际中，当一个利润相对丰厚的项目摆在面前时，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
bird 于 Sun Jul 25 17:50:12 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
单纯对于开发来说，优秀的程序员肯定是必须的。
因此，可以说提高程序员水平是一方面。
那么，从管理上，或者从整个过程上来说，
有没有一些可行的控制手段来尽量保证质量呢？
【 在 lostar (lostar@createsun.com) 的大作中提到: 】
: 提高价格，是提高质量的途径之一
: 如果一个项目两三个人，优秀的程序员所起到的作用不比软件工程低。
: 这时候，人是决定软件质量的一个重要因素。
: 钱多，用高质量开发人员，是一个不错的途径。
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
bird 于 Sun Jul 25 17:51:42 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
是的，测试肯定是不能少的。其中考虑不到确实是一方面，
在这方面，测试员与程序员考虑问题的角度不同，
他们确实会提供一些很有建设性的意见和建议。
现在我的意思是，不考虑想法方面的问题，纯粹技术上的开发，
如何才能保证质量。
举个naive的例子，一个while循环，如果在条件后面多加了一个分号，
我想即使再有经验的程序员在编码的过程中也不敢保证一定不会出这样的错误，
但是如果在这段代码提交后，由另外一个程序员来check这段代码，
甚至单步跟踪调试，这种问题遗留的概率就很小了。
当然，这个例子属于极端初级的错误，一般程序员自己细心debug就会发现了。
只是想通过这个说明一点，我们是不是可以从一些管理的角度考虑提高质量。
毕竟，每个程序员的水平有限，不能指望所有的人一夜之间都变得优秀。
【 在 westmoon (Java Step by Step) 的大作中提到: 】
: 测试的人员和时间是必须的
: 毕竟总有考虑不到的地方
: 理想与现实啊~~
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 18:03:48 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
unit test + nightly build
测试结果第二天就在memeber的邮箱里了
Opensource都这么做的
我们也在努力做auto nighly build
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 是的，测试肯定是不能少的。其中考虑不到确实是一方面，
: 在这方面，测试员与程序员考虑问题的角度不同，
: 他们确实会提供一些很有建设性的意见和建议。
: 现在我的意思是，不考虑想法方面的问题，纯粹技术上的开发，
: 如何才能保证质量。
: 举个naive的例子，一个while循环，如果在条件后面多加了一个分号，
: 我想即使再有经验的程序员在编码的过程中也不敢保证一定不会出这样的错误，
: 但是如果在这段代码提交后，由另外一个程序员来check这段代码，
: 甚至单步跟踪调试，这种问题遗留的概率就很小了。
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
westmoon 于 Sun Jul 25 18:36:58 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
类似这种细节的问题xp结队应该能够解决
但是大局上的系统级测试就很难找到相应的办法
大概只有靠需求和分析设计阶段的细致工作了
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 是的，测试肯定是不能少的。其中考虑不到确实是一方面，
: 在这方面，测试员与程序员考虑问题的角度不同，
: 他们确实会提供一些很有建设性的意见和建议。
: 现在我的意思是，不考虑想法方面的问题，纯粹技术上的开发，
: 如何才能保证质量。
: 举个naive的例子，一个while循环，如果在条件后面多加了一个分号，
: 我想即使再有经验的程序员在编码的过程中也不敢保证一定不会出这样的错误，
: 但是如果在这段代码提交后，由另外一个程序员来check这段代码，
: 甚至单步跟踪调试，这种问题遗留的概率就很小了。
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 18:41:30 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
让我想起阿豆的那篇文章,哈哈
说说你的xp结对实践,我们看到一些缺点
【 在 westmoon (Java Step by Step) 的大作中提到: 】
: 类似这种细节的问题xp结队应该能够解决
: 但是大局上的系统级测试就很难找到相应的办法
: 大概只有靠需求和分析设计阶段的细致工作了
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
Jackle 于 Sun Jul 25 18:54:36 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
说说看啊。
缺点
【 在 hijack (孤读一身) 的大作中提到: 】
: 让我想起阿豆的那篇文章,哈哈
: 说说你的xp结对实践,我们看到一些缺点
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
Jackle 于 Sun Jul 25 19:00:43 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
我对这个比较感兴趣，能提供一些资料或者经验吗？
ps:你们有没有让用户参到整个项目中来的啊？
在XP中用户的参与很重要啊。
【 在 hijack (孤读一身) 的大作中提到: 】
: unit test + nightly build
: 测试结果第二天就在memeber的邮箱里了
: Opensource都这么做的
: 我们也在努力做auto nighly build
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
adoal 于 Sun Jul 25 19:06:48 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
你这个例子确实不好，因为它用lint这种机械化的办法就可以解决，:p
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 是的，测试肯定是不能少的。其中考虑不到确实是一方面，
: 在这方面，测试员与程序员考虑问题的角度不同，
: 他们确实会提供一些很有建设性的意见和建议。
: 现在我的意思是，不考虑想法方面的问题，纯粹技术上的开发，
: 如何才能保证质量。
: 举个naive的例子，一个while循环，如果在条件后面多加了一个分号，
: 我想即使再有经验的程序员在编码的过程中也不敢保证一定不会出这样的错误，
: 但是如果在这段代码提交后，由另外一个程序员来check这段代码，
: 甚至单步跟踪调试，这种问题遗留的概率就很小了。
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
westmoon 于 Sun Jul 25 19:09:59 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
牟实践，看了一些网上资料的结果
纸上谈兵而已-_-bb
【 在 hijack (孤读一身) 的大作中提到: 】
: 让我想起阿豆的那篇文章,哈哈
: 说说你的xp结对实践,我们看到一些缺点
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
lostar 于 Sun Jul 25 19:24:23 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
高质量的开发人员用上合适的工具，可以事半功倍 ：）
【 在 adoal (Isn't CMB crazy?) 的大作中提到: 】
: 你这个例子确实不好，因为它用lint这种机械化的办法就可以解决，:p
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
lostar 于 Sun Jul 25 19:25:25 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
对过程的关注可以减少一点，因为这方面我想现在你们做得已经差不多了。
管理并不是制定制度让别人去遵守，管理更重要的还是具体问题具体分析，
在计划、组织、控制、评估几个方面都需要花心思去考虑。
有时候一个员工评价指标的改变能导致意想不到的结果，有时候一个完善的
切实的计划能够保证项目风险的大大降低。
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 单纯对于开发来说，优秀的程序员肯定是必须的。
: 因此，可以说提高程序员水平是一方面。
: 那么，从管理上，或者从整个过程上来说，
: 有没有一些可行的控制手段来尽量保证质量呢？
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 19:28:16 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
去订阅一个开源项目developer的maillist或者参与开发
你就会亲身感受了
PS:我们的用户没有理想中的那样主动
不过我们还是使用了use story的跟踪系统
【 在 Jackle (睡睡~~WindForce) 的大作中提到: 】
: 我对这个比较感兴趣，能提供一些资料或者经验吗？
: ps:你们有没有让用户参到整个项目中来的啊？
: 在XP中用户的参与很重要啊。
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 19:23:12 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
公司的项目在技术上一般都会有一定的延续，
比如就开发语言可能一直是用c＋＋或者是java等等（还包括其他方面)
就某一技术领域内，
很多导致软件质量低下的情况往往雷同，
也就是低水平的设计和代码都会有一些常见的问题，
或者说经验不足者通常会范一些常见的错误，
从另外一个方面来说，
高水平低bug的设计和代码都会有一些共同之处，
（比如一些模式的应用就来源于这样的想法）
所以，在技术上，应该逐渐通过一些措施的引导，
建立起一些设计和code的标准，
鼓励使用优秀的习惯，杜绝不良的设计和编码风格，
从而避免一些容易导致软件质量低下的问题，
在我们公司，任何一个正式的软件流程都会有比较正式的
review，尽可能保证该过程成果的高质量，
设计的review当然是重中之中，
就代码而言，也会有比较正式的review，
查看代码的常见问题和风格，以及逻辑上的一些问题，
是否存在比较大的问题等等，
当然这些都需要比较大的精力投入，
我现在感觉老外做软件各方面投入真的是非常大，
如果是同样大的项目，
叫中国的公司来做可能一般的老板肯投个1/3都差不多了（个人感觉：）
也难怪他们的质量比较高（当然换了中国的公司就算给同样的
投入做出的软件质量也达不到那个水平，有了这么多投入说不定还
不知道怎么用呢：）
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 单纯对于开发来说，优秀的程序员肯定是必须的。
: 因此，可以说提高程序员水平是一方面。
: 那么，从管理上，或者从整个过程上来说，
: 有没有一些可行的控制手段来尽量保证质量呢？
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 19:48:09 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
建立起一些设计和code的标准，
鼓励使用优秀的习惯，杜绝不良的设计和编码风格，
?@.@?
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 公司的项目在技术上一般都会有一定的延续，
: 比如就开发语言可能一直是用c＋＋或者是java等等（还包括其他方面)
: 就某一技术领域内，
: 很多导致软件质量低下的情况往往雷同，
: 也就是低水平的设计和代码都会有一些常见的问题，
: 或者说经验不足者通常会范一些常见的错误，
: 从另外一个方面来说，
: 高水平低bug的设计和代码都会有一些共同之处，
: （比如一些模式的应用就来源于这样的想法）
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 19:49:31 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
说漏了？（大侠指点一下）
标准不可能细到所有的程度的吧？
（现实没这么理想的吧，我觉得）
标准一般说来还是比较high-level层次，
对于具体的情况，肯定还是有一些事情要具体问题具体分析，
这些时候就要靠经验丰富者指点的优良风格和优良习惯了，
通常是,技术老大看到下面的人写的代码和设计，
然后说，这样的设计可能会出现如何如何的问题，
应该如何如何设计和写如何如何的代码，
然后把原因解释一通，
说的一般都很圆，有的时候觉得蛮有道理的，
有的时候又不知道真正的情况，对于这个具体的问题，
是否真的如其所言呢：）
【 在 hijack (孤读一身) 的大作中提到: 】
: 建立起一些设计和code的标准，
: 鼓励使用优秀的习惯，杜绝不良的设计和编码风格，
: ?@.@?
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 19:55:04 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
而且，建立标准真的是一个漫长的过程，
不容易做到，不容易做好，
我个人觉得开始也就是避免那些常见错误，在那些典型情况下
应该如何做，
我看到的review主要还是依靠人，依靠他们在开发过程中
积累的经验
要真的做的比较好，可能需要在一个技术领域内有比较长的
开发历史吧，
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 说漏了？（大侠指点一下）
: 标准不可能细到所有的程度的吧？
: （现实没这么理想的吧，我觉得）
: 标准一般说来还是比较high-level层次，
: 对于具体的情况，肯定还是有一些事情要具体问题具体分析，
: 这些时候就要靠经验丰富者指点的优良风格和优良习惯了，
: 通常是,技术老大看到下面的人写的代码和设计，
: 然后说，这样的设计可能会出现如何如何的问题，
: 应该如何如何设计和写如何如何的代码，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 19:57:58 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
一个公司有7年编程经验的程序员(现在还在写程序)到底有多少阿?
5年的有多少?
3年的有多少?
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 说漏了？（大侠指点一下）
: 标准不可能细到所有的程度的吧？
: （现实没这么理想的吧，我觉得）
: 标准一般说来还是比较high-level层次，
: 对于具体的情况，肯定还是有一些事情要具体问题具体分析，
: 这些时候就要靠经验丰富者指点的优良风格和优良习惯了，
: 通常是,技术老大看到下面的人写的代码和设计，
: 然后说，这样的设计可能会出现如何如何的问题，
: 应该如何如何设计和写如何如何的代码，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
bird 于 Sun Jul 25 20:04:37 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
哪里可以找到这些相关的工具？以前真没怎么用过，打算试试看。
【 在 lostar (lostar@createsun.com) 的大作中提到: 】
: 高质量的开发人员用上合适的工具，可以事半功倍 ：）
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
bird 于 Sun Jul 25 20:05:20 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
所以也正在考虑使用一些机械化的办法，来专门处理类似的问题，
或者不能叫处理，防患于未然吧。
能否推荐几个比较好的工具？
【 在 adoal (Isn't CMB crazy?) 的大作中提到: 】
: 你这个例子确实不好，因为它用lint这种机械化的办法就可以解决，:p
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
bird 于 Sun Jul 25 20:08:32 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
听起来很好，可实际上一般同时会处理n个项目，似乎可行性值得商榷。
【 在 hijack (孤读一身) 的大作中提到: 】
: unit test + nightly build
: 测试结果第二天就在memeber的邮箱里了
: Opensource都这么做的
: 我们也在努力做auto nighly build
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
bird 于 Sun Jul 25 20:10:12 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
非常同意你的观点。
1. 投入少，少到没法说了，呵呵。
2. 必须要进行各种形式详尽的review，实际上我们做得很不够。
3. 编码规范，有是有的，效果不是特别好，总不成强制勒令每个人都这样，
在这点上，可能要讲究一点人员管理的策略了。似乎大家都不够积极。
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 公司的项目在技术上一般都会有一定的延续，
: 比如就开发语言可能一直是用c＋＋或者是java等等（还包括其他方面)
: 就某一技术领域内，
: 很多导致软件质量低下的情况往往雷同，
: 也就是低水平的设计和代码都会有一些常见的问题，
: 或者说经验不足者通常会范一些常见的错误，
: 从另外一个方面来说，
: 高水平低bug的设计和代码都会有一些共同之处，
: （比如一些模式的应用就来源于这样的想法）
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 20:02:34 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
我们这里的arch，听说要求是25年软件开发经验（当然都在国外）
算起来至少是79年前了，
刚来一个leader，中国人，好像到现在差不多也快20年了，
他说他95开始学java，在第一线又干了几年，当然现在不在第一线了，
有7年编程经验还写代码的还是有一些的，
有一些已经不写代码了，但是在review的时候
是主要人物，部门成立小组专门做标准（一方面是标准，
另外希望最终可以达到peer review）也要这样的人来领导
经验主要在这个时候体现作用，现在是不是还在写代码不重要，
ms你说的好像是开发人员的素质问题，
写代码的人可以没有太多的经验，
但是递交的代码专门有人review，还是可以在一定程度上保证质量的，
当然，招人的时候有严格的过程，也尽量保证进来写代码的人
写出来的代码质量比较高，回到前面说的开发人员素质问题了，
【 在 hijack (孤读一身) 的大作中提到: 】
: 一个公司有7年编程经验的程序员(现在还在写程序)到底有多少阿?
: 5年的有多少?
: 3年的有多少?
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
mwong 于 Sun Jul 25 20:17:02 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
JTest for java code
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 所以也正在考虑使用一些机械化的办法，来专门处理类似的问题，
: 或者不能叫处理，防患于未然吧。
: 能否推荐几个比较好的工具？
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 20:16:14 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
我说的恰恰事你要阐述的问题背后的因素
程序员经验到底有多少可以继承下来的?
你们部门你可以权衡一下
7年经验的占?%
5年?%
3年?%
还有,我理解不了你的表达, 你一方面说你们的质量 主要看review
一方面有说主要看程序员自己的素质
那主要看什么那?
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 我们这里的arch，听说要求是25年软件开发经验（当然都在国外）
: 算起来至少是79年前了，
: 刚来一个leader，中国人，好像到现在差不多也快20年了，
: 他说他95开始学java，在第一线又干了几年，当然现在不在第一线了，
: 有7年编程经验还写代码的还是有一些的，
: 有一些已经不写代码了，但是在review的时候
: 是主要人物，部门成立小组专门做标准（一方面是标准，
: 另外希望最终可以达到peer review）也要这样的人来领导
: 经验主要在这个时候体现作用，现在是不是还在写代码不重要，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
lostar 于 Sun Jul 25 20:18:40 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
这个就看开发者的经验了
对于工具，hijack比较熟的，可以咨询他。呵呵
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 哪里可以找到这些相关的工具？以前真没怎么用过，打算试试看。
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 20:19:40 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
没有监督,标准都是狗屁
不在第一线工作的人定的标准同样是狗屁文件
只是给ISO等一些用的
我们最有用永远是在team cvs里的代码规范
每个team都不一样的
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 我们这里的arch，听说要求是25年软件开发经验（当然都在国外）
: 算起来至少是79年前了，
: 刚来一个leader，中国人，好像到现在差不多也快20年了，
: 他说他95开始学java，在第一线又干了几年，当然现在不在第一线了，
: 有7年编程经验还写代码的还是有一些的，
: 有一些已经不写代码了，但是在review的时候
: 是主要人物，部门成立小组专门做标准（一方面是标准，
: 另外希望最终可以达到peer review）也要这样的人来领导
: 经验主要在这个时候体现作用，现在是不是还在写代码不重要，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 20:15:36 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
对于投入，我最近感受非常深刻，
觉得以前对于高质量软件开发所需要的工程量
的估计一直都过低的厉害，
有的时候ms急进也可以做出来，
尤其是土生土长的中国人，很喜欢这样（当然又聪明又能干也是一个方面：）
但是感觉这事实上是非常危险的做完
明显的特点是华为跳槽过来的员工，
经常干活特别的快，leader说这个礼拜我们先
做一些research的事情，然后大家讨论一下如何设计，
下周我们拿个方案出来，但是下个礼拜那哥们说，
我已经全部做完了，我们都晕倒。。
当然个人能力可能是一个方面，但是总的感觉是国外回来的人
通常喜欢按部就班一点，一步一步慢慢来，
另外就是他们不喜欢一次做太多的东西，怕风险太大，
万一失败了底线都完不成，
而且他们一般喜欢考虑万一这个
方案到时候实现的时候发现都太多的困难没想到，
有没有备用的非常保险的方案，华为过来那哥们常说的就是，
这个方案就不能失败，他这样有的时候是蛮好的，干活特别快，
但我总担心他那天会出问题
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 非常同意你的观点。
: 1. 投入少，少到没法说了，呵呵。
: 2. 必须要进行各种形式详尽的review，实际上我们做得很不够。
: 3. 编码规范，有是有的，效果不是特别好，总不成强制勒令每个人都这样，
: 在这点上，可能要讲究一点人员管理的策略了。似乎大家都不够积极。
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 20:25:12 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
说说你们review是怎样进行的吧
review的结果怎样传递?
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 而且，建立标准真的是一个漫长的过程，
: 不容易做到，不容易做好，
: 我个人觉得开始也就是避免那些常见错误，在那些典型情况下
: 应该如何做，
: 我看到的review主要还是依靠人，依靠他们在开发过程中
: 积累的经验
: 要真的做的比较好，可能需要在一个技术领域内有比较长的
: 开发历史吧，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
bird 于 Sun Jul 25 20:28:36 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
C++呢？
【 在 mwong (罐头米糕の在人间) 的大作中提到: 】
: JTest for java code
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 20:28:01 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
哈哈,你们的员工招聘后的适应期我不敢恭维了
拿华为的那个来说,我甚至觉得你们是失败的,
你们是个team,应该有自己的culture吧,
向我们曾经为自己的team设计了图标和slogan
可以看出华为在这点成功的,因为他们把程序员往他们的文化去塑造
你们用人太急了吧
还没有把它往你们的文化这边塑造,就敢用阿
所以开发节奏肯定会不一致
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 对于投入，我最近感受非常深刻，
: 觉得以前对于高质量软件开发所需要的工程量
: 的估计一直都过低的厉害，
: 有的时候ms急进也可以做出来，
: 尤其是土生土长的中国人，很喜欢这样（当然又聪明又能干也是一个方面：）
: 但是感觉这事实上是非常危险的做完
: 明显的特点是华为跳槽过来的员工，
: 经常干活特别的快，leader说这个礼拜我们先
: 做一些research的事情，然后大家讨论一下如何设计，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 20:27:06 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
我也是刚过来，这里差不多每天都有开会，
但是都讨论有内容的东西，
如果review一个人的工作，
会让他把他整个过程介绍给参加讨论的人，
（负责review的人就是那些经验很丰富的人）
然后大家开始讨论，基本上开完会每个人都知道他做的
设计成果的大体流程了，
（当然象我这样的人也就努力听听懂，基本没有什么建设性的意见
可以提）
那些老大级的人物有些时候会指出存在的问题，提出
修改意见，一些槽糕的设计会被否定，然后下面的人
回去继续修改，下次再拿出方案大家继续讨论，直到
老大觉得技术上ok了，没什么问题了，
设计基本就是这样，
代码的review我还没参加过，
但是ms这个在公司蛮重要的，
【 在 hijack (孤读一身) 的大作中提到: 】
: 说说你们review是怎样进行的吧
: review的结果怎样传递?
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
adoal 于 Sun Jul 25 20:35:37 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
【 在 hijack (孤读一身) 的大作中提到: 】
: 哈哈,你们的员工招聘后的适应期我不敢恭维了
: 拿华为的那个来说,我甚至觉得你们是失败的,
: 你们是个team,应该有自己的culture吧,
: 向我们曾经为自己的team设计了图标和slogan
: 可以看出华为在这点成功的,因为他们把程序员往他们的文化去塑造
这倒不一定式华为刻意塑造出来的。
华为毕竟不是软件公司，软件开发在华为这一派系的公司
（譬如从华为出来的人办的港湾）里的作用，和在专门的
软件公司里毕竟是不一样的。在港湾的程序员告诉我说，
他现在用到的最复杂的数据结构是线性数组……：）
: 你们用人太急了吧
: 还没有把它往你们的文化这边塑造,就敢用阿
: 所以开发节奏肯定会不一致
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 20:36:07 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
如果按你那样说,很耗时间的,
耗时间 == 耗开发人员的激情
我得感觉,你们的机构可能有点臃肿
我们曾经一段时间也做过code review
用cvs来做的,自己弄了个eclipse plugin
后来还是消失了, 因为我觉得运行相应的测试代码就OK了
需要修改的打个TODO的标签
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 我也是刚过来，这里差不多每天都有开会，
: 但是都讨论有内容的东西，
: 如果review一个人的工作，
: 会让他把他整个过程介绍给参加讨论的人，
: （负责review的人就是那些经验很丰富的人）
: 然后大家开始讨论，基本上开完会每个人都知道他做的
: 设计成果的大体流程了，
: （当然象我这样的人也就努力听听懂，基本没有什么建设性的意见
: 可以提）
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 20:36:02 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
【 在 hijack (孤读一身) 的大作中提到: 】
: 我说的恰恰事你要阐述的问题背后的因素
: 程序员经验到底有多少可以继承下来的?
（这个我对软件行业了解还太少，但是我想可以继承下来的肯定还是蛮多的吧，
如果在技术领域上有一脉相承的话，应该是很多继承的）
: 你们部门你可以权衡一下
: 7年经验的占?%
: 5年?%
: 3年?%
: 还有,我理解不了你的表达, 你一方面说你们的质量 主要看review
: 一方面有说主要看程序员自己的素质
: 那主要看什么那?
我想review和程序员的素质对于软件质量保证都很重要吧，
我如果前面有表达了一个更重要的意思，那是我表达有误，逻辑不严密，
但是楼主说到过程上的一些保证软件质量的方法，
我当然说到了把review作为一个重要过程了，因为程序员素质不是软件开发过程的事情
（上面的话没什么太多的漏洞吧？）
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
lostar 于 Sun Jul 25 20:41:59 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
这些各有各的做法，并不要求每个team都一致啊
某个工作在你这个team切实解决问题的，那你们就会去做，相反则不会。
所以不必强求
【 在 hijack (孤读一身) 的大作中提到: 】
: 如果按你那样说,很耗时间的,
: 耗时间 == 耗开发人员的激情
: 我得感觉,你们的机构可能有点臃肿
: 我们曾经一段时间也做过code review
: 用cvs来做的,自己弄了个eclipse plugin
: 后来还是消失了, 因为我觉得运行相应的测试代码就OK了
: 然后打个TODO的标签
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 20:43:46 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
KISS
我不知道这里有没有喜欢每天开会的开发人员?
如果有,出来交流一下好么?
我比较好奇
【 在 lostar (lostar@createsun.com) 的大作中提到: 】
: 这些各有各的做法，并不要求每个team都一致啊
: 某个工作在你这个team切实解决问题的，那你们就会去做，相反则不会。
: 所以不必强求
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
lostar 于 Sun Jul 25 20:47:10 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
我喜欢开会，不过我不是开发人员，哈哈
但是估计让我每天开会，我也很难受的，估计会以质量也就不高了
【 在 hijack (孤读一身) 的大作中提到: 】
: KISS
: 我不知道这里有没有喜欢每天开会的开发人员?
: 如果有,出来交流一下好么?
: 我比较好奇
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 20:43:52 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
【 在 hijack (孤读一身) 的大作中提到: 】
: 如果按你那样说,很耗时间的,
需要比较多的时间投入，但就我目前的感觉而言，这应该是值得的
: 耗时间 == 耗开发人员的激情
首先，我想投入比较多的时间不等于你说的“耗时间”，ms我没看到
开发人员没有激情，
: 我得感觉,你们的机构可能有点臃肿
我的感觉相反，高质量的软件或许正是需要大量的投入才可以保证一定可以做出来，
降低风险，
我以前的对于软件开发需要的工程量的估计过于偏低了（很可能你的也是）
当然，可能不同的项目其他方面的压力和限制不一样，
尤其是市场因素引起的时间限制等
: 我们曾经一段时间也做过code review
: 用cvs来做的,自己弄了个eclipse plugin
: 后来还是消失了, 因为我觉得运行相应的测试代码就OK了
: 需要修改的打个TODO的标签
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 20:50:07 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
你们做产品?
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 需要比较多的时间投入，但就我目前的感觉而言，这应该是值得的
: 首先，我想投入比较多的时间不等于你说的“耗时间”，ms我没看到
: 开发人员没有激情，
: 我的感觉相反，高质量的软件或许正是需要大量的投入才可以保证一定可以做出来，
: 降低风险，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
adoal 于 Sun Jul 25 20:44:33 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: （这个我对软件行业了解还太少，但是我想可以继承下来的肯定还是蛮多的吧，
: 如果在技术领域上有一脉相承的话，应该是很多继承的）
经验的继承不外乎有两种方法，一是在实践中口耳相传，
就像工艺领域的师徒那样，一是系统化，理论化，成文
传于后世。
如果一个开发团队的人员构成不够稳定，有多年工作经验
的人占的比例很少，那么口耳相传的方式就有很大问题，
一则师父自己的经验积累起来没多久可能就溜掉了，二则
本来可以做师父的人也许还没达到做师父的境界就走了，:p
至于系统化的方式……系统化本身就是比直接经验继承更
需要时间的事情，:p
Microsoft的十多个Chief Architect，里面大多数都是在
MS工作了十年以上甚至和公司接近同龄的人。
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 20:49:00 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
恩，你说的问题可能的确有，
因为我看到有同事打开outlook时经常说，
又开会！
但是，这里的会的确和我以前概念中的会不太一样，
真的每次讨论都是有非常实在的内容，
有leader的指点，同时也发挥team的力量，
大家都贡献自己的想法，无论是否正确，
【 在 hijack (孤读一身) 的大作中提到: 】
: KISS
: 我不知道这里有没有喜欢每天开会的开发人员?
: 如果有,出来交流一下好么?
: 我比较好奇
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 20:51:22 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
是的，inventor,3维机械设计软件，
如果你不知道的话就想象是3dmax或者是autocad，
那是另外部门做的，使用上看的话和3dmax共同处多一些
我虽然不知道他们部门的开发过程，但是我想一个公司
里面应该相差不太大，
【 在 hijack (孤读一身) 的大作中提到: 】
: 你们做产品?
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 20:53:43 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
呵呵,我不是说你们的公司,我也没权利,我是不知情的
我不知道我得观点对不对:
用最简单的方式去做事
可能我们的team比你们小的多吧
因为简单对我们而言就是高效
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 恩，你说的问题可能的确有，
: 因为我看到有同事打开outlook时经常说，
: 又开会！
: 但是，这里的会的确和我以前概念中的会不太一样，
: 真的每次讨论都是有非常实在的内容，
: 有leader的指点，同时也发挥team的力量，
: 大家都贡献自己的想法，无论是否正确，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 20:55:36 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
【 在 adoal (Isn't CMB crazy?) 的大作中提到: 】
: 经验的继承不外乎有两种方法，一是在实践中口耳相传，
: 就像工艺领域的师徒那样，一是系统化，理论化，成文
: 传于后世。
: 如果一个开发团队的人员构成不够稳定，有多年工作经验
: 的人占的比例很少，那么口耳相传的方式就有很大问题，
: 一则师父自己的经验积累起来没多久可能就溜掉了，二则
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
lostar 于 Sun Jul 25 20:56:26 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
说到这个，就需要提提企业的知识管理了。。。
以下内容为转载
知识管理大致包括以下6个内容：(1)知识管理的基础措施：它是知识管理的支持部
分，如数据库、知识库、多库协调系统、网络等基本技术手段以及人与人之间的各
种联系渠道等；(2)企业业务流程的重组：其目的是使企业的知识资源更加合理地
在知识链上形成畅通无阻的知识流，让每一个员工在获取与业务有关知识的同时，
都能为企业贡献自己的知识、经验和专长；(3)知识管理的方法：内容管理、文件
管理、记录管理、通信管理等；(4)知识的获取和检索：包括各种各样的软件应用
工具，例如智能客体检索、多策略获取、多模式获取和检索、多方法多层次获取和
检索、网络搜索工具等；(5)知识的传递：如建立知识分布图、电子文档、光盘、
DVD及网上传输、打印等；(6)知识的共享和评测：如建立一种良好的企业文化，激
励员工参与知识共享、设立知识总管、促进知识的转换、建立知识产生效益的评测
条例等。如何进行知识管理是我们首先要解决的理论和实际问题。
为此，我们把企业的业务流程看作是一个紧密连接的供应链，并将企业内部划分成
几个相互协同作业的支持子系统。将企业知识管理系统设计为：以知识生产、分配
，交换、获取、利用为主线，建立企业知识库系统。该系统还包括非知识资源子系
统、财务运作子系统、供给子系统、生产制造子系统、服务维护子系统、工程技术
子系统、市场营销子系统。
【 在 adoal (Isn't CMB crazy?) 的大作中提到: 】
: 经验的继承不外乎有两种方法，一是在实践中口耳相传，
: 就像工艺领域的师徒那样，一是系统化，理论化，成文
: 传于后世。
: 如果一个开发团队的人员构成不够稳定，有多年工作经验
: 的人占的比例很少，那么口耳相传的方式就有很大问题，
: 一则师父自己的经验积累起来没多久可能就溜掉了，二则
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
adoal 于 Sun Jul 25 20:57:39 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
有时候，某一方面的复杂是为了另一方面的简单，:p
【 在 hijack (孤读一身) 的大作中提到: 】
: 呵呵,我不是说你们的公司,我也没权利,我是不知情的
: 我不知道我得观点对不对:
: 用最简单的方式去做事
: 可能我们的team比你们小的多吧
: 因为简单对我们而言就是高效
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 20:59:14 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
嗯,有道理, 这就是封装,然后提供简单接口, 呵呵
【 在 adoal (Isn't CMB crazy?) 的大作中提到: 】
: 有时候，某一方面的复杂是为了另一方面的简单，:p
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
adoal 于 Sun Jul 25 21:00:37 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
而且对不同工作量、不同复杂程度的任务来说，
究竟哪种方式代价更小也是需要具体分析的。
【 在 hijack (孤读一身) 的大作中提到: 】
: 嗯,有道理, 这就是封装,然后提供简单接口, 呵呵
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 20:59:49 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
哦，可能我的理解有误，
我不知道hijack的继承究竟是你说的还是我说的，
我说的继承是指对于一个人本身，
他在这个领域内做了很多年，会积累一些经验，
这些经验他自己可以保留下来以后看到别人的设计，代码
等都会有用，可以很快的分辨出优良的和拙劣的
ms这里现在起作用的主要就是这些经验，
你说的继承是从一个人继承到另外一个人，
这个我不太清楚，这个部门在中国的分部建立还没超过一年，
我过来更是一个月都没，
目前看到的主要还是口耳相传为主，
但是也有一些培训和一些成文档的东西，
【 在 adoal (Isn't CMB crazy?) 的大作中提到: 】
: 经验的继承不外乎有两种方法，一是在实践中口耳相传，
: 就像工艺领域的师徒那样，一是系统化，理论化，成文
: 传于后世。
: 如果一个开发团队的人员构成不够稳定，有多年工作经验
: 的人占的比例很少，那么口耳相传的方式就有很大问题，
: 一则师父自己的经验积累起来没多久可能就溜掉了，二则
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 21:05:24 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
adoal和我表达的是一个意思
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 哦，可能我的理解有误，
: 我不知道hijack的继承究竟是你说的还是我说的，
: 我说的继承是指对于一个人本身，
: 他在这个领域内做了很多年，会积累一些经验，
: 这些经验他自己可以保留下来以后看到别人的设计，代码
: 等都会有用，可以很快的分辨出优良的和拙劣的
: ms这里现在起作用的主要就是这些经验，
: 你说的继承是从一个人继承到另外一个人，
: 这个我不太清楚，这个部门在中国的分部建立还没超过一年，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
adoal 于 Sun Jul 25 21:12:35 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
嗯。所以还是要有经验的，hoho
【 在 hijack (孤读一身) 的大作中提到: 】
: 这个...
: 理性分析颗粒度不能无穷下去
: 作产品有市场压力
: 做工程有客户压力
: 做开源也有市场压力啊
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 21:13:31 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
【 在 hijack (孤读一身) 的大作中提到: 】
: 没有监督,标准都是狗屁
: 不在第一线工作的人定的标准同样是狗屁文件
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~这个我不敢赞同，
他以前一直都在写代码，知道写代码的常见的问题，
虽然他现在不是第一线了，我觉得定的标准还是有指导意义的吧？
我觉得你说的是不是从来没在第一线工作过的人定的是狗屁？
: 只是给ISO等一些用的
: 我们最有用永远是在team cvs里的代码规范
: 每个team都不一样的
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Sun Jul 25 21:16:14 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
我不知道你为什么会提到这个继承？
这个继承难度比较大的吧？
直接依靠他自己积累的丰富经验的比较多吧？
【 在 hijack (孤读一身) 的大作中提到: 】
: adoal和我表达的是一个意思
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 21:34:39 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
这个可以看出一个公司很多东西了啊;)
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 我不知道你为什么会提到这个继承？
: 这个继承难度比较大的吧？
: 直接依靠他自己积累的丰富经验的比较多吧？
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Sun Jul 25 21:35:28 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
今天一个在苏州工作的同学,跟我说了他们老板的一句话:
老板也会犯错的...
我不是说这种标准不好,我得意思是不要把它看成红宝书,圣经
如果把它放到wiki或者大家都可以来完善的地方,我会觉得很好
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~这个我不敢赞同，
: 他以前一直都在写代码，知道写代码的常见的问题，
: 虽然他现在不是第一线了，我觉得定的标准还是有指导意义的吧？
: 我觉得你说的是不是从来没在第一线工作过的人定的是狗屁？
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
ArtWalker 于 Sun Jul 25 22:54:05 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
推荐一个
【 在 hijack (孤读一身) 的大作中提到: 】
: 去订阅一个开源项目developer的maillist或者参与开发
: 你就会亲身感受了
: PS:我们的用户没有理想中的那样主动
: 不过我们还是使用了use story的跟踪系统
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
ArtWalker 于 Sun Jul 25 22:57:18 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
你现在在哪实习啊？貌似是个牛公司
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 我们这里的arch，听说要求是25年软件开发经验（当然都在国外）
: 算起来至少是79年前了，
: 刚来一个leader，中国人，好像到现在差不多也快20年了，
: 他说他95开始学java，在第一线又干了几年，当然现在不在第一线了，
: 有7年编程经验还写代码的还是有一些的，
: 有一些已经不写代码了，但是在review的时候
: 是主要人物，部门成立小组专门做标准（一方面是标准，
: 另外希望最终可以达到peer review）也要这样的人来领导
: 经验主要在这个时候体现作用，现在是不是还在写代码不重要，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Mon Jul 26 10:11:47 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
好的开发环境，和好的PM
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 最近，在开发过程中，软件质量的问题似乎变得越来越严重。
: 最直接的表现就是提交给用户的产品，即使是试用，bug一大堆。
: 回过头来看的话，其实从最初的需求分析、系统设计……，
: 一直最后的编码、测试，虽然是按部就班来的，但感觉都是流于形式。
: 当然，这必然会导致最终软件质量的下降，甚至是低劣。
: 软件工程的道理大家都明白，但项目一个紧跟着一个，
: 直接的后果就是开发周期被急剧压缩，所有的程序员、测试员都在赶工。
: 所以，我知道，真正要想解决软件质量的问题，必须从这方面着手。
: 但是，这也仅限于理论层面上，实际中，当一个利润相对丰厚的项目摆在面前时，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Mon Jul 26 10:12:30 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
同意，不过还有的问题就是，上层管理者的素质
如果管理者不能下放足够的权限，而是用各个条条框框约束你
并且PM也非常的无能，一切都需要看Coder背地里使用更好的方法
那么，我想技术Coder再牛也没什么用
【 在 lostar (lostar@createsun.com) 的大作中提到: 】
: 提高价格，是提高质量的途径之一
: 如果一个项目两三个人，优秀的程序员所起到的作用不比软件工程低。
: 这时候，人是决定软件质量的一个重要因素。
: 钱多，用高质量开发人员，是一个不错的途径。
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Mon Jul 26 10:14:48 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 标 题: Re: 旧话重提：开发过程中的软件质量保证
: 发信站: 飘渺水云间 (Sun Jul 25 17:58:58 2004), 转信
:
:
: 是的，测试肯定是不能少的。其中考虑不到确实是一方面，
: 在这方面，测试员与程序员考虑问题的角度不同，
: 他们确实会提供一些很有建设性的意见和建议。
:
: 现在我的意思是，不考虑想法方面的问题，纯粹技术上的开发，
: 如何才能保证质量。
:
: 举个naive的例子，一个while循环，如果在条件后面多加了一个分号，
: 我想即使再有经验的程序员在编码的过程中也不敢保证一定不会出这样的错误，
: 但是如果在这段代码提交后，由另外一个程序员来check这段代码，
: 甚至单步跟踪调试，这种问题遗留的概率就很小了。
你这个例子和编程风格有关，如果你用
while(){
}
代替
while()
{
}
我想这个问题就不会发生了吧？所以在软件开发中，团队采用统一的，经过精心
设计的风格也非常重要，当然review代码也很重要，但是review的效率应该是很
低的，我现在做得东西对公司来说非常重要，但是PM至今未找到合适的人给我
review代码，完全靠我自己。我认为结对编程应该可以提高coding和review的效
率，不过一直没尝试，因为结对编程的成本也很高。
:
: 当然，这个例子属于极端初级的错误，一般程序员自己细心debug就会发现了。
: 只是想通过这个说明一点，我们是不是可以从一些管理的角度考虑提高质量。
:
: 毕竟，每个程序员的水平有限，不能指望所有的人一夜之间都变得优秀。
:
:
:
:
: --
: ═╮═╬═══╬═ ║ ╠═══════╯╭══╦═╦══╮
: ╰ ╭═╮╭═╮ ╰══╮║╭══╯╯║ ║ ║ ║ ╰══╩═╩══╯
: ═╮ ╰═╯╰═╯ ╭╯║╰╮ ╬═╬═╬═╬ ╰══╣ ╠══╯
: ╰╭╯══╬═╯ ╭╯ ║ ╰╮ ═╩═╩═╩═╩═╰══╣ ╠══╯
: ╭ ║══╬═╯╰╯ ║ ╰╯ ║ ║ ║ ║ ╰══╣ ╠══╯
: ═╯ ╯══╩═╯ ╰╯ ╯ ╯ ╰ ╰ ╯ ╯
:
: ※ 来源:·飘渺水云间 freecity.cn·[FROM: bird]
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Mon Jul 26 10:19:22 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
必须和一批优秀的人在一起才能这么做
否则系统的设计完全达不到unit test的要求
我现在想在现有系统中添如unit test都非常困难
因为没有足够的接口支持
【 在 hijack (孤读一身) 的大作中提到: 】
: unit test + nightly build
: 测试结果第二天就在memeber的邮箱里了
: Opensource都这么做的
: 我们也在努力做auto nighly build
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Mon Jul 26 10:20:52 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
呵呵，我回上面的帖子，谈结对编程的时候，满脑子也都是adoal的那篇文章:P
也许是国内大部分企业都没有结对编程的环境:)
【 在 hijack (孤读一身) 的大作中提到: 】
: 让我想起阿豆的那篇文章,哈哈
: 说说你的xp结对实践,我们看到一些缺点
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Mon Jul 26 10:24:01 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
这个让人非常沮丧，我想在7年后依然可以coding，
但是我想那时我肯定因为环境的原因被迫去做管理，或是别的事情
虽然这些也是我喜欢的:)
【 在 hijack (孤读一身) 的大作中提到: 】
: 一个公司有7年编程经验的程序员(现在还在写程序)到底有多少阿?
: 5年的有多少?
: 3年的有多少?
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Mon Jul 26 10:28:13 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
ms中国的程序员不够懒，嘿嘿
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 对于投入，我最近感受非常深刻，
: 觉得以前对于高质量软件开发所需要的工程量
: 的估计一直都过低的厉害，
: 有的时候ms急进也可以做出来，
: 尤其是土生土长的中国人，很喜欢这样（当然又聪明又能干也是一个方面：）
: 但是感觉这事实上是非常危险的做完
: 明显的特点是华为跳槽过来的员工，
: 经常干活特别的快，leader说这个礼拜我们先
: 做一些research的事情，然后大家讨论一下如何设计，
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Mon Jul 26 10:32:02 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
那天yy跟我说过的，我忘了:(上海某公司
【 在 ArtWalker (直觉艺术家.Evolution) 的大作中提到: 】
: 你现在在哪实习啊？貌似是个牛公司
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
lostar 于 Mon Jul 26 10:53:24 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
开发人员应该包含PM和Coder
其实我比较提倡这样的小团队不要把职务定的这样死，
我提倡分工明确、各方面都有一个人负责就行了。
而PM并不是领导，只是负责一些计划等工作。
刚刚看到一句话叫作“天下兴亡，我的责任”
大家都以出色的完成项目为己任的话，这个项目团队会更具有战斗力。
【 在 LazyCoder (未婚好男人) 的大作中提到: 】
: 同意，不过还有的问题就是，上层管理者的素质
: 如果管理者不能下放足够的权限，而是用各个条条框框约束你
: 并且PM也非常的无能，一切都需要看Coder背地里使用更好的方法
: 那么，我想技术Coder再牛也没什么用
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Mon Jul 26 10:59:15 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
【 在 lostar (lostar@createsun.com) 的大作中提到: 】
: 开发人员应该包含PM和Coder
: 其实我比较提倡这样的小团队不要把职务定的这样死，
: 我提倡分工明确、各方面都有一个人负责就行了。
: 而PM并不是领导，只是负责一些计划等工作。
: 刚刚看到一句话叫作“天下兴亡，我的责任”
这句话ms只能对自己要求，如果作为PM，你硬要说“天下兴亡 ，每个人的责任”
我想肯定作不好的，而仅仅一个Coder这么认为，当然也是作不好的
你有什么办法让每个Coder都这么认为吗？我想这应该是PM的管理能力的体现
: 大家都以出色的完成项目为己任的话，这个项目团队会更具有战斗力。
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
lostar 于 Mon Jul 26 11:04:59 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
现在都强调team work，3个人，如果是一个管另外两个，我倒觉得不如三个人
是一个团队来的更好。当然，前提是成员都是高素质的。
【 在 LazyCoder (未婚好男人) 的大作中提到: 】
: 这句话ms只能对自己要求，如果作为PM，你硬要说“天下兴亡 ，每个人的责任”
: 我想肯定作不好的，而仅仅一个Coder这么认为，当然也是作不好的
: 你有什么办法让每个Coder都这么认为吗？我想这应该是PM的管理能力的体现
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Mon Jul 26 11:07:18 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
【 在 lostar (lostar@createsun.com) 的大作中提到: 】
: 现在都强调team work，3个人，如果是一个管另外两个，我倒觉得不如三个人
: 是一个团队来的更好。当然，前提是成员都是高素质的。
这样的前提太理想化了，一般软件公司能招到多少这样的人？
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
lazydog 于 Mon Jul 26 12:14:44 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
是AutoDesk，你个土鳖，这么牛×的公司都记不住
【 在 LazyCoder (未婚好男人) 的大作中提到: 】
: 那天yy跟我说过的，我忘了:(上海某公司
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
ArtWalker 于 Mon Jul 26 12:29:46 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
寒
狂admire
【 在 lazydog (流浪的懒狗) 的大作中提到: 】
: 是AutoDesk，你个土鳖，这么牛×的公司都记不住
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Mon Jul 26 12:39:04 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
这个公司是干吗的？我不知道
【 在 lazydog (流浪的懒狗) 的大作中提到: 】
: 是AutoDesk，你个土鳖，这么牛×的公司都记不住
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
westmoon 于 Mon Jul 26 15:22:04 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
做autocad的那个。。。
【 在 LazyCoder (未婚好男人) 的大作中提到: 】
: 这个公司是干吗的？我不知道
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Mon Jul 26 18:35:05 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
为公司宣传一下：）
autodesk是世界领先的数字化设计软件和数字内容供应商，
她和ms是世界上仅有的两家生存了20年以上的软件公司，
公司产品很多，最出名的恐怕就是autocad和3dmax了，
现在上海这里也是做产品的
【 在 LazyCoder (未婚好男人) 的大作中提到: 】
: 这个公司是干吗的？我不知道
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Mon Jul 26 18:51:52 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
^_^,好像什么公司都说世界领先的
joke
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 为公司宣传一下：）
: autodesk是世界领先的数字化设计软件和数字内容供应商，
: 她和ms是世界上仅有的两家生存了20年以上的软件公司，
: 公司产品很多，最出名的恐怕就是autocad和3dmax了，
: 现在上海这里也是做产品的
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
huangxuhao 于 Mon Jul 26 18:52:14 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
不错不错，不过AutoDesk ms对大陆有技术封锁 啊
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 为公司宣传一下：）
: autodesk是世界领先的数字化设计软件和数字内容供应商，
: 她和ms是世界上仅有的两家生存了20年以上的软件公司，
: 公司产品很多，最出名的恐怕就是autocad和3dmax了，
: 现在上海这里也是做产品的
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
mwong 于 Mon Jul 26 18:54:13 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
你们公司今年业绩很不错啊：）
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 为公司宣传一下：）
: autodesk是世界领先的数字化设计软件和数字内容供应商，
: 她和ms是世界上仅有的两家生存了20年以上的软件公司，
: 公司产品很多，最出名的恐怕就是autocad和3dmax了，
: 现在上海这里也是做产品的
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
huangxuhao 于 Mon Jul 26 18:53:52 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
宣传嘛，我们公司喜欢用"亚太区最大的"...
【 在 hijack (孤读一身) 的大作中提到: 】
: ^_^,好像什么公司都说世界领先的
: joke
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
lazydog 于 Mon Jul 26 19:07:52 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
牛dd，以后招我进去打杂
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 为公司宣传一下：）
: autodesk是世界领先的数字化设计软件和数字内容供应商，
: 她和ms是世界上仅有的两家生存了20年以上的软件公司，
: 公司产品很多，最出名的恐怕就是autocad和3dmax了，
: 现在上海这里也是做产品的
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Mon Jul 26 19:49:50 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
晕，我admire你都不知道到什么程度了
【 在 ArtWalker (直觉艺术家.Evolution) 的大作中提到: 】
: 寒
: 狂admire
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Mon Jul 26 19:52:14 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
恩，有一定share的都爽死了
【 在 mwong (罐头米糕の在人间) 的大作中提到: 】
: 你们公司今年业绩很不错啊：）
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
frankcai 于 Mon Jul 26 19:58:42 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
我是要被赶出去的那种：（【 在 lazydog (流浪的懒狗) 的大作中提到: 】
: 牛dd，以后招我进去打杂
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
adoal 于 Mon Jul 26 20:10:41 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
几乎所有人都把3ds max叫成3d max……:p
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 为公司宣传一下：）
: autodesk是世界领先的数字化设计软件和数字内容供应商，
: 她和ms是世界上仅有的两家生存了20年以上的软件公司，
: 公司产品很多，最出名的恐怕就是autocad和3dmax了，
: 现在上海这里也是做产品的
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
mwong 于 Mon Jul 26 20:23:17 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
你做产品开发吗？
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 恩，有一定share的都爽死了
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Mon Jul 26 20:34:16 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
上面说了,作产品
【 在 mwong (罐头米糕の在人间) 的大作中提到: 】
: 你做产品开发吗？
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
mwong 于 Mon Jul 26 20:37:23 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
知道阿，产品team里也有不同role的嘛
【 在 hijack (孤读一身) 的大作中提到: 】
: 上面说了,作产品
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
ArtWalker 于 Mon Jul 26 21:11:28 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
还好偶是玩3DS 4.0长大的
【 在 adoal (Isn't CMB crazy?) 的大作中提到: 】
: 几乎所有人都把3ds max叫成3d max……:p
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Tue Jul 27 09:06:05 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
所以我很崇拜尼～
【 在 ArtWalker (直觉艺术家.Evolution) 的大作中提到: 】
: 还好偶是玩3DS 4.0长大的
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
marong 于 Tue Jul 27 10:17:35 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
谁说的？？
ESRI快生存了30年了。1975年开始做GIS软件。
世界头号地理信息系统提供商
【 在 frankcai (从少林长拳到易筋经) 的大作中提到: 】
: 为公司宣传一下：）
: autodesk是世界领先的数字化设计软件和数字内容供应商，
: 她和ms是世界上仅有的两家生存了20年以上的软件公司，
: 公司产品很多，最出名的恐怕就是autocad和3dmax了，
: 现在上海这里也是做产品的
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
lionheart 于 Tue Jul 27 11:45:27 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
1) 轮换制编程：一个人不能连续编程超过三天
2) 每天REVIEW：第二次发现同样错就扣钱给PM
3) 每两天开会：校验进度、发现异常点
4) 每三天BUILD
5) SHADOW团队：保持对现职团队的压力
【 在 bird (灌水中，请勿打扰...) 的大作中提到: 】
: 最近，在开发过程中，软件质量的问题似乎变得越来越严重。
: 最直接的表现就是提交给用户的产品，即使是试用，bug一大堆。
: 回过头来看的话，其实从最初的需求分析、系统设计……，
: 一直最后的编码、测试，虽然是按部就班来的，但感觉都是流于形式。
: 当然，这必然会导致最终软件质量的下降，甚至是低劣。
: 软件工程的道理大家都明白，但项目一个紧跟着一个，
: 直接的后果就是开发周期被急剧压缩，所有的程序员、测试员都在赶工。
: 所以，我知道，真正要想解决软件质量的问题，必须从这方面着手。
: 但是，这也仅限于理论层面上，实际中，当一个利润相对丰厚的项目摆在面前时，
: >> .................<以下省略>............
[首页, 上一页, 下一页; 目录 ]
4.3 比较想说的一些话
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Tue Jul 27 21:14:52 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
我是个程序员,很普通,走到大街上肯定谁都不认识的那种.
或许和大家一样,我也很喜欢技术,喜欢挑战,甚至"变态"的喜欢难题.
下面是我近来的一些感想,不全对.
我先说说我所理解的程序员的道路吧:
技术追求 --> 问题域分析 --> 问题域建模 --> 创造自己的技术
承然,我想我和大家都在走技术追求这一点,
我不否认,这是必经历的, 因为这是以后的资本积累.
但是我想说的是:不要盲目的技术积累.当你觉得技术积累到一定程度, 比如当你能够
承担一个开发小组的主力时,我想大家应该考虑进入一个问题域.思考一下,你的
技术能够解决那些问题域的难题,这些问题域的市场前景如何,你对这些问题域
感兴趣么.
考虑这些问题的价值并不亚于你苦苦的追求一种技术
我现在的感觉,比起技术,我更加喜欢方法论,就是"技术追求"后面的那几个阶段
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
mwong 于 Tue Jul 27 21:34:43 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
问题域的两个阶段如何帮助到创造自己的技术这一步的？
创造技术需要在问题域有多少程度的投入？
靠这些投入就足够了吗？
【 在 hijack (孤读一身) 的大作中提到: 】
: 我是个程序员,很普通,走到大街上肯定谁都不认识的那种.
: 或许和大家一样,我也很喜欢技术,喜欢挑战,甚至"变态"的喜欢难题.
: 下面是我近来的一些感想,不全对.
: 我先说说我所理解的程序员的道路吧:
: 技术追求 --> 问题域分析 --> 问题域建模 --> 创造自己的技术
: 承然,我想我和大家都在走技术追求这一点,
: 我不否认,这是必经历的, 因为这是以后的资本积累.
: 但是我想说的是:不要盲目的技术积累.当你觉得技术积累到一定程度, 比如当你能够
: 承担一个开发小组的主力时,我想大家应该考虑进入一个问题域.思考一下,你的
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Tue Jul 27 21:37:43 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
我没有完完全全的走,但好像在迭代
问题域可以说是无穷尽的吧,看看现在的JSR,它已经不仅仅涉及技术,
甚至它在问题域建模. 只要你精通一个问题域,你肯定会发现现在模型的
缺陷,那时候用既有的技术来写自己的东西也不是难事
好比jini,javaspace其实他们都不是新技术,仅仅是为解决问题的特化技术而已
【 在 mwong (罐头米糕の在人间) 的大作中提到: 】
: 问题域的两个阶段如何帮助到创造自己的技术这一步的？
: 创造技术需要在问题域有多少程度的投入？
: 靠这些投入就足够了吗？
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Tue Jul 27 21:42:56 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
jakarta的很多项目都是问题域专家捐赠的代码
【 在 hijack (孤读一身) 的大作中提到: 】
: 我没有完完全全的走,但好像在迭代
: 问题域可以说是无穷尽的吧,看看现在的JSR,它已经不仅仅涉及技术,
: 甚至它在问题域建模. 只要你精通一个问题域,你肯定会发现现在模型的
: 缺陷,那时候用既有的技术来写自己的东西也不是难事
: 好比jini,javaspace其实他们都不是新技术,仅仅是为解决问题的特化技术而已
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
mwong 于 Tue Jul 27 21:44:16 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
你对“问题域”的定义是什么？
【 在 hijack (孤读一身) 的大作中提到: 】
: 我没有完完全全的走,但好像在迭代
: 问题域可以说是无穷尽的吧,看看现在的JSR,它已经不仅仅涉及技术,
: 甚至它在问题域建模. 只要你精通一个问题域,你肯定会发现现在模型的
: 缺陷,那时候用既有的技术来写自己的东西也不是难事
: 好比jini,javaspace其实他们都不是新技术,仅仅是为解决问题的特化技术而已
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Tue Jul 27 21:48:15 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
我不想去google一段问题域的定义
说说我自己的理解吧,不对给我指出来
1.问题域是有颗粒度的.
2.问题域有行业背景,就是所谓的专业知识壁垒
3.问题域应该有对应的解域
【 在 mwong (罐头米糕の在人间) 的大作中提到: 】
: 你对“问题域”的定义是什么？
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Tue Jul 27 21:55:39 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
等待时机成熟,我想88可以开设一个DomailModel板块
讨论不同问题域的软件建模
【 在 hijack (孤读一身) 的大作中提到: 】
: 我不想去google一段问题域的定义
: 说说我自己的理解吧,不对给我指出来
: 1.问题域是有颗粒度的.
: 2.问题域有行业背景,就是所谓的专业知识壁垒
: 3.问题域应该有对应的解域
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
mwong 于 Tue Jul 27 21:53:29 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
没有什么不对呵呵，
我只是想首先确定一下后面的讨论基于同一个对问题域的理解
回到前面的问题，我想知道的是问题域，尤其是第二点，是如何对技术创新起到帮助的
之所以问这个问题
今天有人问我，AOP在电信行业里怎么应用，我一下子懵了
因为我概念中的技术一般是跨问题域而存在的
【 在 hijack (孤读一身) 的大作中提到: 】
: 我不想去google一段问题域的定义
: 说说我自己的理解吧,不对给我指出来
: 1.问题域是有颗粒度的.
: 2.问题域有行业背景,就是所谓的专业知识壁垒
: 3.问题域应该有对应的解域
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Tue Jul 27 21:59:55 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
汗,上回刚刚和swear谈起他们的项目
不知道是不是他们的商业机密啊
他们打算建一个分布式的weave系统,呵呵,那样客户端的代码可以
减少很多
那个问题,我想已经回答了. 我想某技术所以能够保存活力
因为她解决了特定的问题
所以技术创新的灵感,来源于你对问题域太了解了
【 在 mwong (罐头米糕の在人间) 的大作中提到: 】
: 没有什么不对呵呵，
: 我只是想首先确定一下后面的讨论基于同一个对问题域的理解
: 回到前面的问题，我想知道的是问题域，尤其是第二点，是如何对技术创新起到帮助的
: 之所以问这个问题
: 今天有人问我，AOP在电信行业里怎么应用，我一下子懵了
: 因为我概念中的技术一般是跨问题域而存在的
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Tue Jul 27 22:06:16 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
经验不够:(
aspectwerkz的founder在bea才算是senior software engineer
汗,多牛的人啊
【 在 swear (达人甲) 的大作中提到: 】
: 来做research吧，haha
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
mwong 于 Tue Jul 27 22:07:16 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
汗。。。再说说你对“技术”的定义？
我理解的技术可不是解决了“特定”问题的，而是可以解决一堆问题
例如网格，可以用在教育上，医疗，金融……
例如J2EE，同样跟问题域是正交的
这个例子里更多的是一种solution？
【 在 hijack (孤读一身) 的大作中提到: 】
: 汗,上回刚刚和swear谈起他们的项目
: 不知道是不是他们的商业机密啊
: 他们打算建一个分布式的weave系统,呵呵,那样客户端的代码可以
: 减少很多
: 那个问题,我想已经回答了. 我想某技术所以能够保存活力
: 因为她解决了特定的问题
: 所以技术创新的灵感,来源于你对问题域太了解了
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Tue Jul 27 22:12:01 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
更正
特定 ---> 一类
我说的颗粒度肯定比你理解的要细
【 在 mwong (罐头米糕の在人间) 的大作中提到: 】
: 汗。。。再说说你对“技术”的定义？
: 我理解的技术可不是解决了“特定”问题的，而是可以解决一堆问题
: 例如网格，可以用在教育上，医疗，金融……
: 例如J2EE，同样跟问题域是正交的
: 这个例子里更多的是一种solution？
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
nimbus 于 Tue Jul 27 22:35:37 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
做技术咨询吧，以技术为基础，以行业知识为背景，两者结合
应该说职业的基础条件就比较完备了，至少比较有方向感。
【 在 hijack (孤读一身) 的大作中提到: 】
: 我是个程序员,很普通,走到大街上肯定谁都不认识的那种.
: 或许和大家一样,我也很喜欢技术,喜欢挑战,甚至"变态"的喜欢难题.
: 下面是我近来的一些感想,不全对.
: 我先说说我所理解的程序员的道路吧:
: 技术追求 --> 问题域分析 --> 问题域建模 --> 创造自己的技术
: 承然,我想我和大家都在走技术追求这一点,
: 我不否认,这是必经历的, 因为这是以后的资本积累.
: 但是我想说的是:不要盲目的技术积累.当你觉得技术积累到一定程度, 比如当你能够
: 承担一个开发小组的主力时,我想大家应该考虑进入一个问题域.思考一下,你的
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
Jackle 于 Wed Jul 28 00:01:13 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
我觉得为技术分领域好像不妥
不过系统的分析和建模以及一些
解决方案有领域性性或者
在几个相似的领域内可以互通
作consulting应该也就是因为
有某个领域的实施经验所以
能牛比吧
【 在 hijack (孤读一身) 的大作中提到: 】
: 我是个程序员,很普通,走到大街上肯定谁都不认识的那种.
: 或许和大家一样,我也很喜欢技术,喜欢挑战,甚至"变态"的喜欢难题.
: 下面是我近来的一些感想,不全对.
: 我先说说我所理解的程序员的道路吧:
: 技术追求 --> 问题域分析 --> 问题域建模 --> 创造自己的技术
: 承然,我想我和大家都在走技术追求这一点,
: 我不否认,这是必经历的, 因为这是以后的资本积累.
: 但是我想说的是:不要盲目的技术积累.当你觉得技术积累到一定程度, 比如当你能够
: 承担一个开发小组的主力时,我想大家应该考虑进入一个问题域.思考一下,你的
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Wed Jul 28 00:19:48 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
其实我要主要表达的意思是:
不要总是跟着别人的技术走,不要麻木掉
其实慢慢的,我们也可以来创造我们的技术
【 在 Jackle (睡睡~~WindForce) 的大作中提到: 】
: 我觉得为技术分领域好像不妥
: 不过系统的分析和建模以及一些
: 解决方案有领域性性或者
: 在几个相似的领域内可以互通
: 作consulting应该也就是因为
: 有某个领域的实施经验所以
: 能牛比吧
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Wed Jul 28 00:23:12 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
也不是刻意去划分,或者刻意去追求
就像Oberg,不知不觉就成了CMS expert.
可能自己把握的吧
自己觉得感兴趣就进去
但这段时间有人很短,有人很长
【 在 hijack (孤读一身) 的大作中提到: 】
: 其实我要主要表达的意思是:
: 不要总是跟着别人的技术走,不要麻木掉
: 其实慢慢的,我们也可以来创造我们的技术
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Wed Jul 28 08:58:32 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
这个要看兴趣的，其实你说的只是程序员发展的一个方向而已，一个小小的方向
【 在 hijack (孤读一身) 的大作中提到: 】
: 我是个程序员,很普通,走到大街上肯定谁都不认识的那种.
: 或许和大家一样,我也很喜欢技术,喜欢挑战,甚至"变态"的喜欢难题.
: 下面是我近来的一些感想,不全对.
: 我先说说我所理解的程序员的道路吧:
: 技术追求 --> 问题域分析 --> 问题域建模 --> 创造自己的技术
: 承然,我想我和大家都在走技术追求这一点,
: 我不否认,这是必经历的, 因为这是以后的资本积累.
: 但是我想说的是:不要盲目的技术积累.当你觉得技术积累到一定程度, 比如当你能够
: 承担一个开发小组的主力时,我想大家应该考虑进入一个问题域.思考一下,你的
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
gzhzjk 于 Wed Jul 28 08:57:31 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
强烈的re啊，至少在java方面，感觉中国拿得出手的东西好像不多，
也许被项目耗着的程序员太多了吧，也许是技术的进步太快，让我们跟着都很费力了
【 在 hijack (孤读一身) 的大作中提到: 】
: 其实我要主要表达的意思是:
: 不要总是跟着别人的技术走,不要麻木掉
: 其实慢慢的,我们也可以来创造我们的技术
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Wed Jul 28 09:05:47 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
【 在 gzhzjk (chandler) 的大作中提到: 】
: 强烈的re啊，至少在java方面，感觉中国拿得出手的东西好像不多，
: 也许被项目耗着的程序员太多了吧，也许是技术的进步太快，让我们跟着都很费力了
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
是的,所以导致很多技术我们只知道怎么用,但是不知道为什么会有这个技术
人家花了10几年研究出来的技术,并不是看源代码就可以全部领会的.
因为我们抛弃了技术的context.
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Wed Jul 28 09:11:54 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
构思技术不是那么容易的，我觉得我不是那样的天才，
或许几十年后，我可以凭经验弥补我天资不不足
【 在 hijack (孤读一身) 的大作中提到: 】
: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: 是的,所以导致很多技术我们只知道怎么用,但是不知道为什么会有这个技术
: 人家花了10几年研究出来的技术,并不是看源代码就可以全部领会的.
: 因为我们抛弃了技术的context.
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Wed Jul 28 09:33:21 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
几十年后,你还会写程序?我不信
【 在 LazyCoder (未婚好男人) 的大作中提到: 】
: 构思技术不是那么容易的，我觉得我不是那样的天才，
: 或许几十年后，我可以凭经验弥补我天资不不足
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Wed Jul 28 09:43:54 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
我想，但估计不会，哈哈
【 在 hijack (孤读一身) 的大作中提到: 】
: 几十年后,你还会写程序?我不信
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
mifeng 于 Wed Jul 28 10:00:16 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
感觉java方面中国应该可以出一些东西啊
可能真的是程序员没有时间和精力去做自己喜欢的那些东西。
大家都在为一些商业的软件，项目忙个不停。
【 在 gzhzjk (chandler) 的大作中提到: 】
: 强烈的re啊，至少在java方面，感觉中国拿得出手的东西好像不多，
: 也许被项目耗着的程序员太多了吧，也许是技术的进步太快，让我们跟着都很费力了
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
FishInSky 于 Wed Jul 28 10:03:40 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
中国程序员的生活像民工，太多民工型的程序员，太多人把程序员当民工
【 在 mifeng (是。非。黑。白。) 的大作中提到: 】
: 感觉java方面中国应该可以出一些东西啊
: 可能真的是程序员没有时间和精力去做自己喜欢的那些东西。
: 大家都在为一些商业的软件，项目忙个不停。
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Wed Jul 28 10:06:50 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
早上有翻了翻人月神话，非常向往外科手术队伍～
程序员可以从非创造性的事务中解放出来
【 在 FishInSky (鱼鱼也飞翔&蝴蝶效应的受害者) 的大作中提到: 】
: 中国程序员的生活像民工，太多民工型的程序员，太多人把程序员当民工
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
xuchuan 于 Wed Jul 28 10:18:32 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
怎么可能，民工活实在太多了，程序员不做叫谁去做？难道真的雇佣民工来做？
【 在 LazyCoder (未婚好男人) 的大作中提到: 】
: 早上有翻了翻人月神话，非常向往外科手术队伍～
: 程序员可以从非创造性的事务中解放出来
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Wed Jul 28 10:19:08 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
而关键是自己也把自己看作了民工
【 在 FishInSky (鱼鱼也飞翔&蝴蝶效应的受害者) 的大作中提到: 】
: 中国程序员的生活像民工，太多民工型的程序员，太多人把程序员当民工
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Wed Jul 28 10:20:07 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
看什么活了，你觉得让一个架构师或首席程序员在思考怎么写程序的同时
还要写好那些程序的文档，处理好一些规范话的东西，能受得了吗？
至于技术含量低的活，当然是训练一批专业的人来做，而不是程序员
【 在 xuchuan (xuchuan) 的大作中提到: 】
: 怎么可能，民工活实在太多了，程序员不做叫谁去做？难道真的雇佣民工来做？
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
xuchuan 于 Wed Jul 28 10:23:49 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
什么是程序员？
【 在 LazyCoder (未婚好男人) 的大作中提到: 】
: 看什么活了，你觉得让一个架构师或首席程序员在思考怎么写程序的同时
: 还要写好那些程序的文档，处理好一些规范话的东西，能受得了吗？
: 至于技术含量低的活，当然是训练一批专业的人来做，而不是程序员
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
hijack 于 Wed Jul 28 10:22:44 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
一个好的文档是一个好的opensource存活的关键
也是出论文的好地方,呵呵
这是必须的.不过我很少看到国外有架构师的称呼,senior software engineer
上面就是scientist?
什么叫技术含量低的活?比如...
【 在 LazyCoder (未婚好男人) 的大作中提到: 】
: 看什么活了，你觉得让一个架构师或首席程序员在思考怎么写程序的同时
: 还要写好那些程序的文档，处理好一些规范话的东西，能受得了吗？
: 至于技术含量低的活，当然是训练一批专业的人来做，而不是程序员
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Wed Jul 28 10:35:46 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
好的文档，由架构师口述或草稿，专业的文档书写者整理，规范，这样更好，不是吗？
【 在 hijack (孤读一身) 的大作中提到: 】
: 一个好的文档是一个好的opensource存活的关键
: 也是出论文的好地方,呵呵
: 这是必须的.不过我很少看到国外有架构师的称呼,senior software engineer
: 上面就是scientist?
: 什么叫技术含量低的活?比如...
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
LazyCoder 于 Wed Jul 28 10:37:06 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
在软件开发上，必须强调专业分工，不能让好的程序员干所有的事，应该物尽其用
【 在 LazyCoder (未婚好男人) 的大作中提到: 】
: 好的文档，由架构师口述或草稿，专业的文档书写者整理，规范，这样更好，不是吗？
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
devis 于 Wed Jul 28 12:11:03 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
牛人是学生还是工作了，我觉的你超越一般的水平
【 在 hijack (孤读一身) 的大作中提到: 】
: 我是个程序员,很普通,走到大街上肯定谁都不认识的那种.
: 或许和大家一样,我也很喜欢技术,喜欢挑战,甚至"变态"的喜欢难题.
: 下面是我近来的一些感想,不全对.
: 我先说说我所理解的程序员的道路吧:
: 技术追求 --> 问题域分析 --> 问题域建模 --> 创造自己的技术
: 承然,我想我和大家都在走技术追求这一点,
: 我不否认,这是必经历的, 因为这是以后的资本积累.
: 但是我想说的是:不要盲目的技术积累.当你觉得技术积累到一定程度, 比如当你能够
: 承担一个开发小组的主力时,我想大家应该考虑进入一个问题域.思考一下,你的
: >> .................<以下省略>............
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
apple 于 Wed Jul 28 17:11:12 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
good，那和我一样了
写设计文档，拿下去给coder做，他们做好了我检查
【 在 mifeng (是。非。黑。白。) 的大作中提到: 】
: 我？现在就是写文档，检查，测试等等，反正就是周边的事情。
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
tomsgang 于 Wed Jul 28 17:13:51 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
强的，我们都是老板和我们谈想法，然后我们做，我们写文档
【 在 apple (疲惫的大苹果※为什么会是这样..) 的大作中提到: 】
: good，那和我一样了
: 写设计文档，拿下去给coder做，他们做好了我检查
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
noden 于 Thu Jul 29 10:54:10 2004 的发言如下:
☆━━━━━━━━━━━━━━━━━━━━━━━━━━━━☆
re。
不过，感觉到了问题建模这个阶段，技术倒不是太重要了，尤其是粒度较大的问题域。
这时候考虑的是整个模型的架构，整个模型的运行机制，这时候和技术、甚至计算机本
身都没有什么关联了。
至于自己创造的技术，我觉得倒可以称为自己创造的模型或者解决方案比较好。
当然，如果自己创造出一种语言，那倒是的，^_^。
【 在 hijack (孤读一身) 的大作中提到: 】
: 我是个程序员,很普通,走到大街上肯定谁都不认识的那种.
: 或许和大家一样,我也很喜欢技术,喜欢挑战,甚至"变态"的喜欢难题.
: 下面是我近来的一些感想,不全对.
: 我先说说我所理解的程序员的道路吧:
: 技术追求 --> 问题域分析 --> 问题域建模 --> 创造自己的技术
: 承然,我想我和大家都在走技术追求这一点,
: 我不否认,这是必经历的, 因为这是以后的资本积累.
: 但是我想说的是:不要盲目的技术积累.当你觉得技术积累到一定程度, 比如当你能够
: 承担一个开发小组的主力时,我想大家应该考虑进入一个问题域.思考一下,你的
: >> .................<以下省略>............
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- [竹马推荐]砖头XP(88TechReview提供)
- 体验Spring的“IoC容器”对开发过程中的简化 推荐
- 史上最强IDE集成开发环境——Code::Blocks安装过程（吐血推荐）
- 敏捷开发过程剖析及工具推荐
- IOS开发UI篇—推荐两个好用的Xcode插件（提供下载链接）
- 好工具推荐--网页分析工具 httpwatch 网页开发不可或缺的辅助工具 提供httpwatch下载（包含破解）
- iOS开发UI篇—推荐两个好用的Xcode插件（提供下载链接）
- [竹马推荐]转型：管理之路VS技术之路(管理频道提供)
- ios开发推荐两个好用的xcode插件，提供下载链接
- iOS开发UI篇—推荐两个好用的Xcode插件（提供下载链接）
- 软件开发过程中的审查 (Review)
- 软件开发过程中的变更请求管理 推荐
- 个人在iOS开发过程中真机调试遇到的问题及解决方法 推荐
- iOS开发UI篇—推荐两个好用的Xcode插件（提供下载链接）
- 单机版简易考试系统开发过程讲解(C#注册机、用户注册、考试系统、有偿提供全部源码)
- 用Validator（验证器）提供的丰富的内置验证方法简化Struts的开发过程。
- 用Validator（验证器）提供的丰富的内置验证方法简化Struts的开发过程。
- 软件开发过程中的审查 (Review)
- [推荐] vs2010+Silverlight4+wcf开发部署全过程