当前位置: 简表范文网 > 心得体会 >

写出质量好软件75条方法和体会(完整)

| 来源:网友投稿

下面是小编为大家整理的写出质量好软件75条方法和体会(完整),供大家参考。

写出质量好软件75条方法和体会(完整)

 

 写出质量好的软件的 5 75 条方法和体会

 1. 你们的项目组使用源代码管理工具了么? ?

 应该用。

 VSS 、 CVS 、 PVCS 、 ClearCase 、 CCC/Harvest 、y FireFly 都可以。我的选择是 VSS 。

 2. 你们的项目组使用缺陷管理系统了么? ?

 应该用。t ClearQuest 太复杂,我的推荐是 BugZilla 。

 3. 你们的测试组还在用 d Word 写测试用例么? ?

 不要用 d Word 写测试用例 (Test Case) 。应该用一个专门的系统,可以是 Test Manager ,也可以是自己开发一个T ASP.NET 的小网站。主要目的是 k Track 和 和 Browse 。

 4. 你们的项目组有没有建立一个门户网站? ?

 要有一个门户网站,用来放 Contact Info 、 Baselined Schedule 、s News 等等。推荐 Sharepoint Portal Server X 20XX 来实现,5 15 分钟就搞定。买不起 X SPS 20XX 可以用 WSS (Windows Sharepoint Service) 。

 5. 你们的项目组用了你能买到最好的工具么? ?

 应该用尽量好的工具来工作。比如,应该用 T VS.NET 而不是 是 Nod tepad 来写 C# 。用 d Notepad 写程序多半只是一种炫耀。但也要考虑到经费,所以说是 “ 你能买到最好的 ” 。

 6. 你们的程序员工作在安静的环境里么? ?

 需要安静的环境。这一点极其重要,每个人的空间要大于某个区域。

 7. 你们的员工每个人都有一部电话么? ?

 需要每人一部电话。而且电话最好是带留言功能的。当然,上这么一套带留言电话系统开销不小。不过至少每人一部电话要有,千万别搞得经常有人站起来喊:

 “ 某某某电话 ” 。《人件》里面就强烈谴责这种做法。

 8. 你们每个人都知道出了问题应该找谁么? ?

 应 该知道。任何一个 e Feature 至少都应该有一个 Owner ,当然,r Owner 可以继续 h Dispatch 给其他人。

 9. 你遇到过有人说 “ 我以为 …” 么? ?

 要消灭 “ 我以为 ” 。

 Never assume anything 。

 10. 你们的项目组中所有的人都坐在一起么? ?

 需要。我反对 Virtual Team ,也反对 v Dev 在美国、 Test在中国这种开发方式。能坐在一起就最好坐在一起,好处多得不得了。

 11. 你们的进度表是否反映最新开发进展情况? ?

 应该反映。但是,应该用 e Baseline 的方法来管理进 度表:维护一份稳定的 Schedule ,再维护一份最新更改。e Baseline 的方法也应该用于其它的 Spec 。e Baseline 是变更管理里面的一个重要手段。

 12. 你们的工作量是先由每个人自己估算的么? ?

 每个人都应该做出自己的估计。自下而上估算工作量,而不是自上而下分配。除非有其他原因,比如固定期限的政治任务。

 13. 你们的开发人员从项目一开始就加班么? ?

 不要这样。不要一开始就和疲劳做斗争。从项目一开始就加班只能说明项目进度不合理。当然,有些软件外包到日本必须每天加班,这属于剥削的范畴。

 14. 你们的项目计划中 e Buffer Time 是加在每个小任务后面的么? ?

 不要。e Buffer Time 加在每个小任务后面,很容易轻易的就被消耗掉。e Buffer Time 要整段的加在一个 e Milestone 或者t checkpoint 前面。

 15. 值得再多花一些时间,从 95% 做到 100% 好

 值得,非常值得。尤其是项目后期人累的时候,更要坚持。这将使产品产生质的变化。

 16. 登记新缺陷时,是否写清了重现步骤? ?

 要。这属于 v Dev 和 和 t Test 之间的沟通手段。面对面沟通需要,详细填写 s Repro Steps 也需要。

 17. 写新代码前会把已知缺陷解决么? ?

 要。每个人的缺陷不能超过 0 10 个或 5 15 个,否则必须先解决老的 g bug 才能继续写新代码。

 18. 你们对缺陷的轻重缓急有事先的约定么? ?

 必须有定义。y Severity 要分 1 1 、2 2 、3 3 ,约定好:蓝屏和t Data Lost 算 算 Sev 1 ,r Function Error 算 算 Sev 2 ,界面上的算Sev 3 。但这种约定可以根据产品质量现状适当进行调整。

 19. 你们对意见不一的缺陷有三国会议么? ?

 必须要有。要有一个明确的决策过程。这类似于 CCB (Change Control Board) 的概念。

 20. 所有的缺陷都是由登记的人最后关闭的么? ?

 g Bug 应该由 r Opener 关闭。v Dev 不能私自关闭 Bug 。

 21. 你们的程序员厌恶修改老的代码么? ?

 厌恶是正常的。解决方法是组织 Code Review ,单独留出时间来。P XP 也是一个方法。

 22. 你们项目组有 y Team Morale Activity 么? ?

 每个月都要搞一次,吃饭、唱歌、 Outing 、打球、开卡丁车等等,一定要有。不要剩这些钱。

 23. 你们项目组有自己的 Loo go 么? ?

 要有自己的 Logo 。至少应该有自己的 Codename 。

 24. 你们的员工有印有公司 o Logo 的 的 T T- -t Shirt 么? ?

 要有。能增强归属感。当然,T T- -t Shirt 要做的好看一些,最好用 0 80 支的棉来做。别没穿几次就破破烂烂的。

 25. 总经理至少每月参加次项目组会议

 要的。要让 r team member 觉得高层关注这个项目。

 26. 你们是给每个 v Dev 开一个分支么? ?

 反对。h Branch 的管理以及 e Merge 的工作量太大,而且容易出错。

 27. 有人长期不 Check- -n In 代码么? ?

 不可以。对大部分项目来说,最多两三天就应该 Check- -In 。

 28. 在 在 Check- -n In 代码时都填写注释了么? ?

 要写的,至少一两句话,比如 “ 解决了 Bug No.225” 。如果往高处拔,这也算做 “ 配置审计 ” 的一部分。

 29. 有没有设定每天 Check- -n In 的最后期限? ?

 要的,要明确 Check- - In Deadline 。否则会 Build Break 。

 30. 你们能把所有源码一下子编译成安装文件吗? ?

 要的。这是每日编译 (Daily Build) 的基础。而且必须要能够做成自动的。

 31. 你们的项目组做每日编译么? ?

 当然要做。有三样东西是软件项目/ / 产品开发必备的:

 1. bug management; 2. source control; 3. daily build 。

 32. 你们公司有没有积累一个项目风险列表? ?

 要。

 Risk Inventory 。否则,下个项目开始的时候,又只能拍脑袋分析 k Risk 了。

 33. 设计越简单越好

 越简单越好。设计时候多一句话,将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫 scope management 。

 34. 尽量 利用现有的产品、技术、代码

 千万别什么东西都自己 Coding 。k BizTalk 和 和 Sharepoint就是最好的例子,有这两个作为基础,可以把起点提高很多。或者可以尽量多用现成的 l Control 之类的。或者尽量用XML ,而不是自己去 e Parse 一个文本文件; ; 尽量用 RegExp ,而不是自己从头操作字符串,等等等等。这就是 “ 软件复用 ”的体现。

 35. 你们会隔一段时间就停下来夯实代码么? ?

 要。最好一个月左右一次。传言去年年初 s Windows 组在b Stevb 的命令下停过一个月增强安全。

 Btw , “ 夯 ” 这个字念“ha ng” ,第一声。

 36. 你们的项目组每个人都写 t Daily Report 么? ?

 去写作。五分钟足够了。写大约 0 10 个句子,告诉你的小组我今天做了什么。一个是交流,一个是推自己( ( 我要是闲着一天就不好意思写了) ) 。

 37. 你们的项目经理会发出 t Weekly Report 么? ?

 是的。也是为了交流。包括目前的进度、可能存在的风险、质量状况、各项工作的进度等。

 38. 你们项目组是否至少每周全体开会一次? ?

 要。一定要开会。程序员讨厌开会,但每个礼拜开会时间加起来至少应该有 4 4 小时。包括 team meeting, spec

 review meeting, bug triage meeting 。千万别大家闷头写code 。

 39. 你们项目组的会议、讨论都有记录么? ?

 会前发 t meeting request 和 和 agenda ,会中有人负责主持和记录,会后有人负责发 meeting minutes ,这都是g effective meeting 的要点。而且,每个会议都要形成s agreements 和 和 action items 。

 40. 其他部门知道你们项目组在干什么么? ?

 要发一些 h Newsflash 给整 个大组织。

 Show your team’s value 。否则,当你坐在电梯里面,其他部门的人问:

 “ 你们在干嘛 ” ,你回答C “ABC 项目 ” 的时候,别人全然不知,那种感觉不太好。

 41. 通过 l Email 进行所有正式沟通

 l Email 的好处是免得抵赖。但也要避免矫枉过正,最好的方法是先用电话和当面说,然后 l Email 来确认。

 42. 为项目组建立多个 Mailing Group

 如果在 e AD+Exchange 里面,就建 Distribution List 。比如,我会建 ABC Project Core Team , ABC Project Dev Team , ABC Project All Testers , ABC Project Extended m Team 等等。这样发起 l Email 来方便,而且能让该收到 email的人都收到、不该收到不被骚扰。

 43. 每个人都知道哪里可以找到全部的文档么? ?

 应该每个人都知道。这叫做知识管理 (Knowledge Management) 。最方便的就是把文档放在一个集中的,更好的方法是用 Sharepoint 。

 44. 你做决定、做变化时,告诉大家原因了么? ?

 要告诉大家原因。r Empower team member 的手段之一是提供足够的 information ,这是 F MSF 一开篇的几个原则之一。的确如此,y tell me why 是人之常情,y tell me why 了才能有understanding 。中国人做事喜欢搞限制,限制信息,似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力,不在于是不是能 access information/data ,而在于是不是掌握资源。

 45. Stay agile and expect change

 要这样。需求一定会变的,已经写好的代码 一定会被要求修改的。做好心理准备,对 e change 不要抗拒,而是 expect change 。

 46. 你们有没有专职的软件测试人员? ?

 要有专职测试。如果人手不够,可以 peer test ,交换了测试。千万别自己测试自己的。

 47. 你们的测试有一份总的计划来规定做什么和怎么做么? ?

 这就是 Test Plan 。要不要做性能测试? ? 要不要做y Usability 测试? ? 什么时候开始测试性能? ? 测试通过的标准是什么? ? 用什么手段,自动的还是手动的? ? 这些问题需要用 Test n Plan 来回答。

 48. 你是先写 Tese t Case 然后再测试的么? ?

 应该如此。应该先设计再编程、先 e test case 再测试。当然,事情是灵活的。我有时候在做第一遍测试的同时补上test case 。至于先 e test case 再开发,我不喜欢,因为不习惯,太麻烦,至于别人推荐,那试试看也无妨。

 49. 你是否会为各种输入组合创建测试用例? ?

 不要,不要搞边界条件组合。当心组合爆炸。有很多e test case 工具能够自动生成各种边界条件的组合 —— 但要想清楚,你是否有时间去运行那么多 test case 。

 50. 你们的程序员能看到测试用例么? ?

 要。让 v Dev 看到 e Test Case 吧。我们都是为了同一个目的走到一起来的:提高质量。

 51. 你们是否随便抓一些人来做易用性测试? ?

 要这么做。自己看自己写的程序界面,怎么看都是顺眼的。这叫做审美疲劳 —— 臭的看久了也就不臭了,不方便的永久了也就习惯了。

 52. 你对自动测试的期望正确么? ?

 别期望太高。依我看,除了性能测试以外,还是暂时先忘掉 “ 自动测试 ” 吧,忘掉 r WinRunner 和 和 r LoadRunner 吧。对于国内的软件测试的现状来说,只能 “ 矫枉必须过正 ” 了。

 53. 你们的性能测试是等 所有功能都开发完才做的么? ?

 不能这样。性能测试不能被归到所谓的 “ 系统测试 ” 阶段。早测早改正,早死早升天。

 54. 你注意到测试中的杀虫剂效应了么? ?

 虫子有抗药性,g Bug 也有。发现的新 g Bug 越来越少是正常的。这时候,最好大家交换一下测试的 area ,或者用用看其他工具和手法,就又会发现一些新 g bug 了。

 55. 你们项目组中有人能说出产品的当前整体质量情况么? ?

 要有。当老板问起这个产品目前质量如何, Test r Lead/Manager 应该负责回答。

 56. 你们有单元测试么? ?

 单元测试要 有的。不过没有单元测试也不是不可以,我做过没有单元测试的项目,也做成功了 —— 可能是侥幸,可能是大家都是熟手的关系。还是那句话,软件工程是非常实践、非常工程、非常灵活的一套方法,某些方法在某些情况下会比另一些方法好,反之亦然。

 57. 你们的程序员是写完代码就扔过墙的么? ?

 大忌。写好一块程序以后,即便不做单元测试,也应该自己先跑一跑。虽然有了专门的测试人员,做开发的人也不可以一点测试都不做。微软还有 t Test Release Document 的说法,程序太烂的话,测试有权踢回去。

 58. 你们 的程序中所有的函数都有输入检查么? ?

 不要。虽然说做输入检查是 e write secure code 的要点,但不要做太多的输入检查,有些内部函数之间的参数传递就不必检查输入了,省点功夫。同样的道理,未必要给所有的函数都写注释。写一部分主要的就够了。

 59. 产品有统一的错误处理机制和报错界面么? ?

 要有。最好能有统一的 error message ,然后每个 error e message 都带一...

