Using a Framework will harm the maintenance of your software

Re:Using a Framework will harm the maintenance of your software by hinkley on Thursday October 13, 2022 @01:33AM (#33187607)

In my experience, I lack the talent for truly graphic swearing that would be required to adequately communicate just how much worse it is. Wrapping frameworks is like throwing water on a grease fire. Or maybe like someone else throwing water on the grease fire while you're standing inside the splash radius.

The only way to win is not to play, but the best way to minimize the damage if you can't avoid it entirely is this: escape out of the framework code into 'normal' code as fast as possible. The framework only calls glue code. All of your real logic and investment is in code that uses Plain Old <Language> data structures and that's it. That'll keep you sane.

It also is a great way to pop out bits of your logic into separate little programs where you can do things like write utilities that let you reason about the bigger system in bite sized chunks, or even to use benchmarking tools to do A/B testing of different implementation details of one subsystem, without the noise of the rest of the system getting in the way.

[ Parent | on HN ]

Re:Using a Framework will harm the maintenance of your software by pushedx on Thursday October 13, 2022 @01:39AM (#33187640)

I like your garden path sentence.

[ Parent | on HN ]

Re:Using a Framework will harm the maintenance of your software by pmontra on Thursday October 13, 2022 @04:16AM (#33188534)

On this line of development a customer of mine has a lot of small/medium Rails applications with very little in models and controllers and almost all of it in service and command classes. They use commands for code that does only one big complicated thing and services for bags of simple methods about one resource.

They end up with code like

  class Command
    def initialize(a)
      @a = a
    end
    def run
      s = Service.new(@a)
      s.do_something
      s.do_something_else
    end
  end
  Command.new("a").run

which is funny when I think that in Elixir I would write Command.run("a") and there isn't a good reason for using OO in this case, except that Ruby is very object oriented. Anyway, their code is quite separated from Rails except for the calls to ActiveRecord, but that could be ActiveRecord without Rails.

[ Parent | on HN ]

Re:Using a Framework will harm the maintenance of your software by Joel_Mckay on Thursday October 13, 2022 @04:55AM (#33188746)

Probably a different problem domain, but I like simple BSON message objects over AMQP into rabbitMQ to enforce a producer/consumer linear job queue from a distributed platform... where transactional ordering can on occasion be more important than the latency hit.

Most OTP projects can benefit from a RabbitMQ/kafka message channel, as some jobs may end up visiting several languages, CPU and GPU architectures. =)

[ Parent | on HN ]