先脑图流程图再编程还是先编程中修改？

[dxcqcv]

黑客与画家中有一段，作者不是耐心地一步步写出整个程序，确保大体上是正确的，而是一股脑不管对错，先把代码堆上去，再慢慢修改。你把整个程序想清楚的时间点，应该是在编写代码的同时，而不是在编写代码之前，这与作家、画家和建筑师的做法完全一样

想问问广大程序员，大家觉得这样对吗

[loading]

以前我是一边写一边整，甚至我前端都是这样。现在不了，都是规划好再开始。前端我也自己先画图了，起码用纸笔画个栅格。
做个小规划很快，纸笔效率特别高，甚至地铁上就能整完。

对于大项目，自然你也不需要再问了。

[kawaiidora]

先梳理流程是为了避免“路线错误，写得越多改起来越麻烦”。而所有细节不可能是初期能都抓到的，就在写代码的过程中逐步完善。

实际上的互联网公司代码：管他呢，天知道这个功能能否活过一个月（ doge

[shroxd]

个人觉得没必要分这么清楚，可以先做一点设计，然后写代码，觉得可以改进再折腾一下设计，循环着往前推进。毕竟大一点的模块一时半会也折腾不好

[raaaaaar]

什么都不设计肯定不行，但是考虑完美事无巨细也不现实，问题就在于度的把握。
小细节不用提前考虑，但是大的项目架构这些一定要提前考虑好。

[focuxin]

三个时期八个阶段

[YouLMAO]

P9 设计方案，一群 p6 哼哧农民

[boris93]

我不用脑图之类的玩意
首先理解我要干嘛，然后写 wiki 大致说明，以及定接口规范
然后一边写一边调，功能规模太大的话那就大而化小，写一块调一块

[taogen]

设计好了再写代码确实很舒服，能够减少写代码时间、减少 bug 和缺陷。
但是写一份好的设计文档也挺痛苦的，需要大量的思考。

[atonku]

先做功能，再定需求！

[xuanbg]

你自己也说了：要确保大体上是正确的。那么怎样才能做到确保大体上是正确的？我认为必须做到用脑图 /流程图画出完整的逻辑闭环。只要逻辑完整闭环，其他问题就都是小问题了，可以在编码过程中去完善。譬如哪些数据需要验证，数据类型用 long 还是 int，长度多少，删除是软删还是硬删之类。

[Jackeriss]

先做出最基本的版本，然后不断改进。改进方向可以先想方案，不需要想细节，细节在做的时候确定。

[Aeoluze]

先画个流程图呗

[dxcqcv]

@xuanbg 作者不是 xxxx，而是 xxxx

[waruqi]

梦中想好醒来敲

[vamayoumo]

之前看到过一种观点，做需求第一步是明确需求，把需要实现的需求点同需求方完整明确出来；接下来是构思实现方案，这一步不加设计模式和各种流程图；再细化实现方案，简单需求有初步构思就可以，如果觉得需求点复杂就需要画图和考虑适合的设计模式；最后才是代码。

[cmdOptionKana]

我先写数据库 schema

[JCZ2MkKb5S8ZX9pq]

手画草图 /编程 /draw.io 再画一遍归档

[tumaowolf]

技术厉害 /真正的全栈:先设计再实施
我这个菜鸡:先实施，实施到一定程度再设计

[uselessVisitor]

先思维图画出个大概流程，然后按照流程写，发现中间有空缺遗漏再补充

[MeatIndustry]

推荐一下 TDD，测试驱动开发。