Objective-客观性

从今天起写中文,不装逼了。

今天成功完成了demo。为了顺利完成demo,我们昨天临时将部分还未完善的功能临时删除处理,例如Feedback的修改、删除,OrderTwo在邀约方后台无法查看等。下午我们花了很多时间深度分享了一下本周作为团队一起做项目的第一个星期。

Reflective-反应性

直到昨天晚上,整个组的还是士气高昂的。可能是因为老师一直在夸奖我们的前端完整度,所以我们一直以为自己走在整个cohort的前面。但今天demo的时候才发现,原来好几个团队不仅将前端也用简单大方的视觉方式展现,同时也实现了一些我们尚未实现的功能(如五星打分、聊天框等)。这让最后一组展示的我们有些措手不及,也影响了demo时的临时表现。尽管团队认为demo的整体效果和逻辑还是不错的,但在presentation方面其实可以做到更好。

Interpretive-诠释性

下午分享会时,我分享了本周最大的收获和最大的坑:

最大收获

本周最大收获当属深刻意识到提前规划的重要性。不仅仅是宏观层面从项目的目的、目标、功能的排期和分工而言,而在微观层面,个人对功能实现时的提前思考也是非常重要的。

举例而言,在实现Feedback功能时,由于之前很多时候都是一步步根据老师教程写入代码,所以习惯性在写入Feedback model之后直接就开始写Feedback的controller里的CRUD,并没有思考属于account下和admin下的Feedback controller,并且在写Feedback的view的时候也是想到一个页面写一个。

因此,尽管Feedback初步功能实现了,但MVC之间的功能非常混乱,有的CRUD action是多余的、有的view页面是不会用到的。

后来我在上传第一版Feedback功能的git之后,在纸上将Feedback功能所需要的MVC重新梳理了一遍,然后根据规划好的布局从top-down开始先建立controller里的action,然后添加和删除view的页面,最后再来将这些action和页面里的代码写出来,重新上传。

最大的坑

本周最大的是在routing方面。其实在这周之前我一直不够了解routes.rb文件和所有路由线路的关系。比如哪些resources会出现在多个namespace下面。之前的认知还停留在知道新的model需要作为resources,这样才能撰写CRUD,但没有明白如果是一个resources下(比如orders)下面再有隶属的resources(比如feedbacks)应该如何应对。

双重resources会影响整个MVC流程,但更难的其实是在不同的view里面如何传正确的路径和路径所指的数据。比如,在account/order_twos/index.html.erb里面,如果要调用除了order以外的数据,在path里面不能像之前比较简单的架构下只需要找到path(order)那样,而需要提供两个数值:

如果routes如下:

Feedback的controller如下:

def edit
    @order = OrderTwo.find(params[:order_two_id])
    @feedback = current_user.feedbacks.find(params[:id])
end

而此时想要在order_two的controller下找到edit的路径,则需要这样写:

<% @order_twos.each do |order| %>
...
<% order.feedbacks.where(:user_id => current_user).each do |feedback| %>
...
<%= link_to("修改反馈", edit_account_order_two_feedback_path(order.id, feedback.id), class: "btn btn-sm btn-default outline") %>
<% end %>
<% end %>

以上代码是在同一页面上,在每一个order_two下面的每一个order.feedback里找到edit的路径。这里的重点在于edit路径中的`(order.id, feedback.id),因为在route中这里需要两个数值:

/account/order_twos/:order_two_id/feedbacks/:id/edit

所以提供的第一个是order的id,第二个是feedback的id(感谢梁超教会我这里括号内信息的意思)。

Decisional-决定性

本周初步开始从“把教程中的代码套用到新的项目上”进入“自己理解后根据需求修改代码”,非常有成就感的一步。下周开始我们会用两天时间Eatgether所有的功能,接下来的时间会用于将显示出来的信息正常化,将整个网站美化,可能会调用团队的整体精力从后端逐步转移到前段。