今天我想说说我对成长的过程中“反馈”的理解。
反馈分很多种，正向的、负面的，及时的、不及时的。每一个恰当的反馈都能给予我们成长的机会，有些反馈可遇不可求，也有些反馈可以通过一些方法主动去创造。
还记得那是我上小学三年级的时候，在一堂自然课上。课上老师跟我们一起讨论宇宙和银河。老师说我们地球就在银河系里，所以我们看不到银河，当时我没举手直接反驳道“可是我晚上看到了呀”，老师表情很严肃的质疑我是怎么看到的，当时的我只有心虚害怕没敢继续说话。
那天之后我经常会约上小伙伴一起去能看到星星的地方找“银河”，我想证明我的确看到过“银河”，有没有找到银河不记得但是收获了很多探险的快乐。
第二年暑假我去农村的奶奶家玩，夜里出来方便，没有灯光但路面被星光映的很清晰，偶然间仰头看到了“银河”，那一瞬间我呆住了，现在的我也只能用美丽壮观惊叹形容一下，但是我知道这些词是不足以形容我当时的感受的。它不仅美丽壮观，还承载着我的很多回忆，那一瞬间我收获了只属于我的景色。
每当我有机会再见到银河的时候，我都会回想起那一年，我的精神仿佛都会穿越回那个属于我一个人的夜晚。现在，我已经不会关心当时老师的对与错，反而很感激那位自然课老师给予我的反馈。
最近我在研究“单元测试”，一是研究怎么使用单元测试，二是想办法在公司推广单元测试。
单元测试是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。
我是做web开发的，用的PHP语言。了解PHP的人也许知道，PHP团队大部分是基于语法简洁等特点进行高速迭代开发，而很少有团队会引入单元测试，因为有单元测试就意味着要多出一倍的需要维护的代码。即使这样依然有一部分高级团队或PHP老鸟带的团队会主动引入单元测试，并且极力的向广大PHP程序员推荐使用单元测试。这是为什么呢？
我们编写代码时，一定会反复调试保证它能够编译通过，这样我们保证了语法是正确的，但是没有任何人能承诺这段代码的行为是正确的。后续的交付中都需要专业的测试人员通过很多测试用例来保证代码行为的正确性。当然测试不通过还需要由开发人员对代码进行反复的修改调整。
幸运的是单元测试可以为我们的承诺作保证，编写单元测试就是用来验证这段代码的行为是否与我们期望的一致。单元测试也是程序，所以运行单元测试的成本非常低，我们可以随时靠单元测试得到反馈，这种及时高频的反馈将大大缩减开发的整体工期并保证项目质量。而我们付出的代价就是团队里每个开发人员都对自己的代码编写优秀的单元测试。面对高质量的代码，测试人员测试的重心就可以转向对项目合理性易用性等其他更整体的考察。
我理解的反馈永远是成长最好的动力源之一，主动创造反馈将是加速成长的最好方法之一。
你的日常生活工作是否也由各种各样的反馈推进着呢？你是否想过主动创造一些反馈机制来给生活工作带来便利和飞越呢？
欢迎大家给我留言，讲讲你们的故事。
