友情提示：如果本网页打开太慢或显示不完整，请尝试鼠标右键“刷新”本网页！
代码之道-第2部分
快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！
曳炊裕裨蛘饩褪亲钚虏赡傻墓娣妒椤！比缓螅惆颜夥鈋…mail发给最直接受这个变更影响的项目经理、开发、测试和实施人员。几天之后，当你根据他们的建议做完了必要的修改，你就可以把你的SCR发给团队中剩下的所有人，并且把它放到RAID中或者一个公共目录中，跟其他SCR一起跟踪。
译者注：关于RAID，参见本书最后的“术语表”。
这里的关键是，规范书的变更现在文档化了，并且得到了相关人员的复审，而且不会阻碍工作的进展。反对几乎总是例外，不会有很多。开发人员在任何时候都可以继续工作，这里只是一个权衡问题——动手做之前花更多的时间等待是否有反对，或者冒着后来被反对的风险马上就动手做。典型情况下，开发人员会一直等待，直到SCR经过了初始的几次修改后发给团队全体成员的时候才动手做。
预防是最好的治疗
当然，最理想的是规范书从一开始就不会迟到，至少你不能被它蒙蔽。这里就用得着T…I…M…E图表了。在T…I…M…E图表中，第一份规范书展示了对整个项目的设计。它不是简单的需求文档，也不是数个小型规范书的集合，而是项目的一个高级规范书，很像是开发主管写的那种高级架构文档。这个规范书应该展示项目将具有的功能和用户界面，以及它们怎样在一起协作，而把细节留给以后的规范书。所有后来的规范书和功能都必须参考这个高级规范书。
这样的话，开发、测试和实施人员就可以制定计划去说明未来所有的功能了。他们能够生产出集成得更好的产品，使用户体验更加流畅。项目经理也可以使用第一份规范书去安排剩下的其他规范书，先做优先级高的，而不必担心遗漏什么东西或者做出让别人吃惊的事情来。这种理想终究使T…I…M…E产生了（难以抗拒）。
作者注：T…I…M…E（Totally Inclusive Mutually Exclusive）图表是由Donald Wood首先提出的，但它从未像我的同事Rick Andrews最初预期的那样流行过。然而，微软现在的价值主张、远景文档、跨产品案例和仔细设计的原型都能达到同样的目的。
电子书 分享网站
宝宝做了件极坏的事情（1）
2002年6月1日：“闲置人手”
你的开发团队两周前达到了“零Bug反弹”（ZBB，Zero Bug Bounce）， 你突然意识到，你又迎来了一个“工作淡季”。任何从事零售软件产品开发、并且碰到过零Bug反弹的开发人员都知道这个“工作淡季”。但如果你的团队是提供互联网服务的，你现在可以停止阅读了。（等一下，你一开始读本栏目的时间哪来的？回去干活！）
作者注：零Bug反弹（ZBB，Zero Bug Bounce）描述了第一次出现项目中的所有功能都完成了、并且所有工作条款都解决了的那个时刻。这个时刻很少会长时间持续。通过进一步的系统测试，通常在1小时之内就会有新的问题暴露出来，随后团队又必须埋头去工作。尽管如此，零Bug反弹意味着项目在可预见的将来就要结束了。
零Bug反弹标志着项目状态从“瓶颈在开发方”到“瓶颈在测试方”的转变（“瓶颈在项目经理”没有类似的这种转变）。在处理完产品出货后最初几周内的一批新发现的Bug之后，大部分开发团队进入了“时而加速，时而等待”的模式——当有新Bug分配过来的时候奋力去解决它，否则就闲着不知道该做什么了。
最可怕的是，“工作淡季”有时候可能从零Bug反弹开始，一直持续到下一个版本产品的第一个里程碑。这在大项目中可能有几个月之多！开发经理手上总是忙着各种各样的事情，因而很容易就会忽略，其实三分之二的团队成员都闲在那里。你知道他们怎么说闲置人手的——嗯，不是很好听！
以下是闲置的开发人员经常做的一些坏事：
？ 抢修Bug。零Bug反弹之后，你的团队应该处于“禁闭”状态，这意味着，所有Bug在被修复之前都要通过分诊会议的慎重考量。闲置的开发人员有时坐在他们的位置上，敲击RAID（现在叫Product Studio）上的F5功能键等待Bug的出现。如果通过这种方式没有发现Bug，他们就会把视线转到正在被分诊讨论的那些Bug上，挑一个有趣一点的，然后开始研究它。在你知道之前，他们可能已经有了一个修复方案，并且正伺机悄悄地把代码签入进去呢……这就是抢修Bug！一个有自尊的开发者不应该做这样的事情。
作者注：在软件工程中，Bug通常是指代码中的错误。然而，微软内部使用“Bug”这个词泛指跟产品相关的所有增加、删除或者修改。但大家对外一般称这些为“工作条款”，其中有一些也可能是代码错误。我更喜欢“工作条款”的说法，这样就能把那些真正的Bug区分出来。
谁知道分诊团队是否会决定修复那个Bug呢？谁知道那个Bug是否被正确地修复了，并且也不会引起相关的另一个更大的或者小一点的Bug呢？对于潜在的重大问题投入一点调研是可以的，但绝对不要抢先去修复！
？ 修复尚未报出来的Bug。现在有一个Bug通过了分诊，你正在进行修复。这时你注意到，在你修改的代码附近有其他更多的Bug（通常这些Bug是由以前的修复引起的）。但不知怎么搞的，这些Bug还没有被人报出来。你看到了这些代码，而其中的错误也尽收你眼底。为什么不一起把它们都修复了呢？喂！就此打住！！！
开发团队通过代码复审来避免这种可怕的事情。在“可信计算”时代，团队应该在整个项目周期内复审每一次代码签入。当团队处于“禁闭”状态时，要保证有3双眼睛（即代码改动者本人和另外两个开发者）同时审查每一次的代码改动。至于开发人员在修复一个Bug时发现的其他Bug，则要通过如下方式来跟踪：先把它报出来、登记到Bug数据库中，然后再分诊……
作者注：《凯文与霍布斯》连环漫画系列中有这么一个故事：凯文对一只苍蝇慈悲为怀，打开前门让它飞出去。结果呢？这只苍蝇非但没有飞出去，反而另外3只苍蝇飞了进来。这就是为什么你必须在项目逼近尾声时，要对每一个Bug进行研究和分诊的原因了。我的团队曾经在我们的产品发布前一个月的时候改变了一个参数的值，结果一周之后，全公司的测试人员都发现：只要打开CD托盘，所有的应用程序都会停止响应。最后，我们往回追踪到那个看起来无关紧要的参数，并把那个改动撤销了才解决问题。这种事情真实地发生在我们的周围，只是你未必知道而已。 。。
宝宝做了件极坏的事情（2）
？ 修复标为“延期”的Bug。大家知道，被标为“延期”的Bug在产品发布给制造商（RTM，Release To Manufacturing）之前是不能去修复的。那么，是不是应该在计划下一版产品的时候去修复它们呢？不对！当初在项目的进行过程中，产品的相关团队对“哪些Bug对我们的客户影响最大，因此必须在发布之前修复”作了判断，但这种判断在产品没有真正发布之前是无法验证的。当产品发布之后，你就没必要再去猜了。“产品支持服务”（PSS，Product Support Services）、Watson和“微软咨询服务”（MCS，Microsoft Consulting Services）会告诉你的，而且它们非常坦诚。那些标为“延期”的Bug只具有参考价值，用于理解为什么这些Bug当初没有要求去修复。注意，你不要再一次去猜测已经真实存在的客户。你要做的是，关注用户反馈，修复真正影响用户的那些Bug。
？ 重写“丑陋”的代码。开发人员讨厌“丑陋”的代码。这些代码常常麻烦不断，可读性差，难以维护。因此，当开发人员手头有空的时候，他们经常自言自语：“哈，我手头没有规范书，因此不能开发新的东西。我为什么不趁此机会重写那些讨厌的丑陋代码呢？”他们知道，如果给第二次机会的话，他们能够做得更好。他们也的确可以做到。他们可以在第二次的时候，重写出漂亮得多、清晰得多的代码，而且比第一次写的时候少了很多Bug。
令人遗憾的是，重写的代码实际上将比当前的丑陋代码带来更多的Bug。因为当前的丑陋代码是在第一次编写的基础上，经过了几个月甚至是几年的测试和修复之后才达到的质量水准。
有时候重写是必要的。重写可以提高代码的性能、扩展性、可靠性、安全性、或者对于新技术的适应能力。在这些情况下，应该把重写当作一个功能来对待；像处理其他功能一样，写一份规范书，然后为它制定时间表。否则，不要做代码重写这种愚蠢的事情，它只会重新引入一大堆令人讨厌的Bug，而且还对客户价值没有丝毫的贡献。
作者注：我的上述观点同样适用于“重构”（Refactoring），尽管我很讨厌提到它。哪怕重构是在你毫无察觉的情况下由电脑自动完成的。这并不是说你不应该进行定期的代码重构或复审，而是说，你不应该随意地做这些事情。做不做都应该由团队来做决定，并且要保证手头有足够的“单元测试”来防止引入大量的新Bug。如何正确地做这些事情才是关键。
？ 在编码风格上争论不休。谈到最消耗开发团队时间的事情，在空格、括号、匈牙利命名法等问题上的争论必定在前5名之列。请记住：使用一种一致的编码风格对你代码库的质量和可维护性大有裨益，而你的团队具体使用哪种风格一点都不重要。你是开发经理，你来选一个并坚持使用它。谁说这也需要民主？！
txt小说上传分享
告诉我该做什么
关于闲散时间的阴暗面我已经说得够多的了。在这个清静时期，你的开发团队可以做些什么有建设性的事情呢？
很自然，测试团队会坚持说，在产品发布给制造商之前的这段时间里，开发人员应该帮着找Bug。而项目管理团队会坚持说，在产品发布给制造商之后，开发人员应该花时间去阅读和复审规范书。不过，这些事情对开发团队来说没有太多实际的工作量、不具有吸引力、也无法让他们开心。
那么，开发人员在“工作淡季”到底可以做些什么呢？下面是我的一些想法：
？ 分析Bug。分析团队在过去的一个产品开发周期中修复过的所有Bug，找出其中的规律。哪些是个人常犯的错误？哪些是团队犯的错误？团队中的每个成员下次需要注意点什么，才能开发出更好的产品？
？ 为部门开发一些工具。尽管开发人员通常不擅长发现Bug，但他们在开发用于帮助发现Bug的工具方面的能力却是超强的。他们还能开发一些工具用于使过程更加顺畅，比如源代码签入、安装、建造和支持。给源代码插桩或者开发一个好的测试用具，能够大大地促进开发与测试团队之间的关系。当然，你应该先到工具箱网站上去查一查，看看满足你需要的工具是否早已存在了。
？ 讨好项目经理，把他们的设计思想变成原型程序。开发原型程序是个好主意，只是不要在常规代码库上去做。尝试用另一种语言来写，或者至少要有独立的建造。在常规代码库上开发原型程序的最大问题是，项目经理和高层管理者会很自然地认为，代码已经到了差不多可以发布的程度，而事实上，原型程序通常存在着本地化、平台依赖、徽标、漫游、性能、安全、兼容性等各种各样的问题。混淆原型程序和产品代码会把产品计划和期望搞得一团糟。相反，用另一种语言来开发原型程序却是一个极好的学习机会。再说还能……
作者注：虽然以前已经说过了，但我还要再强调一下，“不要把原型程序当作产品来发布。”这么做不会节省时间，而只会花更多的时间。千万不要这么做！原型程序是用于学习和沟通的，它的用途就是这么单纯。除了用另一种语言开发原型程序外，我以前常常把Esc按键处理为异常结束。这样的话，如果我的上司在观看演示时表现得异常兴奋，我会敲一下Esc键，让程序崩溃，然后解释说，“很显然，我们的程序还没到发布的时候。”
？ 学习新技术或技能。人们总是抱怨他们没有足够的时间去学习新技术或技能，抱怨得不到培训机会使他们自身得到提高。好吧，为什么不好好利用项目的这个清静时期呢？不要让机会在你身边溜过！
？ 跟研究人员交谈。在零Bug反弹之后是跟研究团队交谈的最好时机。这时候你有足够的时间去采用某个新技术，花时间去学习它，并且了解你能用到哪些东西。到你的产品发布、并且开始计划下一个版本的时候，你可能已经把原型程序准备好了，并且解决了所有的风险，着实让你的团队惊喜不已。另外，你和研究人员也可以为未来的产品策划新的研究领域。这非常有价值，而且做起来很容易。
？ 撰写专利申明或白皮书。其他还有更好的时间，用来反思和记录你已经做过的事情吗？如果你团队中的一位开发人员在项目过程中想出了一个新颖的点子，产品因此增加了不错甚至是重大的价值，那么务必叫他撰写一个专利申明。这做起来很容易，很快，还能极大地鼓舞士气。请访问专利组织的网站，以便了解更多的细节。如果你想把一些信息文档化，或者与其他团队分享某个想法，那就写一个白皮书。相对来说，这做起来也很容易，但能给作者和你的团队带来尊敬和影响力。
？ 反思职业生涯。最后但并非最不重要的一点，项目的这个清静时期是你审视职业生涯现状的最理想时机。你现在处在你理想中的位置吗？你的职业生涯在向正确的方向前进吗？你准备好迎接新的挑战了吗？你需要做些什么，以使自己忙碌并并能富有激情？如果通过上述反思，你觉得必须改变一下，那么，越早采取行动越好。
俭则不匮
差不多已经司空见惯了：产品的两个版本之间的时间被不必要地浪费了。而实际在这段时间内做的事情常常还是有害的。其实，只需要一点点的想法和思考，你的开发团队就可以在不带来任何伤害的前提下，提高他们自身的能力，提高产品，提高他们的见解，乃至提高整个组织的效力。为你的“停工期”好好计划一下吧，开足马力勇往直前！
txt电子书分享平台
为什么我们会在这里？
2004年6月1日：“我们开会的时候”
别浪费我的时间。拜托，请你不要浪费我的时间。也许我翻过桌子去用胶带封住你的嘴，我才能避免眼睁睁地看着你浪费我生命中宝贵的60分钟。召集一次会议怎么能给人以权利去浪费别人的生命？如果时间是金钱的话，大部分会议都是不景气的市场。我很厌烦那些可以把车快速开下悬崖、却开不好一个会议的人。
我不想再参加这种会议了。如果你逼着我去一个会议室，请为我准备好，因为我会质问你想上演的任何“绝技”。你浪费我的时间，那我也要让你的时间像火把一样燃烧。不喜欢这样吗？别考验我！我会质问你什么呢？听好了，因为下面就是……
我用来打断你的自助式“聚会”的第一个问题是，“为什么我们会在这里？”我们聚在一起到底想干什么？有理由吗？如果你没有让所有人清楚这个理由，大家可能会各有所想，并且像狗一样追着自己的尾巴，结果自然是一无所获。我不知道——也许你应该预先发一个议程，或者一些我们将要讨论的文档？拜托你做点什么！
如果你把会议的主旨作了通告，我可能还会提醒你，一定要坚持这个主旨！我不关心是否还有另外50个会议，去做另外的50个决定、讨论另外的50个话题或者更多的信息共享。我现在参加这个会议，我就只想专注于这个会议。如果有人想要谈论其他的什么事情，让他在我们结束之后再上演他自己的秀吧！
作者注：如果有人试图转移话题，你该如何不失礼貌地打断他呢？我喜欢的方法是，对他说：“让我们先把这个话题讨论完，然后再谈你的话题。”通常情况下，当你结束了第一个话题之后，所有人都想离开了。那个会议干扰者将不得不另外安排一个会议，并且邀请合适的人参加（这样要好得多）。如果那个干扰者坚持认为应该先讨论他的话题，那么首先讨论他要这么做的理由（这时候会议实际上仍然聚焦在原先的话题上）。如果理由很充分，那么是你的会议时机还不成熟，因而是你的会议需要另行安排。在这种情况下，没人会介意离开当前的这个会议。
我们正在试图做什么？
接下去，我的问题是，“我们正在试图做什么？”
？ 我们是在试图做出一个决定吗？很好，就让我们做个决定，其他的像头脑风暴、状态检查、流言澄清等统统跳过。
？ 我们是在试图共享信息吗（比如一个状态汇报会议）？很好，把信息列表上的内容过一遍，但不要试图去做什么决定或者解决什么问题。
？ 我们是在试图收集想法吗？很好，捕捉每个人的想法，无论它们有多荒诞都不要作出批评或论断。最后，挑出其中最好的一个即可作为会议的成果了。
这里的要点是，混合会议是低效的，常常会徒劳无功。大家都知道了为什么会聚到一起来，也知道了会议正在试图达成什么目标。如果你必须中途改变这些前提，那你要深思熟虑之后，让每个人都意识到，现在规则已经变了。否则，你会浪费所有与会者的时间，永无止境地纠缠不清，最后还不得不重新召开会议。如果你要这么做，麻烦你不要邀请我。我不会参加的！
作者注：有个典型案例，就是在Scrum会议上提出设计问题来讨论。Scrum会议是用于共享信息的，不是用于收集想法或做决定的。没什么像设计讨论一样，不经意间就能让Scrum会议脱离轨道。然而，因为设计讨论是很值得做的，我们在Scrum会议上会把讨论的话题在白板上列出一个清单。等Scrum会议结束之后，那些想讨论这些话题的人可以留下来，参与接下去的设计会议。
为什么他们会在这里？
很好，我们已经知道了开会的理由，也知道了我们正在做什么。现在的问题是，为什么他们会在这里？我指那些不该在这里的人。这些人在问一些多余的问题，他们只是在重复别人的观点，他们只需在必要的时候表示一下同意。那么，为什么这些人会在这里呢？
会议的持续时间跟参加会议的人数是直接成比例的，说不定它们的关系还是线性的。你应该只邀请那些必须出现在会议上的人。
？ 试图做一个决定？邀请可以做决定的人。其他所有人都可以在会议之后、通过e…mail了解到会议的情况。不是所有必要的、需要做决定的人都能参加吗？那就取消会议。立即取消！否则，你将不得不在所有人都能参加的时候重新召###议。
？ 状态汇报会议？邀请那些将要汇报状态的人。其他所有人都可以在会议之后、通过e…mail了解到会议的情况。有一些需要汇报状态的人不能参加吗？我猜他们肯定是懒鬼。
？ 头脑风暴会议？邀请一些有创意的、思想开明的人，他们是会议成功的关键。其他所有人都可以在会议之后、通过e…mail了解到会议的情况。
有时候，你必须邀请一些其他人来参加会议，他们对会议是否成功起着至关重要的作用，比如主持人、协调员、啦啦队队长等。但也就这些人了。如果太多其他人登记要参加会议的话，你最好取消会议。（你可以预先判断出将有多少人参加会议，因为当有人接受一个转发的会议邀请时，你会收到一个确认信息。）
尽量预定一个小型会议室，这样可以把一些不速之客排除在外。尽量把会议安排在30分钟内结束，这样可以让大家准时出席并且保持会议过程的高效进行。你可以声称这是一个“工作会议”，必要的时候甚至可以使用“信息权管理”（IRM，Information Rights Management），以阻止会议邀请信被转发。
为什么我现在才听到这个？
对于一些重要的主题，你不想让关键的相关人员吃惊。没人喜欢匆匆忙忙地被拉去做至关重要的决定，也没人希望对关键领域发生的事情丝毫不知。如果你想要会议开起来比较顺畅，那么预先跟关键人员做个沟通。你们可以发现问题，协商折衷方案，预先让所有人都取得一定的共识。接下去，会议更多地只是一个形式了。对于要做决定的会议来说，这是个好方法，只是它比较费时。但对于一些至关重要的决定，这也是至关重要的一步。
书包 网 。 想看书来
接下去要做什么？
现在会议开完了，结束了，一切都过去了，对吗？错了！会议像好莱坞恐怖电影中的鬼怪蛇神一样，它们会重新获得生命，然后吃掉剩下的那些人。决定接下去要做什么，把它们写到e…mail中去。这样才能使已经结束的会议不会死灰复燃。
写e…mail的时候，把所有与会者的名字放在地址栏中，并且抄送所有受会议结果影响的人。务必要包含一个对会议所做的决定、共享的信息或者收集到的想法的简短总结。然后列出接下去的安排，指明谁在什么时候做什么事情。此刻，你终于可以放心地继续前进了。
看到了吧，尊重别人的时间并没有那么难！会议在很多方面是昂贵的。当然，会议对于加强组织的沟通也是必要的。但如果你要开会，那就把会开好。所有人都会赏识它，你也能完成更多的事情。
书包 网 。 想看书来
你失去理智了吗？
2006年7月1日：“停止写规范书，跟功能小组呆在一起”
我不是项目经理（PM，Program Manager）。我也从来没有担任过项目经理。我将来也不可能成为一名项目经理。这并不是我个人对项目经理的抵触。因为我的朋友之中不乏有出色的项目经理。很显然，我没有权利去教导项目经理怎么去做他们的工作。
尽管如此，项目经理应该停止写规范书。就这么简单！他们在浪费我的时间，浪费组织的时间，浪费整个公司的时间。你几乎可以听到残留着的、细微的、嘎扎嘎扎的声音，因为规范书像白蚁一样在一口一口咬掉公司和客户的价值。我对此深恶痛绝！
其实不仅仅是项目经理。开发者也必须停止写开发规范书。测试者则必须停止写测试规范书。疯狂必须停止！浪费必须停止！我们必须重新找到我们的感觉，找回我们的生产力，还有我们的智慧。
作者注：如果用回应数来考量，本栏目肯定是我发表过的最有争议的栏目之一。你也可以从接下去的那段文字看出，我当初就猜到了这一点。关于我的观点，大家最大的误解是在“正式文档”和“非正式文档”的区别上面。我认为，多工种呆在一起工作的团队只需要非正式的文档，比如把白板上的内容拍了照片放到维基网站上，并加上少许的注释。而被距离隔开或按照工种划开的团队则需要正式的文档，比如具体的规范书。
“你肯定不是认真的？”我听到忠实的读者这么说，“你多年来一直鼓吹质量（参见第5章的“牛肉在哪里”栏目）和设计（参见第6章的“通过设计解决”栏目）。你告诫开发人员在他们拿到规范书之前不要采取行动，在没有彻底理解设计之前不要开始编码。莫非现在你承认以前是被误导了，或者甚至可能你本身的认识就是错误的？”不，当然不是。
功能团队在开发用户体验之前必须首先理解它，开发人员在实现一个内部设计之前也必须首先充分理解它，这样才能面对面地解释给同伴听。但是，这些步骤中没有哪个需要正式书写的文档。
为什么我们需要正式书写的规范书呢？客户不需要它们。市场和产品规划部门也不需要它们。即便是内容发布者和产品支持人员，他们对规范书的使用也是有限的。因此，谁需要这些荒唐无用的“杰作”呢？为了找到答案，我们不妨把规范书扔掉，看看谁会叫起来。
在那里进退两难
如果我们不再有规范书，开发和测试人员会大叫，“我怎么知道代码应该实现什么功能呀？”告诉他们找项目经理讨论去。然后他们接着抱怨，“项目经理又不会整天在我的办公室里转悠。我需要记录下来的规范书。我必须对它们进行复审、修改和更新。”
是的，这里的确有问题。不是开发和测试人员必须有规范书来复审、修改和更新，而是项目经理没有整天留在附近，一起来讨论用户体验、实现和测试策略。好吧，那如果项目经理这么做了又怎样呢？
如果项目经理跟开发和测试人员整天呆在同一个开放区域里，并且周围摆满了白板，一起为同一个功能集合努力工作，又会怎么样呢？我们还需要正式书写的规范书吗？等等，我听到了更多的尖叫声。
特殊要求
如果没有正式书写的规范书，依赖这些功能的其他团队将会抗议，“如果我们不知道你的代码是怎么工作的，我们怎么知道如何去使用它呀？”这问题问得很好。如果项目经理整天跟功能团队呆在一起，他们也就不可能有时间去应对所有的下游团队，而我们也不可能把所有人都塞到同一间房间里去。然而，下游团队其实不需要规范书——他们需要的是一个小型的软件开发包。不管怎么样，组件团队都得提供软件开发包的，这么做非常有价值。
如果没有正式书写的规范书，“合规警察”（pliance Police）将会咆哮，“的文档在哪里？”这问题问得也不错。合规警察让我们远离伤害。尽管他们的工作不怎么讨好，但却非常重要。他们常常需要正式书写的文档来完成他们的工作。然而，合规警察同样也不需要规范书。他们需要的是完整的合规文档，跟规范书相比，它常常以不同的形式包含不同的信息。
作者注：这些“合规警察”是谁？他们其实是普通的工程师，只不过他们的工作重点是，确保微软的产品在关键领域的正确性，比如安全、隐私、全球可用（没有不合适的委婉语或引用）和顺从所有适用的法律和法规等等。举例来说，他们要求的典型文档包括：威胁模型（安全方面的）、隐私声明、专利权使用条款等。
在上述两种情况下，你都不需要正式书写的规范书。你需要的是其他类型的特定文档，而这种文档会比较容易写，因为它不是可自由发挥的。
txt电子书分享平台
我不记得了
那么我们还需要正式书写的规范书吗？我“不记得”�
快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部!
温馨提示： 温看小说的同时发表评论，说出自己的看法和其它小伙伴们分享也不错哦！发表书评还可以获得积分和经验奖励，认真写原创书评 被采纳为精评可以获得大量金币、积分和经验奖励哦！