I've just ported one of my D7 modules, Views Contextual Range Filter, to D8. Phew! That took longer than I'd hoped.
In terms of the effort, I'm not referring to us developers having to convert our .info files to .info.yml files. Or that for configuration variables our trusty
mymodule_settings() function now needs to return
system_config_form($form, $form_state) and that we have to do the saving of our config variables ourselves in another function, using the new API that came out of the CM initiative.
Those were the obvious and the easy bits.
I'm talking Views.
At the time of writing, nothing in this lovely porting tutorial prepares a developer for what they'll face when they port a D7 module that interacts in a big way with Drupal's biggest module, Views.
Views, blocks and the config stuff have plunged deeper into OO through Symfony.
If you're an ex-Java developer like me, then for Symfony read Spring (dependency injection, annotations etc) and you should be right… after the initial shock ... And after a few days of poking, trying to figure things out and reworking your code.
If you only know enough OO to get by in D7, then brace yourself for a brush-up. Big time. Expect to see more of the :: symbol and of that function return chaining thingy (->) so popular in Ruby. If you don't know what I'm talking about, then you're getting my point exactly.
With CTools gone and Views Symfonised, we're not just talking symbols and name changes here. Most of your D7 Views code will be broken: your handlers, plugins, argument code… pretty much everything… Some D7 hooks are gone. Some View data publicly available in D7 is now protected, so new access functions are required to get to it and manipulate it.
Finding where to start can be a daunting task in itself. Your D7 class views/handler/views_handler_argument_numeric.inc for instance, looks and feels different and lives in core/modules/views/lib/Drupal/views/Plugin/views/argument/Numeric.php. Makes sense? Not to me either. Not at first.
With their Symfonication, the new Views parts have also adopted CamelCase notation rather than lowercase plus underscores. Yep… We now have double coding-standards. What is the Coder module going to recommend, I wonder?
The good news? Revisiting your old code is an opportunity to get it right the second time. And Symfony is cool.
So, coming out at the other end of that tunnel, your code does shine a little brighter. Cleaner. And ready to take on the future.