推荐访问:写出质量好软件75条方法和体会 质量好 写出 体会

相关推荐

2024年度深化城乡融合“十百千万”工程工作总结(全文) 在办公室干部座谈会上讲话稿 在全县招商引资大会上致辞(完整) 经验交流:“五个坚持”创新加强党建设(全文完整) 2024年度经验交流:打造品牌集群,提升党建工作质量【精选推荐】 2024年在“乡村振兴美丽家园”创建活动上经验发言材料 202X年区法学会建设调研报告【精选推荐】 X市经信工作总结和2024年思路(范文推荐) 2024年2024年全国“两会”测试100题(全文完整) 2024年度全文学习2024年安全生产治本攻坚三年行动 2024年度深化城乡融合“十百千万”工程工作总结(全文) 在办公室干部座谈会上讲话稿 在全县招商引资大会上致辞(完整) 经验交流:“五个坚持”创新加强党建设(全文完整) 2024年度经验交流:打造品牌集群,提升党建工作质量【精选推荐】 2024年在“乡村振兴美丽家园”创建活动上经验发言材料 202X年区法学会建设调研报告【精选推荐】 X市经信工作总结和2024年思路(范文推荐) 2024年2024年全国“两会”测试100题(全文完整) 2024年度全文学习2024年安全生产治本攻坚三年行动 写出自己熟悉人精神作文600字初一 世界读书日心得体会10篇 关于2022全国两会精神的心得和体会13篇 流调工作体会14篇 119消防日心得体会(完整文档) 2022全国两会精神体会交流14篇

