Posts

当我们谈论敏捷开发或精益方法，许多人可能首先想到的是某些具体的操作，如每日站会、使用看板、每周迭代等等。然而，这些并不是敏捷开发的必要条件，更不是敏捷开发的全部。敏捷开发的精髓，其实是在于持续迭代的思维方式。 持续迭代 持续迭代，是敏捷开发的关键。迭代的本质，是对人类能力有限这一现实的理解与接受。我们每个人都有所不能，但同时也有无限的可能。在敏捷开发的过程中，我们不是在试图设计出完美无瑕的产品，而是在理解和接受我们可能会犯错误，然后以此为起点，不断地修正、优化和改进。 以错误处理为例。当团队中出现错误时，我们不应逃避责任，而应积极寻找问题的原因，并通过流程改进来防止同类错误再次发生。这种改进是由团队自发进行的，而非强制实施。这种自主的改进精神，能够最大程度地激发团队成员的主观能动性，推动团队向更高效的目标发展。 讲述这种思想，也许用画画来作比喻最为贴切。我们的第一版产品，就像画的草图。之后，我们在草图上逐步添加线条、颜色、细节，最终得到一幅完整的画作。这个过程就像我们在不断地迭代优化产品，每一次的改进都是在前一版本的基础上进行的，而每一版的产品，都是可以独立运行的完整版本。 工程实践 在实际操作中，不同的敏捷团队可能会有不同的实践方式。比如，有的团队可能使用测试驱动开发（TDD），有的团队则可能使用代码审查（PR）。这些都是可能的，也都是敏捷的体现。因为，无论采取何种方式，都是为了尽快建立反馈循环，以提高开发效率和产品质量。就像我们进行TDD时，先编写测试，然后实现功能，再进行重构。测试的目的，就是为我们提供反馈，让我们知道实现是否正确。 此外，持续集成也是一种反馈机制。它能告诉我们代码是否能成功编译、是否能与其他模块正确集成，我们的代码是否能形成一个可运行的软件。在持续集成环境下运行的测试，可以帮助我们尽早发现和修复错误。 小结 简而言之，迭代开发的核心就是：首先，能够端到端交付一个小而完整的功能；其次，提供反馈机制，以指导下一步的增量工作；最后，拥有开放的学习心态，根据反馈及时进行调整。在这个过程中，我们既要接受可能会犯错误的现实，又要尽全力去修正这些错误，使产品越来越完善。只有这样，我们才能真正理解和实现敏捷开发。 扩展阅读 Don’t Know What I Want, But I Know How to Get It Revisiting the Iterative Incremental Mona Lisa

我们需要有对自己的信心，这个信心不依赖于外物而存在。你可以不断的与未来的自己对标，向着自己的目标前进。一旦有和他人对比的邪念，你就需要停下来，让这种念头走开，然后轻装上阵，持续前进。

作为一种人工智能模型，ChatGPT是一个高效的开发工具，可以极大地提高开发人员的效率。作为一名经验丰富的开发人员，我对它的能力有着复杂的情感体验——一方面，我感到惊讶和略微担忧，但另一方面，我认识到一个新时代正在兴起，我很高兴能成为其中的一份子。无论如何，我们需要考虑如何利用这些新技术来获取新的优势。

ChatGPT或者大部分现有的AI工具，很大程度上无法独立的完成创造性的工作。但是如果反过来，我们提供prompt，然后review这些工具生成的内容，则可以成十倍的提高我们的效率。不过和其他很多新工具的发明一样，它在带来挑战的同时也带来的机遇。在我看来，学习并最大化发挥AI的价值可能会帮助你比以前刚快的脱颖而出。

在这篇文章中，我想要讨论一些关于色彩的基本原理，一些在实际项目中比较保险（未必非常酷炫，但是比较安全）的配色方法，以及一些工程中的实践（比如accessibility等）。通常来说，大部分人都可以相对轻松的觉察出**良好的**配色方案，或者说很容易对比出配色方案A比方案B更加的“和谐”。而另一方面，当需要自己从头设计出一个合理的配色时，则往往会不知如何着手。