今日推荐开源项目：《程序员如何优雅的挣零花钱: howto-make-more-money》
今日推荐英文原文：《Is UML Esperanto for Programmers?》
今日推荐开源项目：《程序员如何优雅的挣零花钱: howto-make-more-money》传送门：GitHub链接
推荐理由：在当今社会, 程序员学习并掌握大量的技能, 除了正常的参加工作, 程序员又有什么方式将自己掌握的技术进行变现呢?这本书将讲述程序员如何优雅的赚零花钱.
今日推荐英文原文：《Is UML Esperanto for Programmers?》作者：codemanship
原文链接：https://codemanship.wordpress.com/2020/04/06/is-uml-esperanto-for-programmers/
推荐理由：统一建模语言 (Unified Modeling Language，UML) 是一种为面向对象系统的产品进行说明、可视化和编制文档的一种标准语言，是非专利的第三代建模和规约语言。本文将探讨UML的相关历史, 以及UML在现代环境中的应用.
Is UML Esperanto for Programmers?
Back in a previous life, when I wore the shiny cape and the big pointy hat of a software architect, I thought the Unified Modeling Language was a pretty big deal. So much, in fact, that for quite a few years, I taught it.In 2000, there was demand for that sort of thing. But by 2006 demand for UML training – and for UML on teams – had faded away to pretty much nothing. I rarely see it these days, on whiteboards or on developer machines. I occasionally see the odd class diagram or sequence diagram, often in a book. I occasionally draw the odd class diagram or sequence diagram myself – maybe a handful of times a year, when the need arises to make a point that such diagrams are well-suited to explaining.
UML is just one among many visualisation tools in my paint box. I use Venn diagrams when I want to visualise complex rules, for example. I use tables a lot – to visualise how functions should respond to inputs, to visualise state transitions, and to visualise conditional logic (e.g., truth tables). But we fixated on just that one set of diagrams, until UML became synonymous with software visualisation.
I’m a fan of pictures, you see. I’m a very visual thinker. But I’m aware that visual thinkers seem to be in a minority in computing. I often find myself being the only one in the room who gets it when they see a picture. Many programmers want to see code. So, on training courses now, I show them code, and then they get it.
Although UML has withered away, its vestigial limb remains in the world of academia. A lot of universities teach it, and in significant depth. In Computer Science departments around the world, Executable UML is still very much a thing and students may spend a whole semester learning how to specify systems in UML.
Then they graduate and rarely see UML again – certainly not Executable UML. The ones who continue to use it – and therefore not lose that skill – tend to be the ones who go on to teach it. Teaching keeps UML alive in the classroom long after it all but died in the office.
My website parlezuml.com still gets a few thousand visitors every month, and the stats clearly show that the vast majority are coming from university domains. In industry, UML is as dead a language as Latin. It’s taught to people who may go on to teach it, and elements of it can be found in many spoken languages today. (There were a lot of good ideas in UML). But there’s no country I can go to where the population speak Latin.
Possibly a more accurate comparison to UML, might be Esperanto. Like UML, Esperanto was created – I think perhaps, aside from Klingon, only one example of a completely artificial spoken language – in an attempt to unify people and get everyone “speaking the same language”. As noble a goal as that may be, the reality of Esperanto is that the people who can speak it today mostly speak it to teach it to people who may themselves go on to teach it. Esperanto lives in the classroom – my Granddad Ray taught it for many years – and at conferences for enthusiasts. There’s no country I can go to where the population speak it.
And these days, I visit vanishingly few workplaces where I see UML being used in anger. It’s the Esperanto of software development.
I guess my point is this: if I was studying to be an interpreter, I would perhaps consider it not to be a good use of my time to learn Esperanto in great depth. For sure, there may be useful transferable concepts, but would I need to be fluent in Esperanto to benefit from them?
Likewise, is it really worth devoting a whole semester to teaching UML to students who may never see it again after they graduate? Do they need to be fluent in UML to learn its transferable lessons? Or would a few hours on class diagrams and sequence diagrams serve that purpose? Do we need to know the UML meta-meta-model to appreciate the difference between composition and aggregation, or inheritance and implementation?
Do I need to understand UML stereotypes to explain the class structure of my Python program, or the component structure of my service-oriented architecture? Or would boxes and arrows suffice?
If the goal of UML is to be understood (and to understand ourselves), then there are many ways beyond UML. How much of the 794-page UML 2.5.1 specification do I need to know to achieve that goal?
And why have they still not added Venn diagrams, dammit?! (So useful!)
So here’s my point: after 38 years programming – 28 of them for money – I know what skills I’ve found most essential to my work. Visualisation – drawing pictures – is definitely in that mix. But UML itself is a footnote. It beggars belief how many students graduate having devoted a lot of time to learning an almost-dead language but somehow didn’t find time to learn to write good unit tests or to use version control or to apply basic software design principles. (No, lecturers, comments are not a design principle.)
Some may argue that such skills are practical, technology-specific and therefore vocational. I disagree. There’s JUnit. And then there’s unit testing. I apply the same ideas about test structure, about test code design, about test organisation and optimisation in RSpec, in Mocha, in xUnit.net etc.
And UML is a technology. It’s an industry standard, maintained by an industry body. There are tools that apply – some more loosely than others – the standard, just like browsers apply W3C standards. Visual modeling with UML is every bit as vocational as unit testing with NUnit, or version control with Git. There’s an idea, and then that idea is applied with a technology.
You may now start throwing the furniture around. Message ends.
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