热门文章

2022年度车间入职1周工作培训心得7篇

《车间入职1周工作培训心得7篇》是一篇好的范文,觉得应该跟大家分享,看完如果觉得有帮助请记得(CTRL+D)收藏本页。入职能让员工增强学习理论的自觉性与坚定性,增强的能力和信心。入职培训心得对经历过入职培训的人具有许多的影响,你知道它的写法?你是否在找正准备撰写“车间入职1周培训心得”,下面小编收集

2022年度校园安全党员个人心得体会范本6篇

本页是最新发布的《校园安全党员个人心得体会范文6篇》的详细范文参考文章,好的范文应该跟大家分享,重新整理了一下发到这里。每个应该采取有效措施,加强对的教育力度。你在安全教育中有写过校园安全心得?它会给你带来许多帮助。你是否在找正准备撰写“校园安全

邮政营销培训个人心得3篇

最近发表了一篇名为《邮政营销培训个人心得3篇》的范文,好的范文应该跟大家分享,希望对网友有用。销售要认真学习理论知识,做到学以致用、应才适用,促进绩效提升。营销培训对每一个销售人员具有重要的作用,快来写营销培训心得。你是否在找正准备撰写“营销培训心得”,下面小编收集了相关的素材,供大家写文

2022年度教师师德师风心得培训心得合集(全文完整)

