结构规则。 学习如何构建方案，探索可能性、错误、解决方案等。 - 页 4

新评论
 
C-4:

而如果在项目中间，甚至接近项目结束时，客户突然改变，你的清晰结构会发生什么。

  • 原始要求的5%。
  • 原始要求的10%。
  • 原始要求的25%。

这是对你的项目对变化的准备程度和弹性的一个很好的测试。

这就是问题所在，这也是我在这个主题中的原因。

我想找到一个答案，如何设计（或如何把客户塞进这样一个框架），使他的愿望得到满足，而项目又不被破坏。

因为硬币有两面，用一面你可以改变项目，用另一面你可以说 "不作为这个项目的一部分不能做"，真相是在中间的某处。

最好的事情是以这样的方式设计开发，使客户的大部分基本需求都可以实现。

 
C-4:
现在没有正常的程序员会画流程图。所有这些都是理论上的废话，旨在教给学童，但不适合在实际项目中工作。

这一切都取决于要在纸上写什么。

我不赞成写作，但有时你必须在纸上画出一个大致的结构。这很方便快捷，就像给珠宝商画草图一样，整体情况应该很清楚。

也许这就是为什么有很多非正常程序员，因为他们不画流程图。

 
C-4:
现在，没有一个正常的程序员会画流程图。所有这些都是理论上的胡说八道，旨在教育学童，但不适合在实际项目中工作。
好吧，我不会如此尖锐地称之为 "理论上的废话"。 以这种或那种形式在纸上画 "带箭头的方块 "在编程中被广泛使用。 至少采取同样的UML--充满了 "带方块的箭头"。:) 因此，在初始阶段，方框图也是有用的......
 
C-4:
现在，没有一个正常的程序员会画一个流程图。
没有方框图。你还是要画建筑。
 
sanyooooook:

我想这就是为什么有很多不正常的程序员，因为他们不画流程图。

;)
 
MetaDriver:
我不会轻易称其为 "理论上的废话"。 在纸上画 "带箭头的方块 "在编程中被广泛使用。 以UML为例--充满了 "带方块的箭头"。:) 因此，在初始阶段，方框图也是有用的......

我试过用UML设计，那是胡说八道（IMHO）。

所有这些方块和箭头我都可以完美地保留在我的脑子里，但抽象的东西不适合我的脑子，所以我把它们勾画出来。

HI 如果你深入挖掘，人脑很适合记忆图片、地图、行为模式，但不适合建立抽象，抽象是一个人最难做到的事情。

因此，人类总是试图将抽象的东西形式化，变成更熟悉的东西。

 
Urain:

人脑很适合记忆图片、地图、行为模式，但不适合建立抽象；抽象是人类最困难的任务。

ZZZI 这就是为什么人类总是努力将抽象的东西形式化为更熟悉的东西。

我同意。

在这方面，我有自己的方法来重塑自己的大脑，我甚至有软件开发（我可以偶尔分享），但发展非常缓慢（虽然事后看很明显）。

--

从某种意义上说，所有和任何编程都是抽象工作，但在实际处理抽象概念的水平和技巧方面存在巨大差异。

 
MetaDriver:

我同意。

我在这方面有自己的方法来磨练自己的大脑，我甚至有软件的开发（我可以偶尔分享一下），但发展非常缓慢（虽然事后看很明显）。

--

从某种意义上说，所有的和任何的编程都是使用抽象的工作，但在实际使用抽象的水平和技巧上有很大的区别。

我们对为抽象而抽象不感兴趣，不是吗？

我想，既然我们在进化过程中并不最适合抽象化？(值得商榷，至少比这个星球上的其他居民要好），我们应该尝试建造拐杖。

例如，人们发明了头脑风暴这样一种技术。

我经常为一个实体的命名而烦恼，给它一个简洁的名字，既能让人足够理解，又极其简短。当这一点成功后，抽象的东西就很容易被同化了。

对不起，我现在不能写太多（用手机写不方便），我到了那里就没有时间写了。我现在不能写很多东西（在电话上不方便）。 我不会有时间。

 
我阅读了ToR，如果没有想到结构形式的解决方案，我就在其他项目 上做工作，通常我不会在第一天就开始实施。如果程序不是ICL或XML，那么我就阅读、计算实现的变化、结构类型、类。当我脑海中有一个共同的画面时，我就开始切割积木或编写基本模块。 如果有些东西不成功，我就会拿着一些类似俄罗斯方块的玩具在沙发上崩溃，一直玩到我完全解决了问题，或者直到我感到厌烦为止 :)
 
Urain:

对不起，我现在不能写太多（用手机不方便），我到了那里就没有时间了。明天会更好。

没问题。我今天也很不开心。 非常希望这个分支能成为一个永久的固定项目（比如 "bug，bug，问题"）。 只要讨论的形式能在一个建设性的脉络中逐渐稳定下来。
1234567891011...20
新评论