弱弱的问一句：大家都多少人是先画流程图后写程序的？

只看该作者 · 2012-2-5 19:15

如题所问，虽然知道先画流程图后写程序，是一个良好的习惯。但是，我一直都是一上手就开写程序，程序写完了，后期文档整理的时候才开始画流程图。想该，但是很难了……

只看该作者 · 2012-2-5 19:21

个人意见：想清楚就可以，没必要拘泥于形式。

1万 · 2012-2-5 19:26

一般的小程序，要什么流程图啊。瞎掰！

1万 · 2012-2-5 19:53

一般的小程序，要什么流程图啊。瞎掰！
dong_abc 发表于 2012-2-5 19:26

还是要的，你现在记得，并不代表你以后记得!
这个流程图不能省的！

1万 · 2012-2-5 20:38

开车为啥要考驾*？不是因为你不会开，是因为你不会注意安全。跟流程图一个道理，无证驾驶迟早是要还的。

1万 · 2012-2-5 21:23

本帖最后由 dong_abc 于 2012-2-5 21:27 编辑

想问一下LS两位，你们看过以前画的流程图吗？大型软件不算哈。我如果忘了程序流程一般直接看源代码。第一反应就想不到流程图上！因人而异吧。

1万 · 2012-2-5 21:45

想问一下LS两位，你们看过以前画的流程图吗？大型软件不算哈。我如果忘了程序流程一般直接看源代码。第一反应就想不到流程图上！因人而异吧。
dong_abc 发表于 2012-2-5 21:23

那我也想问下楼上的，你接手过别人的程序吗？我接别人程序的第一感觉是还不如毁了重写。如果再加上没有流程图，太TM麻烦了。

另外就算再高的高手也有犯晕的时候，流程图可以从宏观上看流程有没有漏洞和可以简化的地方。熟手不画简单流程的流程图和鼓吹不画流程图就乱犒程序是有本质区别的。

1万 · 2012-2-5 22:38

写好注释就行了....放心吧...流程图不如把函数设计好

只看该作者 · 2012-2-5 22:46

我喜欢在草稿本上随手乱涂乱画的那种流程图，这样敲代码时反而效率高。正规的流程图软件用也是帮倒忙，整个打断思路。

只看该作者 · 2012-2-6 00:16

年轻时，经常写着写着脑袋里就蹦出新想法，恨不得把现在的代码推倒重来，也经常推倒重来。现在岁数大了，只有一个想法了——直达目标的那个想法，其它繁文缛节、枝枝杈杈全部从脑袋里删除。

但是确实没有流程图。有文档、注释、有写博客。每个软件都有一个文本文件，记录着BUG、更新、一些想法、未完成的功能，以备日后查验。

当然，我不是专业搞软件的，没有受过大项目熏陶。

1万 · 2012-2-6 00:48

最早的时候，我是画流程图的，慢慢地就不画流程图了，但虽然不画了，脑子里还是要有流程图的。
通常，我是把程序的架子先搭起来，就是像画流程图一样，写好一个个的函数，确定函数的调用关系，但函数是空的，没有具体内容。然后根据功能需求，把一个个函数的代码写出来。当然有时候要回过头来调整“架子”。
总的思路就是：像写**一样，把提纲先列好，然后再写具体的内容。编写代码的过程中，可以回过头来修改提纲。
换个说法：比如画素描，先是寥寥数笔勾出大致轮廓，再逐步完善，最后抠一下细节，作品就完成了。
用此方法，为一个产品写过一个7000多行的汇编代码，仅用编程器，花了半年时间，总算把产品做好了。那段时间，连做梦都是以微秒为时间单位的，吃饭的时候也会下意识地想：我吃完这碗饭要多少微秒。

1万 · 2012-2-6 07:05

1)编程序需要不需要流程图?需要. 不过这个流程是在程序总框架之下,并且并不需要画出来,想清楚就行.
2)对程序写文档,写注释;
3)变量用明确含义的缩写或全称,并尽量注释它的含义.

只看该作者 · 2012-2-6 09:50

本帖最后由 adce 于 2012-2-6 10:02 编辑

流程图是"软件工程"中的重要组成部分...
"软件工程"是一门外行指导内行的科学...所以作为使外行可以无理取闹的重要手段...
流程图必不可少...因为外行只能看懂这个...

这并不是诋毁流程图...而是程序员的必备技能...因为画了好了流程图才能使你做得少...但老板认为你做的多
也就是工作干的好不如流程图画的好...

广义的流程图有很多...有用例图、顺序图、状态图等等...软件工程里都有介绍...
还是那句话...

软件工程是外行指导内行的科学...
作为外行...是接近文盲的水平...不要指望能看懂字...也就是看看图的水平...
外行(投资人、老板、项目经理、客户)都是很重要的....所以流程图很重要....

编写代码与画流程图没有任何关系...
流程图主要是用来讨论用户的需求的...
代码怎么写和流程图没有关系...

一个理想的开发团队是1个人编码...10个人写文档(画流程,说明书)这么个比例...
这也是Teamwork的真正思想...
即能者多劳.其他为这一个人服务....
现在大部分企业都把Teamwork当成三个和尚没水吃了...

很多个人开发者很可能又要谈需求画流程又要写代码....
我推荐您有谈需求画流程的时间...
不如请客喝酒...

只看该作者 · 2012-2-6 09:54

这个习惯不好，要改啊

2万 · 2012-2-6 10:21

从来就不画，小心投入太多，得到太不整天烦恼

1万 · 2012-2-6 10:25

只要没经验,犯错误在所难免.我最近的工程,UML图都被我推翻重画.2k行代码全部重写

1万 · 2012-2-6 12:07

类图必画。
函数名必须写说明，全局变量必须写说明。
函数调用尽量少，耦合尽量小。
十行及更少行的代码，不画流程图，只写注释。
文件里面的函数不易超过10个，文件说明必须写。

以上个人的习惯，挨个流程图都画，实在没有时间，小函数都是用understand自动生成，应付一下文档。

只看该作者 · 2012-2-6 12:07

原来小i也有不少心得:lol,能写是最好的,不写也要有总体框架,如果连软件的外棚都没有,呵呵....你的软件好极都有限!

1万 · 2012-2-6 12:09

16# icecut
重构的时候，绝大多数代码可以复制。所以我接别人的代码，从来不怕彻底返工。
之前实现的功能不会变，只是重新规划了一遍。不会有多少工作量的。

只看该作者 · 2012-2-6 13:04

从来就不曾写过，软件这东西想写上去就写上去，被拘泥于形式反而写不出来了，
写好注释和良好的格式习惯才是必须的

弱弱的问一句：大家都多少人是先画流程图后写程序的？

湍急之河流

七世轮回

技术奇才奖章

精华达人奖章

核心会员奖章

坚毅之洋流

十世金身

技术导师奖章

终身成就奖章

技术领袖奖章

荣誉元老奖章

无冕之王奖章

奔腾之江水

突出贡献奖章

沉静之湖泊

以坛为家