admin 管理员组文章数量: 887018
2023年12月17日发(作者：下载空白简历)
Ｍａｎａｇｅｍｅｎｔ管理 程序员的创新修炼 文／许正华 以系统的方法来理解创新思维的基本方面有助于了解持续创新的内在规律。本文作者根据多年的工作体验 和思考，展现出了一个循序渐进的创新思考模型，并结合实例进行了深入的阐释和分析。 笑：１：创新 对程序员来说，“创新”是一个永恒的话题。它 给世人的感觉是既简单又玄妙。说它简单是因为 创新似乎不需要严格的外在条件，说它玄妙是因 为我们很难说清楚创新产生的过程，所有的创新 几乎都是不可复制的。 任务ｔ ｉ ｌ 任务２ ｛ ｌ 任务３ ｌ Ｊ０ｌ 囤 嗣 组件级重用架构（现在） Ｉ．匕 ．謦毒 ｛ｉ任务３ ； ．；ｉ＿ 。 』 Ｉ 》 【实例分析】前几天听到同事在抱怨没有足够的 硬件资源做伸缩性测试，经过进一步询问，我了 解到：产品中有一个部分需要多任务（进程）执 行；任务进程原本是由ｃ＋＋实现的，为了调用第 三方Ｊａｖａ ＳＤＫＩ￣＿程访Ｉ＇￣ＷｅｂＳｅｒｖｉｃｅ，每个进程都 加载了一个Ｊａｖａ虚拟机。经过测试发现使用了此 ＳＤＫ的ＪＶＭ占用了大量的系统资源，最终大大降 低了系统的可伸缩性。面对同样的场景，人们的 反应会有很大的差异：有些人会抱怨几声了事； 有些人会设法寻找更为强大的机器；还有人会 尝试从软件架构的角度改变现状。例如，把通过 Ｊａｖａ ＳＤＫ￣＿程访Ｉ＇￣ＷｅｂＳｅｒｖｉｃｅ的逻辑封装为本地 圈 创造力的工具（例如，通过随机输入突破现有思 维模式、挑战概念、跳出主要观点、定义问题和 代理服务，它可以将相关业务逻辑的重用从组件 级提升为应用级（如图１所示）。没错！这就是创 思维理论的缔造者和倡导者德・波诺教授在《比 新。本文将放弃任何对结果的讨论，因为创新不 知识还多》一书中提出了一系列可用于提升思维 应以成败论英雄。 如果说这些微创新不但是每个程序员都可以做、 而且必须要做的工作，那么我们是否已经准备好 剔除错误等）是这当中杰出的代表。在我看来这 了呢？这方面的系统论述向来是比较少的，水平 些工具并不是独立的，它们相互影响、共同发挥 ８２
Ｍａｎａｇｅｍｅｎｔ管理 作用。接下来就走近它们，以探其真面目。 批判性思维 批判性思维是创新过程最显著的特征（也就是剔 除错误），就让我们先从它开始吧。 在程序员江湖闯荡久了，就会深知创新的艰辛。 不求一鸣惊人、但求独善其身是程序员队伍中一 种比较具有代表『生的思潮。我们真正能做到独善 其身吗？试想如果现有代码的可维护性很差，任 何人都很难在有限的时间内写出高质量代码，最 终很可能落得个同流合污。 有时我们也会一不小心走到另一个极端：如果留 意，我们总能在公司的茶水间里听到员工关于公 司缺乏产品创新的恶评。批评是有益的，但我们 更需要批评过后的冷静思考和实际行动。创新无 疑需要批判性思维，但前提是我们能将“批判” 与“批判性思维”区别开：批判的目的只是为了 达到对某个事物的否定；而批判性思维则是通过 否定来寻找更好的做事方法。单纯的批判是消极 的；而批判性思维则要积极得多。 州题的定义 批判性思维是建立在问题定义基础上的，因为 “没有问题就无昕谓批判”。 什么是问题 什么是问题？期望与现实的落差就是问题。现实 是容易觉察的，但界定外界期望就难得多了。人 们倾向于把外界的输入作为建立合理预期的唯 一标准，而不是独立形成自身对预期的认识。例 如，开发人员总乐于将测试人员在缺陷描述中记 录的期望行为和结果作为实际的用户需求，并据 此来修改代码。 【实例分析】某产品中定义了“策略”的概念，并 提供了相应的编辑界面。在策略编辑界面（如图 ２所示）中，允许用户对原有策略进行保存或另存 为一个新策略。测试人员曾经报过一个用户体验 方面的缺陷：用户在选择“另存为”功能时，很 可能会遇到系统提示的失败报告，原因只是忘记 了修改策略名称。 我们可以顺着测试人员的思路将问题定义为“如 何让用户避免令人沮丧的失败报告” 。进一步思 考，不难发现策略编辑界面还有其他问题，比 如，用户原本希望创建一个新策略，却错误地点 击了“保存”按钮。因此，也可以将问题定义为 “如何通过合理的功能布局，避免不能预期的用 户行为”。最后，我们决定提供一个“策略拷贝” 的新功能，并将“另存为”按钮从策略编辑界面 中移除。 在定义问题时，我们需要注意以下几点。 ＿一个现象可能隐藏着多个问题。 ・区分核心问题与非核心问题；可以存在多个核 心问题。 ＿问题可以在不同抽象层次上定义（从用户体验 的角度来看，可分为表现层、框架层、结构层、 范围层和战略层）。 随着被灌输信息的增多，人们所受到的来自外界 的影响和约束不断增强。一个人对现实的接受程 度越高，问题形成的难度就越大。 外界是不完美的 对于软件研发团队，定义问题的能力直接影响其 需求分析的质量，进而最终决定了产品的质量。 一般认为软件工程师参与到需求分沂与产品设计 的机会并不是很多，他们接收来自用户或者产品 经理的需求规格，并且努力把功能列表转变为可 以运行的程序。不幸的是，现实中软件生产过程 要复杂得多：在开始阶段，写下来的需求只是冰 山一角；未写下来的需求才是沉浸在水下的巨大 ８３
Ｍａｎａｇｅｍｅｎｔ管理 冰块；即使写下来的、被用户所确认的需求规格 忽视概念的历史根源 也不能确保最终一定能够让用户满意。 对概念的忽视有其深刻的历史原因，如下所述。 《用户故事与敏捷方法》在论述用户故事与需求 炒作概念。不知从什么时候开始，“概念”常常 规格、用例等传统需求分析工具的区别时，特别 与一个动词相关联，它就是“炒作”。一个新产 强调用户故事的目的不是记录客户与开发团队之 品往往借助炒作热门概念来提升自身的价值， 间的协议或契约，而是充当着用户具体需求对话 “概念”渐渐变成了假、大、空的代名词。这与概 的占位符。 念本身的功能完全背道而驰一一概念原本是为了 因此，我们不能把产品经理的输入等同于用户需 让一个或一类事物能够更准确地被大众以一致的 求。在现实中，开发团队总是容易认为项目早期 形成的用户故事就是对用户需求的描述，因此大 部分人都放弃了对问题进行深入且持续的思考。 敏捷实际上是想告诉我们：外界是不完美的，昕 有相关人员（产品经理、开发者、测试者、用户、 文档编写者等）只有通过不断的沟通才能加深对 用户需求以及产品策略的理解，并在讨论的过程 中达成一致。如果我们不能在这个方面放弃传统 的惯性思维，我甚至怀疑所谓的敏捷是否还具有 生命力。 外界的不完美导致我们必须关注自身定义问题能 力的培养。首先，通过独立的思考形成自己对～ 个事物的预期，而不是唯命是从；其次，通过各 种可能的手段来确认这个预期是否合理，并进行 必要的修正；最后，对比现实与预期形成对问题 的认识。当这种思维模式成为你的一个思考习惯 时，问题就会不断地从脑海中涌现出来。 慨念的建 建立概念模型的意义 合理预期是建立在合理的概念模型基础上的。只 有明确了概念，才知道未来的路该往哪里走，才 知道什么时候需要坚持原则、什么时候需要像现 实妥协。只有建立起概念模型，你才有可能进一 步思考现实与存在于你脑海中的概念是否一致。 每一个软件设计问题的背后都隐藏着一个或简单 或复杂的概念系统。很多时候，软件工程师并没 有意识与能力去主动地发掘这些概念，这是导致 软件设计不确定性的重要原因之一。因此，对概 念的驾驭能力就成为软件架构师最为倚重的基本 能力之一。 方式所理解。说句公道话：“之昕以盛行炒作概 念之风，不是因为今天概念太多了，恰恰是因为 现如今人们缺乏对概念的理解。”这一切大概发 生在过去的十年里（十年前的我大约刚刚完成学 业、步入社会）。 只摸石头不过河。我们不妨把时间推得再久远一 些：在我念书的年代里，对概念的深入研究变成 了教条与迂腐的代名词，因为对很多人来说概念 意味着陈旧，意味着一成不变。概念确实表现出 一定程度的稳定眭，这种稳定性源于其抽象的本 质。但我们切不能将这种稳定陛绝对化。概念同 样也会像这个世界上的绝大多数物质一样，随着 时间的流逝发生变化。这种可变性源于其主观 的本质。没错！概念并不是像人们想象的那样客 观。人们只是试图通过自身的努力将自己对概念 的理解无限趋近于客观。 “实践是检验真理的唯一标准”——这是几乎 每一个中国人都熟知的一句话。我从不怀疑其 合理陛，但放在上述社会环境中，难免容易让入 迷失：既然是“检验”，我们就应该首先澄清待 检验对象。换句话说，我们应先形成对真理的假 说，然后不断地用实践结果增加其可信程度，亦 或反之。现实中，人们渐渐丧失了事先形成对真 理认知的耐心，这种不耐烦也许是源于人们对于 可能出现的自我否定的恐惧，这直接导致实践最 终仅仅成为一些人收集数据的工具。 我曾与一些软件研发人员讨论有关软件性能测 试的问题。我发现他们并不能清楚地说出某个测 试的目的。当我进一步询问测试结果能否帮助我 们得出一些结论时，他们就变得含糊其辞。在我 看来：单纯为收集数据而进行的测试是毫无意义 的，这就好比只唁记摸石头而忘了过河才应是原
版权声明：本文标题：程序员的创新修炼 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.freenas.com.cn/jishu/1702812680h431827.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论