说明
事情大致是这样的，在此之前我基本算是零基础，有那么一两次玩是刚好看到同事在玩，顺手玩玩，甚至没完成过一个面。这次呢，因为儿子买了个魔方，玩了会就没玩了，自己就拾起来玩玩，找了视频教程来看，完成整个魔方的复原，现在处于教小孩玩魔方的阶段。在这个学习的过程中呢，有了一些杂七杂八的思考，主要和软件开发有关，于是记录了下来。
如果你和我一样是魔方初学者，本文可能对你有点用，但这篇不是教程，建议看网上的视频教程。
思考
- 在看视频教程的时候呢，作者先把魔方的特点和动作（上，拨，下，回）的这些定义讲清楚。其实和在软件开发过程中，先把需求，把业务场景讲清楚是一样的，只有首先将概念弄清楚并且是大家理解一致的之后才有讨论和分析的前提。然而事实上，我们在沟通需求时，时常没有讲清楚，以为对方象自己一样本来就知道，少做了一些补充说明（或是限定范围），导致整个沟通过程鸡同鸭讲，收效甚微。
- 在复原的过程中是有固定套路的，比如黄色小白花，白十字，比如上拨下回，上拨下拨上拨拨下，右拨上左拨上右拨下左拨下等等，这其实和软件开发中的设计模式是很像的，对于一个模式解决一个特定场景的问题，而不同的模式的结合则能应对处理更加复杂的应用场景需求。另外我们可以把一些基础动作理解成我们常用的一些组件。
- 整个魔方的复原，大致分为先底层、再二层、最后顶层的过程。你可以体会到从无序，到有序，再次混乱最终有序的过程。其实这里我最想说的是关于再次混乱的问题，对于一个软件来说，从概念到有产品再不断运营的生命周期似极了这个过程，在概念阶段各种天马行空，之后从小处着手，有了原型，有了初版，不断加功能，接着各种问题开始暴露出来，在不断的修复与重构的过程中，产品逐步完善。而这里还有一个“差点就成功”，几次在最后复原的时候因为公式没有做完整，恢复就失败了，需要重新开始。在混乱的时候，对于身处其中的人可能只看到问题，或是对产品进行了新的定位，反正是没能坚持，然后就没有然后了，这是可惜，还是可怜？如果对于这个混乱的过程仔细观察，我们会发一些核心方块，位置基本是没有变化的。这也引起我的一些兴趣，对于软件架构时我们常说核心模块和边界，如果核心把握了，边界清晰了，拓展（或插件）的修改对核心的伤害就比较小。如果你往公司看是不是也有这个规律呢？有个术语叫“熵”，理解熵地过程可能更能接受变化吧。
- 其实刚学的时候就有点担心学不来，做总比看容易，就是别怕，做了总能出点东西。另一个就是，说总比做容易，真正自己做的才有体会，要有敬畏之心。
