我们可以从您最近的灾难性范式转变中学到什么？
偶尔我们会经历一次软件学习经历，这会颠覆我们的假设，我们会从一个全新的角度看待软件开发。 对于我们大多数人来说，最明显的一个问题是向硬核 OOP 的过渡。 您还经历过哪些其他此类地震？您建议我们如何利用您的经验来质疑我们的假设？
编辑：也许对你学到的东西以及它如何改变你的编程有一些建议？
Very occasionally we go throuh a software learning experience that turns our assumptions upside down, and we view software development from a whole new perspective. The most obvious one I suspect for most of us who have been around a while was the transition to hard-core OOP. What other such earthquakes have you experienced, and how would you suggest we might use your experience to question our assumptions?
EDIT: Maybe some suggestions about what you learned, and how it's changed your programming?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
不是最近的，但我是作为业余爱好者开始编程的。 我成为了这方面的专家，通过自学学到了我需要知道的一切。 我上大学获得了两年的计算机科学学位，顺利地完成了课程，但并没有学到任何新信息。 这太容易了，在为留言板做出贡献并看到其他人陷入困境后，我自我评价自己至少是一名与任何 10 年老手一样好的程序员。
于是我得到了第一份编程工作。 当我去敲定第一行代码时，这种代码实际上会被其他人使用，这对我打击很大：我不擅长编写代码。
只是有机会看看别人的代码，听他们谈论 DLL、版本控制、将程序集放入 GAC、设计模式、测试驱动开发，所有这些在大学里没人愿意提及的外国概念我意识到我对编程几乎一无所知。 大学和自学并没有让我为真正的职业做好准备。 事实证明，我可以编写代码来做任何我想做的事情，但我根本不是一个高级思考者，而且我编写的任何代码都非常糟糕。
嗯，6 个月的实际经验解决了这个问题，帮助我改掉了一些坏习惯，并让我对代码实际应该是什么样子有了很好的感觉。 所以，我自我感觉良好，但遇到了一个无法解决的问题：我有一个对象嵌套在另一个对象内部 5 层深处，我希望它通知最外层的对象其状态已更改。 我找不到明显的方法来做到这一点，所以我咨询了一位同事，他借给了我一本关于 Java 设计模式的书。 我读了这本书，它让我大开眼界，让我发现自己错过了多少：有一个我以前从未见过的设计模式世界，为我从未想过的问题提出了优雅的解决方案。
然后它再次击中了我，一直以来我都错过了很多东西，我根本不是一个高级思考者，而我为解决 GoF 书中描述的相同问题而编写的黑客使它甚至显而易见：我不擅长编写代码。
又过了 6 个月，我就成为了设计模式的大师。 我生活在抽象工厂里，呼吸着抽象工厂，长篇大论地抱怨为什么 MVC 远远优于 MVP，向我床边的 Martin Fowler 黄金偶像祈祷。 所以，无论如何，我想通过学习一些额外的语言来丰富我的简历。 我将 Python、C#、Perl 添加到列表中，但我真的厌倦了一遍又一遍地学习相同的东西，而只是语法上的细微变化。 我决定研究一种奇怪的语言，并且我遇到了 Haskell 的一些片段。 在不知道这门语言是什么的情况下，我阅读并发现了一种称为函数式编程的完整编程范式。 只是为了好玩，我学习了一种函数式编程语言（我选择了 OCaml，而不是 Haskell 和 Lisp），它完全改变了我对编程的看法。
在进行了这个小实验之后，我再次意识到：我不擅长编写代码
这个函数式编程的世界是如何在我不知情的情况下存在的？ 为什么没有人早点告诉我这件事？ 想想看，我曾经为自己能够生成数十个 Java 类（实际上是 1000 行代码，创建抽象工厂、具体工厂、访问者等层次结构）而感到自豪。当我精通 OCaml 时，我的应用程序中的行数下降了 20:1。 数十个可能的 Java 层次结构分解为几个 OCaml 联合，所有这些都适合在一个屏幕上。 从那时起我就一直乘坐函数式编程的列车。
这里的教训很简单：如果你认为自己是最好的程序员，那你就很糟糕。 “我知道所有需要知道的事情”的心态是天真的，并且会限制你成为真正优秀的程序员的能力。
Not the most recent, but I started out programming as a hobbyist. I became a whiz at it, learned everything I needed to know by self-study. I went to college to earn my 2-year degree in computer science, sailed through my classes, and learned precisely no new information. It was too easy, and having contributed to messageboards and seeing others struggle, I self-evaluated myself to be at least as a good a programmer as any 10-year veteran.
So then I got my first programming job. When I go to hammer out my first lines of code, the kind that would actually be used by other people, it hit me really hard: I suck at writing code.
Just having a chance to look at other people's code, listen to them talk about DLLs, version control, putting assemblies the GAC, design patterns, test-driven development, all of these other foreign concepts that no one ever bothered to mention in college made me realize that I barely knew anything about programming whatsoever. College and self-study did nothing to prepare me for the real deal. It turns out I could hammer out code to do whatever I wanted, but I was not a high-level thinker at all, and whatever code I churned out was positively awful.
Well, a good 6 months of real-world experience fixed that up, helped to condition away some bad habits, and gave me a good feel for what code should actually look like. So, here I am, feeling good about myself, but I run into a problem I can't solve: I have an object nested 5 levels deep inside another object, and I want it to notify the outermost object that its state had changed. I couldn't figure out an obvious way to do it, so I consult a coworker who loans me a book on Java design patterns. I read the book and it opened my eyes about how much I was missing: there was a whole world of design patterns that I'd never seen before, proposing elegant solutions to problems that I would have never thought of.
And then it hit me again, all this time I'd been missing out on so much, I'm not a high-level thinker at all, and the hacks I wrote to solve the same problems described in the GoF book made it even obvious: I suck at writing code.
Another 6 more months and I was a master of design patterns. I lived and breathed abstract factories, ranted at length on why MVC is vastly superior to MVP, prayed to a golden idol of Martin Fowler next to my bedside. So, in any case, I wanted to boost my resume by learning a few additional languages. I added Python, C#, Perl to the list, but I got really bored learning the same things over and over with just a subtle change in syntax. I decided I'd look at a weird language, and I came across a few a few snippets of Haskell. Not knowing what the language was, I read about and discovered an entire programming paradigm called functional programming. Just for funsies, I learned a functional programming language (I chose OCaml over Haskell and Lisp), and it completely changed how I thought about programming.
After running that little experiment, it hit me again: I suck at writing code
How has this universe of functional programming existed without me ever knowing about it? Why didn't anyone tell me about it sooner? To think, I used to take pride in my capacity to pump out dozens and dozens of Java classes, literally 1000s of lines of code creating hierarchies of abstract factories, concrete factories, visitors, etc etc etc. When I became proficient with OCaml, the line count in my applications dropped by a factor of 20:1. Dozens of would-be Java hierarchies collapsed down into a few OCaml unions, all of which fit on a single screen. I've been riding the functional programming train ever since.
The lesson here is simple: if you think you're the best programmer, you suck. The "I know everything there is to know" mindset is naive and will limit your capacity to become a truly excellent programmer.
测试驱动开发？
Test-Driven Development?
不知道这些是否算作范式转变，但是...
去年当我还在上大学时，它让我大开眼界。
Don't know if these would count as paradigm shift but...
Is a few eye-opener last year when I was still in college.
我们可以了解到，许多花哨的名字只是对老式想法的命名，经过一些修饰和形式化。
We can learn that a lot of fancy names are just names given over to old fashioned ideas that have been spruced up a bit and formalised.
闭包，lambda 函数 ...
closures, lambda functions ...
对我来说依赖注入和控制反转。
Dependency injection and inversion of control for me.
Map 和Reduce< /em>
Map and Reduce
3GL 到 4GL ;)
3GL to 4GL ;)
类型推断。 在对 Java 繁琐、官僚的类型规范装置感到无比沮丧之后，发现 SML 并发现静态类型几乎可以毫不费力地实现，这真是让我大开眼界（并且让我更加更 对 Java 感到沮丧...）。 请注意，从那以后我就没有使用过类型推断语言（通常，我要么不选择语言，要么选择 Python），但是看到可以做什么极大地影响了我的态度关于已经做了什么......
Type inference. After being incredibly frustrated by Java's cumbersome, bureaucratic type-specification contraption, discovering SML and seeing that static typing can be almost effortless was a real eye-opener (and made me even more frustrated with Java...). Mind you, I haven't used a type-inferring language since (generally, either I don't get to choose language or I choose Python), but seeing what can be done has greatly affected my attitude about what is done...