当前位置：首页 > news >正文

个人网站怎么做联盟推广微信与网站对接

news 2025/11/17 5:30:12

个人网站怎么做联盟推广,微信与网站对接,西双版纳傣族自治州属于哪里,智慧团建网站登录平台官网ISBN: 978-7-121-41997-3 作者#xff1a;【美】Alan M. Davis 译者#xff1a;叶王、马学翔、吴斌、王冰清审定#xff1a;章淼页数#xff1a;344页阅读时间#xff1a;2023-09-24 推荐指数#xff1a;★★★★★ 这本书可以说是集开发之大成者了#xff0c; 如果你… ISBN: 978-7-121-41997-3 作者【美】Alan M. Davis 译者叶王、马学翔、吴斌、王冰清审定章淼页数344页阅读时间2023-09-24 推荐指数★★★★★ 这本书可以说是集开发之大成者了如果你是开发或者管理人员没有看过这本书我觉得你还没到火候。这些基本上都是上世纪七十、八十、九十年代总结出来的原则这些都是经得起时间考验的虽然有些因为时代的原因都过时了但是还有很多宝贵的经验留存了下来十分建议阅读回味。这里是软件工程生命周期中的需求、设计、编码、测试、维护的全面覆盖。软件质量的三要素人、过程、工具。现在工具链成为了软件工程的管理核心了。原则1质量第一质量必须量化、建立落地实施机制。原则2质量在每个人眼中都不同确定优先级并清晰的传递给每个相关方。原则3开发效率和质量密不可分试图提高开发效率时bug密度就会增加。原则4高质量软件是可以实现的让客户参与做原型设计并保持简单。原则5不要试图通过改进软件实现高质量质量无法从软件的改进获得。原则6低可靠性比低效率更糟糕低可靠性问题不仅难以发现而且难以修复。原则7尽早把产品交给用户使用原型法原则8与客户、用户沟通解决真正需求的唯一方法就是去和真正有需求的人沟通。原则9促使开发者与客户的目标一致原则10做好抛弃的准备原则11开发正确的原型一次性原型和演进式原则12构建合适功能的原型原则13要快速地开发一次性原型原则14渐进地扩展系统是降低软件开发风险的最有效方法之一。原则15看到越多需要越多一旦用户看到产品他们就会想要更多的东西。原则16开发过程中的变化是不可避免的原则17只要可能购买而非开发原则18让软件只需简短的用户手册衡量软件系统质量的一种方法是查看其用户手册内容的多少。原则19每个复杂问题都有一个解决方案这是错误的。原则20记录你的假设即使很荒谬也要记录原则21不同的阶段使用不同的语言原则22技术优先于工具自动化之前先手工验证。原则23使用工具但要务实原则24把工具交给优秀的工程师原则25CASE工具是昂贵的现在大部分工具都免费了原则26“知道何时”和“知道如何”同样重要一个优秀的工程师需要了解很多不同种类的技术知道每种技术适合那部分。原则27实现目标就停止需要对整个软件过程都熟悉原则28了解形式化方法先用自然语言描述然后再用形式化方法描述。自然语言打电话给小吴。形式化语言开机、点击打电话、输入手机号、点击拨打。原则29和组织荣辱与共产品中的缺陷是公司的耻辱软件工程师引起的公司耻辱是工程师的耻辱。当任何人发现你在产品中犯的错误时应该心存感激而不是试图辩解。帮助其他工程师避免同样的错误对后续的错误修正也可以不那么抵触。原则30跟风要小心原则31不要忽视技术软件工程技术日新月异原则32使用文档标准原则33文档要有术语表原则34软件文档都要有索引原则35对相同的概念用相同的名字原则36研究再转化不可行研究者更愿意在越来越多的无实际意义的问题上演示他们的想法。原则37要承担责任不要有任何借口。如果你是一个系统的开发者把它做好是你的责任。要承担这个责任。要么做好要么就压根不做。原则38低质量的需求分析导致低质量的成本估算原则39先确定问题再写需求原则40立即确定需求原则41立即修复需求规格说明中的错误要在需求分析阶段修复错误原则42原型可降低选择用户界面的风险可以给用户提供一个真实系统的印象原则43记录需求为什么被引入原则44确定子集原则45评审需求原则46避免在需求分析时进行系统设计需求阶段的目标是明确系统的外部行为。原则47使用正确的方法没有任何一种需求分析方法适合所有软件。原则48使用多角度的需求视图原则49合理地组织需求原则50给需求排列优先级原则51书写要简洁原则52给每个需求单独编号原则53减少需求中的歧义自然语言存在固有的歧义问题。原则54对自然语言辅助增强而非替换原则55在更形式化的模型前先写自然语言原则56保持需求规格说明的可读性用户、客户、市场营销人员、需求作者、设计师、测试人员、管理人员等都需要清楚需求文档。原则57明确规定可靠性原则58应明确环境超出预期时的系统行为原则59自毁的待定项到何时为止由谁处理这个待定项。原则60将需求保存到数据库需求是复杂和非常不稳定的。原则61从需求到设计的转换并不容易设计的最终产出是设计规格说明。设计的第一步是综合形成一个理想的软件架构。从外部视角到内部最优设计的转换从根本上说是一个难题。原则62将设计追溯至需求当选择软件架构时重要的是所有需求都能被覆盖。原则63评估备选方案详细列出多种方法在这些方法之间权衡分析并最终采用一种。原则64没有文档的设计不是设计我已经完成了你新家的设计剩下的工作就是把它画出来。我已经完成了这不小说剩下的工作就是把它写下来。原则65封装信息隐藏是一个简单且经过验证的概念它使软件更容易测试和维护。原则66不要重复造轮子复用而不是工程。原则67保持简单构建软件设计有两种方法。一种方法是使它简单到明显没有缺陷。另一种方法是使它复杂到没有明显的缺陷。 KISS原则。原则68避免大量的特殊案例如果你发现有太多的特殊案例那么你可能设计了一个不合适的算法。原则69缩小智力距离不同的人在审视同一个现实世界时往往会感知到不同的结构。原则70将设计置于知识控制之下如果设计是以能使其创建者和维护者完全理解的方式创建和记录的那么这个设计就是在知识可控范围内的。原则71保持概念一致概念一致是高质量设计的一个特点。当设计完成后设计应该看起来是一个人做的。原则72概念性错误比语法错误更严重不管你有多优秀都会犯概念性错误。需求阶段这是客户想要的吗设计阶段这个架构在压力下可以正常工作吗这个算法真的适用于各种场景吗编码阶段这段代码的执行和我想的一样吗是否实现了这个算法测试阶段执行这段测试让我确信什么原则73使用耦合和内聚高内聚低耦合原则74为变化而设计模块化、可移植性、可塑性、保证最小智力距离、在智力可控范围内。原则75为维护而设计对于非软件产品设计后的最大成本风险是制造。对于软件产品设计后的最大成本风险是维护。原则76为防备出现错误而设计不引入错误、尽可能预想不可能的情况并制定恢复策略。原则77在软件中植入通用性一个软件组件的通用性体现在它在不同的场景下不做任何修改就能执行预期功能。原则78在软件中植入灵活性一个软件组件的灵活性体现在他很容易被修改以在不同的场景下执行其功能。原则79使用高效的算法了解算法复杂度理论是成为一名优秀设计者的必要前提。原则80模块规格说明只提供用户需要的所有信息设计过程中的一个关键部分是对系统中每个软件组件的精确定义。原则81设计是多维的打包方案、依赖层次、调用关系、进程组织原则82优秀的设计出自优秀的设计师优秀的设计是简洁、简单、优雅、快速、可维护、易于实现原则83理解你的应用场景无论需求文档写得多好架构和算法的最优选择都应主要基于对应用场景特质的理解。原则84无须太多投资即可实现复用复用软件组件最有效的方法是从一个包含精心制作和挑选的组件的代码库开始这些组件是专门为重用而定制的。原则85“错进错出”是不正确的如果用户提供了非法的输入数据程序应该返回一个好理解的提示理解为什么这个输入是非法的。原则86软件可靠性可以通过冗余来实现并行方式、冷备方式。软件的超高可靠性是非常昂贵的。原则87避免使用特殊技巧程序员都非常聪明他们想展示这种聪明。底线避免编写使用特殊技巧的代码以向世界展示你有多聪明。原则88避免使用全局变量全局意味着任何人都可能错误地修改它的值。原则89编写可自上而下阅读的程序原则90避免副作用副作用是软件中许多细微错误的来源原则91使用有意义的命名优秀的程序员应该只花很少比例的时间敲代码10~15%的时间大部分时间应该花在思考上。原则92程序首先是写给人看的现在最有价值的资源是人力开发软件的人力、维护软件的人力和提高软件能力的人力。原则93使用最优的数据结构如果你选择了正确的数据结构算法将变得易于编写、阅读以及维护。原则94先确保正确再提升性能提供正常运行程序的性能比“让高性能程序正常运行”容易很多。原则95在写完代码之前写注释在写代码的同时写注释这会让你更容易调试软件。原则96先写文档后写代码一些读者对这个原则或许会感到奇怪但当实践一段时间之后你会认为这个原则是理所当然。原则97手动运行每个组件手动执行一些简单的测试用例原则98代码审查 Code Review 原则99你可以使用非结构化的语言原则100结构化的代码未必是好的代码一个人可以写出异常晦涩的程序虽然它是结构化的。对高质量的程序结构几乎是必要条件但远不是充分条件。原则101不要嵌套太深嵌套超过三层就会严重降低可理解性。原则102使用合适的语言特定项目或产品的目标通常会指定合适的语言。原则103编程语言不是借口如果你是一个好的程序员对任何一种编程语言来说你都应该是一个好程序员。原则104编程语言的知识没那么重要不管使用哪种语言优秀的程序员都是优秀的。不管使用哪种语言糟糕的程序员仍然是糟糕的。一个真正优秀的程序员应该可以很容易地学会一种新语言。这是因为一个真正优秀的程序员很好地理解和赞赏高质量编程的概念而不只是了解某些编程语言的语法和语义特性。原则105格式化你的代码代码缩进、编程规范原则106不要太早编码编写软件和盖房子类似。这两者都需要做很多准备工作。在设立基线前要确认需求和设计是正确且合适的在对最终产品编码前更要确认。原则107依据需求跟踪测试理解哪些测试可以验证哪些需求是很重要的。原则108在测试之前早做测试计划必须与产品开发同时进行以便同步完成测试计划和初始开发活动。原则109不要测试自己开发的软件软件开发人员永远不应成为自己的主要测试者。 1.在开始集成测试之前检查单元测试是否足够。 2.所有集成测试 3.所有软件系统测试原则110不要为自己的软件做测试计划你不仅不应该测试自己的软件而且也不应该负责为软件生成测试数据、测试方案或测试计划。原则111测试只能揭示缺陷的存在无论测试得多么彻底和深入测试只能揭示程序中存在缺陷而并不能确保程序没有缺陷。原则112虽然大量的错误可证明软件毫无价值但是零错误并不能说明软件的价值本原则的第一部分显然是正确的第二部分则发人深省。原则113成功的测试应发现错误假设你感觉生病了医生把你的血样送到实验室。几天后医生打电话告诉你“好消息你的血液正常”。这不是什么好消息。你病了否则不会去看医生的。原则114半数的错误出现在15%的模块中保守估算在大型系统中大约一半的软件错误出现在15%的模块中80%的软件错误出现在50%的模块中。原则115使用黑盒测试和白盒测试黑盒测试使用组件外部行为的定义作为唯一输入。白盒测试使用代码本身生成测试用例。原则116测试用例应包含期望的结果一个测试用例的文档必须包含期望的正确结果的详细描述。原则117测试不正确的输入为尽可能多的可接受的输入情况生成测试用例是自然和常见的做法。原则118压力测试必不可少在面对极限的负载时他是否可以保持正常运行。原则119大爆炸理论不适用在一个项目接近交付期限而软件还没有准备好的时候开发者往往充满绝望的情绪。原则120使用McCabe复杂度指标圈复杂度。1976年提出来的。原则121使用有效的测试完成度标准 1.每周发现新错误的比率 2.暗中在软件中埋下已知的bug然后bug到目前为止被发现的百分比。原则122达成有效的测试覆盖 1.语句覆盖率 2.分支覆盖率 3.路径覆盖率原则123不要在单元测试之前集成原则124测量你的软件测试软件的时候往往很难确定为何软件会失败。原则125分析错误的原因如果一类错误的原因我们已经全面地分析和研究过了那么就不那么容易再犯同类的错误了。原则126对“错”不对人当你或他人在你的代码中发现错误时公开坦诚地讨论它。与其责骂自己不如将它当作自己和他人的学习经历。原则127好的管理比好的技术更重要好的管理能够激励人们做到最好糟糕的管理会打击人们的积极性。原则128使用恰当的方法技术问题需要使用技术的方法。管理问题需要使用管理的方法。政治问题需要使用政治的方法。原则129不要相信你读到的一切一般来讲相信特定想法的人会搜索支持这个想法的数据而抛弃不支持的数据。原则130理解客户的优先级如果客户能按时获得必需的10%的系统功能那么他们可以忍受其余90%的功能延迟交付。原则131人是成功的关键具备合适经验、才能、培训的能人是在预算内按时完成满足用户需求的软件的关键。原则132几个好手要强过很多生手你应该总是雇佣最好的工程师。原则133倾听你的员工你必须信任那些为你工作的人。原则134信任你的员工如果你不太信任他们那么他们会给你不要去信任他们的理由。原则135期望优秀如果你对员工有更高的期待他们将表现得更好。你期望的越多获得的成就就越大。原则136沟通技巧是必要的如果他/她不能沟通、说服、倾听和妥协最好的设计师也可能会变成差劲的资产。原则137端茶送水给他们惊喜在午夜给他们带比萨。原则138人们的动机是不同的能够打动员工的东西和打动我的东西是一样的。原则139让办公室保持安静最有效率的员工和公司都拥有安静和私密的办公区。原则140人和时间是不可互换的只用“人月”来衡量一个项目几乎没有任何意义。原则141软件工程师之间存在巨大的差异研法效率每人每月完成的代码行数相差25倍之多质量每千行代码中发现的bug量相差10倍之多。原则142你可以优化任何你想要优化的任何项目都可以优化任何要优化的“质量”因素。在优化任何一个因素时通常会弱化其他“质量”因素。原则143隐蔽地收集数据数据收集在以下方面极为重要帮助进行未来的成本预测评估项目或组织的当前状态评估管理、过程或技术变更的影响等。原则144每行代码的成本是没用的我们可以选择以多种语言中的任何一种来实现程序。原则145衡量开发效率没有完美的方法将代码行数评估转换成功能点人月等。原则146剪裁成本估算方法每种方法都基于从大量已完成项目中收集的数据。原则147不要设定不切实际的截止时间一个不切实际的截止日期将无法保证完成任务。原则148避免不可能原则149评估之前先要了解在你可以评估任何事情之前你必须先了解一些东西。即使每个人都以同一种方式衡量某事这种方式也并非一定适合你。原则150收集生产力数据如果你尚未从过去的项目中收集详细的数据那么今天你就无法剪裁你的成本估算模型。原则151不要忘记团队效率优化所有个体的生产力并不一定会产出最佳的团队生产力。原则152LOC/PM与语言无关语言的选择会极大地影响可维护性。原则153相信排期一旦建立了可行的排期并分配了适当的资源所有各方都必须相信排期。原则154精确的成本估算并不是万无一失的你假设概率原则155定期重新评估排期排期通常在项目启动时设定其中包括中间期限和产品交付期限。原则156轻微的低估不总是坏事对任何一个特定的项目被轻微低估比被轻微高估会花费更少的资源。原则157分配合适的资源不管人员的质量如何工具、语言或流程的可用性如何认为强加的进度和不恰当的预算将会毁了一个项目。原则158制定详细的项目计划每个软件项目都需要一个计划 PERT表、甘特图、里程碑、标准、分配。 “如果你不知道要去哪里那你也就无法到达那里” 原则159及时更新你的计划有一个过时的计划比完全没有计划更糟糕。所以无论任何时候情况发生变化都要更新你的计划。原则160避免驻波重新安排时间和重新计划需要采取行动而不仅仅是承诺很快就能解决问题。原则161知晓十大风险人员短缺不切实际的排期不理解需求开发糟糕的用户界面当用户并不需要时尝试镀金没有控制需求变更缺乏可重用的或者接口化的组件外部执行任务部满足要求糟糕的响应时间 10.试图超越当前计算机技术的能力原则162预先了解风险对于每个风险要量化其真正发生时会带来的破坏程度并量化这种损失发生的可能性。原则163使用适当的流程模型原则164方法无法挽救你作为一名管理者要提防那些声称基于新的方法将大大提高质量或生产力的虚假的预言家。原则165没有奇迹般提升效率的秘密软件开发行业充满了“推销员”他们鼓吹通过使用这种工具或那种技术能够降低开发成本。原则166了解进度的含义了解衡量进度的标准原则167按差异管理原则168不要过度使用你的硬件当内存或CPU使用率接近90%时软件开发成本将翻倍当接近95%时成本将会增加两倍原则169对硬件的演化要乐观摩尔定律原则170对软件的进化要悲观原则171认为灾难是不可能的想法往往导致灾难你决不能沾沾自喜地以为一切都在控制之中并且会一直保持这样。原则172做项目总结记录、分析所有不符合预期的事情并从中学习。原则173产品保证并不是奢侈品产品保证包含软件配置管理验证和确认。原则174尽早建立软件配置管理过程怎么去报告一个软件问题怎么去提出一个新的需求所有利益相关方对于建议的改动都能知晓且他们的意见都被考虑了有一块看板用于展示变更请求的优先级和排期所有基线化的中间产品或最终产品都在掌控之中原则175使软件配置管理适应软件过程软件配置管理SCM并不是一套对所有项目一律使用的标准实践。原则176组织SCM独立于项目管理 SCM只有在独立于项目管理的情况下才能做好本职工作。原则177轮换人员到产品保证组织每个优秀的工程师每隔两到三年要投入六个月的时间到产品保证上。原则178给所有中间产品一个名称和版本原则179控制基准原则180保存所有内容明智修补的首要原则是保存所有的零件原则181跟踪每一个变更变更未解决预期要解决的问题变更解决了问题但导致了其他问题在将来的某天变更被注意到时没有人能弄清楚更改的原因原则182不要绕过变更控制变更控制每个人都会得到收益原则183对变更请求进行分级和排期成立一个委员会定期评审所有变更请求。原则184在大型开发项目中使用确认和验证VV 原则185软件会持续变化原则186软件的熵增加任何经历持续变化的软件系统都会变得越来越复杂并且变得越来越杂乱无章。原则187如果没有坏就不要修理它软件被认为是可塑的、易于修改的。不要误以为软件中的“失灵”很容易发现或修复。在检查时你觉得自己发现了另外一个错误。不要试图“修复”它。很有可能你会引入而不是修复一个错误。原则188解决问题而不是症状当软件出错时你的责任是彻底理解错误产生的原因而不只是草草分析一下并对你认为的原因进行一个快速的修复。原则189先变更需求如果各方都同意对软件进行增强那么第一件事就是变更软件的需求规格说明并获得批准。原则190发布之前的错误也会在发布之后出现不要花钱填坑。原则191一个程序越老维护起来越困难原则192语言影响可维护性开发所使用的编程语言会极大地影响维护期间的开发效率。原则193有时重新开始会更好原则194首先翻新最差的完全重新设计和重新编码“最差”的组件。原则195维护阶段比开发阶段产生的错误更多维护期间有20%到50%的改动会引入更多的错误。原则196每次变更后都要进行回归测试对所有之前测试过的功能进行再次测试。原则197“变更很容易”的想法会是变更更容易出错因为软件是很复杂的要正确运行必须处于“完美”状态所以必须认真考虑每一个改动可能带来的影响。原则198对非结构化代码进行结构化改造并不一定会使它更好原则199在优化前先进行性能分析请记住80%的CPU周期将被20%的代码消耗原则200保持熟悉熟悉守恒定律保持产品发布版本之间的改动量相对稳定。原则201系统的存在促进了演变无论你认为自己多完美地实现了需求都必须魏部署之后必要的变更做好计划。

查看全文

http://www.zqtcl.cn/news/845203/