编程编到一定阶段之后，大家都有没有遇到这样的阶段？

选个你自认为ok的方法开始动手吧，这都是积攒经验必经的过程。

先做，遇到问题再改。

做出原型之后再考虑有什么地方可改进的

把每次的过程详细记录下来，分析、比较方法的不同。

多尝试即可，重构的多了以后自然就知道该怎么办了

我觉得，会这样的原因就是，你遇到的问题还不够多。我觉得成长很大程度上靠失败的经验积累起来的，别怕错只管来就是了

推荐一本书《无从选择》

遇见这种情况我一般都直接用greedy algorithm...

完美主义作祟, 过了就好了

用java或.net的都有这个阶段 , 因为这些语言务虚, 凡事必讲模式,架构等. 用动态语言php/python/ruby的会好些,因为这些语言务实

谢谢楼上的各位～

@jjx 感觉确实有点完美主义的倾向，我总是倾向于找到最好的解决方法，可往往不存在最好的完美的解决方案

@yunan 看了豆瓣的简介，似乎确实是我所面临的问题，有机会看看～

退回到原，然後一最符合初衷的方案

没看懂是交互纠结还是代码纠结。
如果是交互纠结，没建议。
如果是代码纠结，也没建议。（真心不是来捣乱的。只能多试了。

我经常碰到这样的问题，在一些方案间犹豫不觉，浪费大量时间，搞得精疲力尽，心情沮丧
这样做的目的无非是因为情况有点复杂，你想兼顾各种情况，做出最“完美”的设计，但其实你是掉坑里了，不停的原地打转
在“折磨自己”无数次后，我现在的做法是，先用最简单直接的方法解决主要问题，让它上线
上线稳定后再考虑其它情况，一个一个来，在这个过程中你会发现一些“范式”，可以有效解决之前纠结的问题，然后觉得之前的纠结很SB
这个过程中可能需要一些重构，写点单元测试可以让重构顺畅点

我现在觉得，好的设计不是一开始就能“想”出来的，而是在开发过程中“发现”出来的

参考奥卡姆剃刀原理

@perrywky 恩～～

@aisk 。。。奥卡姆剃刀原理

先可用，再重构。

@alsotang 赞同，我也是这么做的，重构会有新的认识，技能提升很快

@emohacker
@alsotang

恩～但不知道你们有没有遇到过前端一旦改了个东西，后端逻辑呀数据库结构啊整个都要发生巨大变化的情况？

可以去看看经济学上的两个方法

@juicy 感觉这种情况发生只有在大版本更新中，或者访问量上来了，你的程序性能优化空间还蛮大而需要做优化，况且即便要变数据库结构，肯定也要事先规划好数据转换逻辑，数据还是在那里的。

之前经历过一个项目2.0变动非常大的，把逻辑理清楚，重构完之后感觉很舒服的，这个过程的艰辛在于如果你是中途接手的，那你就需要蛋疼别人给你留的坑，因为历史遗留问题是必然存在的。

纠结完之后你就会感觉跟以前不一样鸟。

可是感觉你的问题有点矛盾，前端的变动不应该牵动到底层数据逻辑才对，底层的数据逻辑由功能需求决定，前端是负责表现需求以及实现交互。你说的那种情况，我觉得应该是需求大变，前后端都得变

送给楼主一句话
Done is better than perfect.
首先把东西做出来用起来，然后你完全会有完全不同的视角，再重构。

@emohacker
@xuan_lengyue

恩，谢谢～心里大致有个数了

对完美主义者来说，应该这样想：先花一个小时做出一个屎一样的原型（好听点叫Minimum Viable Product），做出来了再说别的

所以国内的小老板们才是最理智的，
管你用什么方法，先给我整个能跑的东西出来再说

premature optimization is the root of all evil

人不要以自己为上帝。
你在想什么设计比较好，其实就是在想什么设计最好。
满足需求就行，顶多照顾一下算得到的潜在需求。
最好连潜在需求都别照顾，因为潜在需求其实就是个大坑。
保持轻量，保持简单。
千万不要跳入完美主义的深坑。