最近发表了一篇名为《教师师德师风心得培训心得》的范文,感觉写的不错,希望对您有帮助,看完如果觉得有帮助请记得(CTRL+D)收藏本页。队伍师风素质的高低,直接关系到素质的顺利实施。在师德师风培训中你一定有许多的收获,你知道师德培训心得的写法?你是否在找正准备撰写“教师师德心得培训心得”

2022年增强********意识筑牢********防线心得体会最新合集

《2022增强********意识筑牢********防线心得体会最新》是一篇好的范文,觉得有用就收藏了,希望对网友有用。充分发挥基层阵地作用,以设置********法律咨询台、****宣传展板、印发宣传资料等方式开展形式多样的宣传教育活动,营造全民共筑安全屏障的浓厚氛围。下面小编在这里为大家精

2022年度做完劳动后心得体会范本7篇(精选文档)

最近发表了一篇名为《做完劳动后的心得体会范文7篇》的范文,觉得有用就收藏了,看完如果觉得有帮助请记得(CTRL+D)收藏本页。对接触、了解社会,增强社会适应能力有重要的作用。写一篇劳动心得能让自己在劳动实践过后的总结中得到许多的收获。你是否在找正准备撰写“做完劳动后的心得体会”,下面小编收

2022年防洪防汛安全培训个人心得体会合集【完整版】

