先把功能全做出来，然后慢慢调整界面

可能帮不上忙，但是 LZ 说的我经历过 1. 最主要的问题是：现在很缺一个 bottom up 的 Front-end tutorial，也就是 Rails Tutorial 的 counterpart 从头写个网站界面，用上良好的 JS,CSS 框架和 Best practice, 排版等等技巧。这样子学一其次，前端就可以打个很好的基础 而不是每次写个 layout，就查半天。 这个我发邮件问过 Rails Tutorial 的作者，也在 v2ex 上发帖问过。这种教程目前还不存在 2. 关于界面设计，如果是个人作品（即探索性质的产品，需求不是特别确定的话） 不要一开始就把界面做得特别好，因为“界面”实际代表的是功能

拿我之前的一个作品，http://magicdigest.herokuapp.com/ 为例子 最开始是最简单的功能，界面是这样 没有 header, 没有 sidebar 等等。因为最开始最简单的功能就是这个，并且也拿这个去给朋友们看，觉得有没有用（MVP demo） 但是随着功能的逐步添加，最后就内容逐渐逐渐变多，有的 header，有了 sidebar 来供用户做 filter 等等

产品的界面会随着功能逐步发展。如果一开始就把整个 layout 确定下来，反而后期不利于修改了。 比如可能最开始是极简的，header 可能就发放 1、2 个页面比较美；可是程序一写开，东西一多，就没办法了 像http://just4magic.herokuapp.com/，我采用主题作为黑色，再后来扩展写起来，黑色作为背景就很烦

对于个人的探索类作品尤其是这样，因为你也不知道之后产品会往哪个方向发展。

最近写了一章关于 view 的，同时整理了一些开发经验，把 bootstrap 相关的也加上了，尤其是 bootswatch 的部分，希望对你有帮助。

http://rails-practice.com/content/Chapter_3/3.1.html

今天也纠结这个问题，主要是修改 view 往往会带来一堆小的 commit，这个时候就非常不爽。

现在在尝试分离，就是使用 Middleman 一类的软件来实现前端的开发，然后后端只做功能。等一切都完成了，再进行整合。因为前端大多数时候就是调整页面结构和各种效果的细微调整。调界面很烦…… 选 Middleman 的好处是可以跟 Rails 的采取相同的技术。

现在就是一个人在做 Rails 项目，希望能有帮助。

#5 楼 @chunlea 一个小 commit 就不爽，会不会过于洁癖了？ 不过谈深了就要扯到项目管理之类的了。

#5 楼 @chunlea branch 一个分支撸界面就是了

我感觉 1 楼说的对，先把 html 写了，排版和效果最后在做就行。。。我一直这么做

#6 楼 @MrPasserby 问题在于，小的 commit，对于 commit 的 message，好难去正确描述。

#7 楼 @dandananddada 开 Rails 调整界面，还是有些重。Middleman 调页面结构快很多，主要是好多东西可以很容易的做 mockup

#5 楼 @chunlea 请问 Middleman 是指的https://middlemanapp.com/吗？是图形化界面工具？

#7 楼 @dandananddada 但当分支 branch 被 merge 的时候所有的 commit history 也会出现在 master branch 的 commit history 里面吧？

#11 楼 @ted rebase -i

@liwei78 你写的这本 Rails 教程质量很高，很期待后续内容 :plus1:

你自己都意识到了啊，“前端经验不丰富”。要么学习前端，要么招个前端～

#13 楼 @shin 谢谢，我加油。

后端是做数学应用题，虽然难但有迹可循 前端是写作文，每次写的都不能一样

感谢各位指点，现在改变自己的思路。 先把功能做出来，后面慢慢调界面。

#10 楼 @ted 是的。但是非图形化应用。类似 Jekyll

#5 楼 @chunlea Middleman 挺有意思的，准备试一下，能很好的整合进 Rails 吗？

想做成什么样的形式就找什么样的前端模版，然后。。就没有然后了

#19 楼 @springwq 目前看还可以，支持 ERB，Haml 和 Slim，支持 Sprockets，不过 ActionView 的很多 helper，比如 video_tag 不支持，但是貌似可以引入，这样成本更小。