一、初遇App Engine  

   这是我首次接触App Engine，第一次打开它，就被它的页面UI设计和功能所折服。App Engine实现了多端、多系统的在线协同开发，并且可以做到一个人完整的完成前后端的开发，丰富的前端开发功能更是让我们能做到“所见即所得”。可以说，它打破了开发的门槛，只需要少量的编程知识，就可以用很短的时间开发一款功能完备的应用程序。纯在线开发，让程序员不必再苦恼于更换新电脑，新系统后新的开发环境的配置。我迫不及待地开启我的App Engine旅程。 

二、坎坷的开发之路——对耐心与严谨的考验  

   本次DevCloud啤酒供需数字化管理系统开发竞赛提供了一份事无巨细的支持文档，按道理，参赛者只需灵活使用Ctrl+C Ctrl+V便可以轻易开发出自己的程序，但是，由于支持文档中所用的App Engine版本与开发时的版本不同，这导致了许多界面，以及组件名词的不同，这些就十分考验参赛者的灵活变通能力。  例如：“啤酒列表视图”界面中的“购物车”按钮，支持文库中要求我们令按钮的Value绑定为beerInfo.id（图一）。但是，在此版本中，“按钮”无法进行Value绑定（图二）。因此，我大胆推断不需要进行绑定，经过测试，我的推断是成立的。

   再例如：附加题1中，需要我们创建几个“流”，然而打开新建列表，没有发现“流”，此时我只能一个一个尝试，最终找到“流”的新名字——“服务编排”。  还有栅格容器中“列”和“行”在现版本中名字为“栏”和“分栏”等，不再赘述。  此外，在与一同参赛的伙伴交流时，发现接关单系统普遍出现了一个问题：接关单刷新后失效！在多次对比支持文档无果后，我开始考虑是否文档本身有漏洞。经过对比“接单”的JS脚本代码和其他几个脚本代码后，惊讶的发现它调用了一个从来没有见过的“takeOrderAction”服务模型，“从来没有”意思是前面所有页面的模型，以及往后的代码。那它是自己定义了一个模型吗？不！首先如果是这样，大可以让我们在模型里面自己建立一个，没必要另外写一个代码；另外，再对比其他的模型引用代码时，发现所引用的基本是定义过了的。于是我新建服务模型takeOrderAction，绑定takeAndclose，接单成功。 

三、不足与反思  

本次开发出现了很多粗心的情况，比如对象明明是BeerMgtInfo，绑定到了BeerInfo；代码中有一个lgj前缀没有改过来，等等。这个经验告诉我，不管以后做什么，都需要非常细心，不能总寄希望于“出bug再去改”“做完所有的功能再回去检查”，往往会因为元素过多而惰于修改。  此外，出库和用户取消订单出现的“期待日期格式错误”问题，从字段到代码都检查多次，仍未解决；关单功能出现“违反唯一规则”，也没解决。总而言之，功能不完备，非常遗憾。不过，我不会气馁，会吸取这次的经验，争取在下次做出比较好的产品。