【问题标题】:What do you consider the 1st principle(s) of programming?您认为编程的第一条原则是什么?
【发布时间】:2008-10-01 19:03:43
【问题描述】:

我总是喜欢问自己“这个的首要原则是什么?”在我学会了一些基本的东西(例如编程)之后。这是一个鼓舞人心的问题,IMO,它可以迫使你思考某事背后最重要的原则,尤其是编程等技能。

那么,您认为编程的首要原则是什么?稍后我会在下面给出答案。

【问题讨论】:

  • 我们不谈论搏击俱乐部。

标签: programming-languages


【解决方案1】:
  1. KISS - 保持简单愚蠢
  2. 干燥 - 不要重复自己
  3. YAGNI - 你不需要它

【讨论】:

  • KISS 应该保持简单智能。当您第一次因为没有设计智能和可扩展性而必须重写大量代码时,您会同意这一点。 :)
  • 我认为 KISS 应该是“保持简单,愚蠢!”
  • 我实际上正在写一篇博客文章,讲述这两个是程序员心中最亲近和最亲爱的两个,同时它们又是怎样的矛盾,就像你经常会看到的那样需要二选一
  • 我还会添加 YAGNI。
  • @Programmin 工具 - 我不认为“愚蠢”是多余的。我认为它传达了我们想要变得“聪明”的倾向,这表现为不必要的复杂性。在我看来,“愚蠢”试图通过帮助我们记住最初认为“聪明”通常不是的东西来提醒我们这种趋势。
【解决方案2】:

编写代码,就像您必须维护该代码一样。

【讨论】:

  • 这是一个非常实用的启发式方法,3x :)
  • 编写代码,就好像一个挥舞着斧头的精神病患者必须维护它一样。 FTFY。
  • ...挥舞斧头的精神病患者知道你住在哪里。
  • ..,他刚刚磨好了他的斧头...
  • ...他在你身边工作。
【解决方案3】:

尽量偷懒。

【讨论】:

  • 再次,太笼统了,IMO。这就引出了一个问题“到底有多懒惰才是适当的懒惰?”,因为显然“马虎”是你也不想成为的东西。
  • 这是对 perl 的“懒惰、急躁和狂妄”的引用
  • 所以我们说的是另一种懒惰?我认为“懒惰”鲍勃的意思是“在它纠结之前不要费心组织你的代码”:D
  • 太笼统了。通过这个类比,所有变量和函数都将是 1 个字母,因为我“太懒”而无法输入有意义的内容。但是,假设我也必须维护它,那么也许您是正确的,因为我会使其尽可能易于维护。
  • @Kyle:是的,这就是重点。 “真正的懒惰”让现在和未来的事情都变得更容易。事实证明,这与正确地做事是一样的。如果你现在做的工作更少但以后工作更多,你就不是“尽可能懒惰”:)
【解决方案4】:

禅,第一部分:编程只是路,不是路。

编程只是教计算机做什么的技术。要成功创建快速、可靠的软件,意味着了解您的算法、最佳实践以及与您的编程(语言)不一定相关的所有其他内容。

禅,第二部分:如果你赶时间,慢慢走。如果实在赶时间,就绕道而行。

听起来很傻,但不要让自己陷入妥协,这(真的)可能会在之后给你带来麻烦。我有一条规则:如果你是一个程序的核心,尽量做到精确和好。如果您正在使用软件深处的核心方法,请尝试加快编码速度。如果你在这两个之上进行编码,你甚至会变得更加草率。

设计错误是最难发现和/或修复的,下一步是每个人都依赖的部分中的编程错误,然后是“真正炫耀的软件部分”。如果您需要在项目结束时修复设计错误,嗯,那可不好... ;-)

禅,第三部分:知道你的路,尼奥。

了解您的环境、工具和您每天依赖的东西,并对其进行分类,使其适合您。如果你使用你的编程“环境”是最好的,你甚至不必去想它。如果你必须完成工作,不要介绍“花哨的新东西”,而是做好你的工作。这些东西可以在新项目中引入,即当你有时间准备和使用它时。