《防洪防汛安全培训个人心得体会》是一篇好的范文,感觉写的不错,希望对您有帮助,重新编辑了一下发到。我们必须要树立高度的意识,人人讲安全,时时讲安全。安全心得对经历过安全培训的人具有许多的影响,你知道它的写法?你是否在找正准备撰写“防洪防汛安全培训心得体会”,下面小编收集了相关的素材,供

2022年建筑培训员工个人心得体会7篇(2022年)

最近发表了一篇名为《建筑培训员工个人心得体会7篇》的范文,觉得应该跟大家分享,为了方便大家的阅读。每一个都应该重视人才,培养人才,积极开展。写一篇员工培训心得能让自己在员工培训过后的总结中得到许多的收获。你是否在找正准备撰写“建筑培训员工心得体会”,下面小编收集了相关的素材,供大家写文参考

2022年爬山活动心得10篇

最近发表了一篇名为《爬山活动心得10篇》的范文,觉得有用就收藏了,看完如果觉得有帮助请记得(CTRL+D)收藏本页。的过程就像人的生活一样,做什么事情都要有恒心,要有勇气去挑战,只有毅力强的人,才能到达终点。下面是小编给大家整理的关于爬山活动心得,欢迎大家来阅读。爬山活动心得1今天晚上,我

疫情防控坚持动态清零总方针心得体会实用范本三篇(全文完整)

《2022疫情防控坚持动态清零总方针心得体会精选实用范文三篇》是一篇好的范文,觉得应该跟大家分享,希望对网友有用。2022坚持动态清零总方针心得体会精选实用范文三篇各基层党组织是贯彻党中央决策部署,保障制度执行到位的最后一公里,应稳扎稳打、实打实锤,视疫情为考场,在疫战中淬炼党建引领力,全面提升基层

2022年经典实训报告主题心得范本300字10篇

《经典的实训报告主题心得范文300字10篇》是一篇好的范文,觉得有用就收藏了,看完如果觉得有帮助请记得(CTRL+D)收藏本页。学习即是通过阅读、听讲、研究、观察、理解、探索、实验、实践等手段获得知识或技能的过程,是一种使个体可以得到持续变化的行为方式。下面是小编收集整理的经典的实训报告主题心得30

2022实训报告心得范本大全10篇

本页是最新发布的《实训报告心得范文大全10篇》的详细范文参考文章,感觉很有用处,希望大家能有所收获。学习即是通过阅读、听讲、研究、观察、理解、探索、实验、实践等手段获得或技能的过程,是一种使个体可以得到持续变化的行为方式。下面是小编收集整理的实训大全,大家一起来看看吧。实训报告心得大全1经