今日推薦開源項目：《程序員如何優雅的掙零花錢: 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/