【讨论】:

  • 呃,再说一遍:我在谈论编程时进入了禅境:)
  • @part III - 不要添加“花哨的新东西”,除非你得到报酬!
  • +1 用于矩阵参考。我是一个好人的傻瓜(那个和禅宗。让我想到 Python)
【解决方案5】:

KISS(保持简单,愚蠢)。

它确实提出了一个问题“你如何定义简单?”还有“什么时候对于手头的任务来说太简单了?”这就是为什么你不能仅仅知道编程的第一原则就成为一名优秀的程序员。

【讨论】:

  • 我认为这是一个过于笼统的规则。它引出了一个问题“你如何定义'简单',真的”。
  • 如果你很笨,你怎么知道它是否简单?
  • 这很好,史蒂文 :)
  • “这就是为什么你不能仅仅知道编程的第一原则就成为一名优秀的程序员”——喜欢它。
  • @Dima:你说得对,我的意思是质量和简单性(至少在这种情况下)都是无法定义的,但如果我们的眼睛经过训练,我们就会知道它。跨度>
【解决方案6】:

过早的优化是 一切邪恶。 ——唐纳德·克努斯

【讨论】:

  • 无论是实施还是设计。
【解决方案7】:

不要重新发明轮子。

【讨论】:

  • 关于是否应该重新发明轮子这个问题的正确答案始终是“视情况而定”。所以“不要重新发明轮子”只能到此为止。在大多数情况下,它可能是一种很好的启发式方法,但并非每次都如此。
  • 一些“轮子”需要重新发明。
  • 告诉邓禄普。他发明了充气轮胎。如果不是他重新发明轮子,我们的旅程会很坎坷。
  • 怎么样:只有在收益值得付出代价的情况下重新发明轮子
【解决方案8】:

先搞清楚问题!

【讨论】:

  • 啊,终于有人用这个了。你可以亲吻,yagni,随心所欲地擦干。如果你无缘无故地编程,那是没有用的。
  • @e-satis:是的,这就是我第一次回答这个问题时的想法。我滚动查看所有答案,令人惊讶的是之前没有人发布过。
  • 好答案。如果程序员没有正确理解问题的全部要求,就会浪费很多时间。
  • 问题是:你怎么知道你理解了这个问题?
【解决方案9】:

YAGNI - You Ain't Gonna Need It。 YAGNI 背后的想法是针对您的需求进行编程,而不是针对潜在的功能。前提是,通过保持您需要编程的内容,您将(除其他外)减少代码膨胀,降低复杂性,避免功能蔓延,并减少对可以做什么(以及如何完成)的限制未来。

我想它与模块化设计协同工作:未来的功能可以在不重新设计现有代码的情况下进行扩充。

