云开发的云开发的假设和原则
发布网友
发布时间：2022-05-25 12:45
共1个回答
热心网友
时间：2023-10-29 15:09
只关注产品
[假设]
产品体验为王、口碑致胜，否则就是垃圾（客户或市场是判断的唯一标准)，但开发者往往只关注代码逻辑，技术骨干也往往只关注框架模式，未站在用户角度去深入体验和精致要求，盲目或无所谓地遵从产品设计，可实际上产品设计本身就是反复探索、试错和试验的过程，于是形成了开发与产品设计的森严壁垒，并在反复证错的过程中，进一步激化了产品和开发的矛盾，营造出料一种产品恶性进化的氛围。
[原则]
把所有注意力只需且必须集中在产品上
无缝交互驱动开发
[假设]
客观上产品都是逐渐成长的，阻碍这一过程的就是必须锁定特定版本的传统开发模型，即特定需求驱动开发，特定时间、地点和人员进行一种蹩脚的产品发展的推进，沟通和反馈这一过程淹没在时断时续的交互障碍中，遑论随需而变。
[原则]
不*时间、不*地点、不*人员的沟通和反馈
极限迭代
[假设]
用时间和成本的方式简单的评价软件开发速度和软件阶段版本毫无意义，虽然面对用最少时间和最低成本尽快迭代出一个可供沟通和反馈的试错版本直到一个有基本价值的稳定版却是日益明确的要求，因为迭代速度的量化标准模糊不堪，而且每次迭代的结束由于其他环节跟不上而带来较大的中断并不能有效触动进一步迭代的开始。
[原则]
确保连续沟通和反馈的快速迭代
粗暴式简单
[假设]
简单往往最容易理解，只有理解才有可能更好地开发、使用、推广、维护和发展，软件系统做到足够的“简单”，往往最稳定和高效，只有最简单稳定的东西才有可能被使用；同时，简单往往最小工作量，少做就是最好，因为可能需求不清楚、场合没必要、使用有争议，不能稳定化的需求尽量延后，毕竟，开发者对需求的把握、系统的把握也是一个成长的过程，不可能一步到位，否则容易带来巨大争议和质量问题。但什么才是简单，每个人的秤都不一样，简单之道不简单！
[原则]
真正的简单 ，要简单到粗暴，可以不限特定人、人员数目和技术细节的简单化
四轮驱动质量控制
[假设]
传统编程模式下如果没有显式规范并加以培训的代码必将遵循墨菲定律--反其道而为之，而编码人员个体的惰性、倦怠、得过且过和自我否定勇气不够，程序代码往往存在众多质量异味， 在对速度又有额外要求时将更容易忽略众多潜在风险而形成产品的炸点；实际上，没能监督约束的代码肯定会累积较大风险，而风险代码之间相互依赖将进一步放大风险，传统代码评审耗时费力且难以全面兼顾，而互审由于责权利问题更是不能落实，最终反复迭代后无法继续重构而失去控制只能推倒重来！
[原则]
软件规范显式自动约束，标准质量监查无缝渗透，代码完备测试透明累积，同一品次代码杜绝依赖，从四个方面自驱动代码质量控制
自动化质量跟踪
[假设]
引入任何改变，不管大小，则bug必然存在，且可能非开发者的直接原因引起，隐藏很深，危机重重，所以，任何代码改变，如果没有相应措施进行确认，普通开发人员将毫无信心，直到改变的勇气丧失殆尽！
[原则]
任何代码改变必然伴随一次完整的自动化质量检查并形成质量跟踪报告
复用同步和节制
[假设]
复用虽是提升品质的根本，但低质量复用很容易引入并带来严重问题，而且复用容易过渡追求而耗费更多时间且最终变成鸡肋，复用一旦跟创新结合更容易变成过于创新，少量使用后往往尾大不掉难以否定。
[说明]
在复用接口基础上，按软件本身阶段同步驱动复用化，在产品非正式版前节制通用化投入！
可控的开放
[假设]
只要是不开放（无关免费）的东西，中间隐藏的单点故障就会存在，甚至有可能就是放不开的垃圾，除非有良好的服务支持；因此，运行时要避免封闭的中间件（无关信任），避免对操作系统的*（能灵活、快速安装部署升级），如果暂时存在则至少解耦可替换，从而确保完全的可控性。
[原则]
要保持开放--全松耦合但建立耦合质量标准
共同设计和统一路线
[假设]
技术模式和实现路线不被认可，哪怕再“好”，往往也存在不接地气的毛病，是必须抛弃或说服的，否则，着急的落地和推进，将导致众多的问题，这些问题不被理解将进一步放大问题，从而进入恶性循环；尤其是对接其他系统的，如果为了赶时间，导致很多技术路线未完全统一，如字符集、数据库、应用整合、数据整合...，这将形成“致命”的软件缺陷；实际上，如果开发团队技术定位和框架偏向未预设，应尽量保持大部分开发者的习惯，理解公司高层心理定位，争取开发团队的完全理解。
[原则]
共同进行框架、路线和构件的设计，尊重现实、优先复用、融合分歧和分解矛盾以统一路线，达成相互理解和共同期望
服务是产品的延续
[假设]
传统的交付多是阶段*付，从而造成产品成长的割裂。
[原则]
产品的真正开始是对产品使用的支持
改变思路才有出路
[假设]
传统的开发过程，我们一定会发现：无意义的重复带来厌倦，按规范手动调整多个地方必定带来一致性冲突，可选择的越多就将出现自由选择障碍，无监管的自由将带来破坏即互为覆盖破坏，对同一事物的无边界的修改将导致责任不清分工困难，没有评审的口头规范将逐步失控，熬夜等过度加班等将导致节奏失调直到失控，不能对全部进行整体认可、参与而负责的往往就会相互推诿而千疮百孔，不能全部把握的就会带来越来越强的抵触，人为的层次迁变和错位将随着时间的流失而变得越来越成本巨大，没有经过第三方检验的代码充满忧虑，以人为本和充分尊重等口号毫无意义...
[原则]
思想决定命运，只有根本改变开发者的开发这一个行为，建立起对传统开发*性的开发体系，才有可能重塑开发者的定位（摆脱码农的命运）--完全平等和相互尊重 ，才有可能真正积极、主动和有力地面对云时代的挑战。
云软件过程管理
[假设]
人有惰性，代码逐渐熵化，传统管理往往脱离实际。
[原则]
对开发过程要实施连续不断的管理--自动化开发过程的管理