【讨论】:

    【解决方案10】:

    知道什么时候不要编程。

    【讨论】:

    • 这到底是什么意思?
    • 那是什么时候?
    • 有时您需要以不同的方式解决用户问题 - 而不仅仅是编写解决方案。
    • 人的判断和决策是一切的一部分;有时尝试自动化判断是没有意义的。
    • 他的意思是,通过购买现成的应用程序、组件或库,可以更便宜、更及时地解决许多编程问题。
    【解决方案11】:

    咖啡进,码出。

    【讨论】:

    • 在我的情况下喝茶 =)
    • +1 hmm 更像是“喝咖啡,代码 + 很多厕所休息时间?” :) 我喜欢咖啡和茶,我左右摇摆......
    【解决方案12】:

    如果没有经过测试,那就是坏了。

    【讨论】:

    • 我同意那个
    【解决方案13】:

    有两种构建软件设计的方法: 一种方法是让它变得如此简单,以至于显然有 没有缺陷,另一种方法是做到这一点 复杂到没有明显的缺陷。 第一种方法要困难得多。

    --查尔斯·安东尼·理查德·霍尔

    【讨论】:

      【解决方案14】:
      1. 区分因果关系(使用计算机)

      2. 区分事实和观点(与人合作)

      3. 尽可能简单,但不简单(设计)

      【讨论】:

        【解决方案15】:

        编程是一种手段而不是目的。或者,“可以并不意味着应该”。

        【讨论】:

          【解决方案16】:
          1. 了解为什么该程序会让某人开心(否则,您为什么不在外面和所有其他孩子一起玩?)。 (这个人可以是你。)
          2. 开发一个概念性的业务模型领域,以捕捉所有需要的复杂性,仅此而已。
          3. 开发一个概念性的软件架构模型,以捕获所有需要的复杂性,仅此而已。
          4. 无情地将所有其他复杂性排除在外。

          【讨论】:

          • 说得好!完全同意
          【解决方案17】:

          在我看来,最重要的原则是通过创建良好的抽象降低复杂性

          这包括

          • 了解要解决的问题,
          • 为其设计合适的解决方案并
          • 实现它,
          • 最好以使代码易于理解和维护的方式,

          还要确定停止创建抽象的点,并深入了解实现技术(例如数据库系统、编程语言)的基本属性,以防止产生可避免的额外复杂性。

          【讨论】:

            【解决方案18】:

            节目以观众为中心。因此,不要假设您编写的任何内容都不会被您或其他人阅读和维护。

            由此得出的结论:通过很好地命名变量、函数和类来证明您理解要解决的问题!

            【讨论】:

              【解决方案19】:

              直到你在测试中展示它才起作用

              【讨论】:

              • 这不是真的,我已经编写了很多有效但未经测试的代码! :D
              • “我没有测试过,我只是证明它是正确的”:)
              【解决方案20】:

              先思考,后编码。

              你远没有你想象的那么聪明。问问题。学会珍惜你的同龄人。

              调试时,第一个答案几乎总是错误的。

              您为了抛弃而编写的代码往往会成为更大流程的基石。永远不要随意写任何东西。

              【讨论】:

                【解决方案21】:

                任何问题都可以通过另一层间接解决。

                【讨论】:

                • 其实,过多的间接寻址本身就是一个有待发现和解决的问题。所以..
                • 解决了...通过另一层间接! =)
                • 奇怪的是,它是真的。看看春天...
                【解决方案22】:

                了解你的工具。

                【讨论】:

                  【解决方案23】:

                  原则:软件就是知识获取

                  后果:许多知识表示技术,都建立在抽象之上。为我们提供层、层、封装、关注点分离。

                  许多过程表示技术,均基于顺序选择重复

                  【讨论】:

                    【解决方案24】:

                    为下一个人编写代码。

                    【讨论】:

                      【解决方案25】:

                      始终编写代码,就好像维护它的人是一个知道你住在哪里的精神病连环杀手

                      另外,永远不要认为你对编程无所不知,继续学习

                      【讨论】:

                        【解决方案26】:

                        我是通过学习数字电子学进入编程领域的,所以我猜对我来说,基本的逻辑门(不是,和,或,异或,暗示)是编程的首要原则。

                        【讨论】:

                          【解决方案27】:

                          一切都是为了用户。

                          【讨论】:

                            【解决方案28】:

                            垃圾进 - 垃圾出 如果数据不好,你的用户界面有多好也没关系。

                            【讨论】:

                              【解决方案29】:

                              DRY,几乎所有其他东西都是从它产生的。 KISS 是平衡行为的另一端,可确保您不会将软件优雅追求到疯狂的程度。

                              【讨论】:

                                【解决方案30】:

                                从输出开始,向后工作。

                                【讨论】:

                                  猜你喜欢
                                  • 2016-01-03
                                  • 1970-01-01
                                  • 1970-01-01
                                  • 2019-12-28
                                  • 1970-01-01
                                  • 1970-01-01
                                  • 1970-01-01
                                  • 1970-01-01
                                  • 2016-05-24
                                  相关资源
                                  最近更新 更多