[HN Gopher] Suture: A Ruby gem that helps you refactor your lega...
       ___________________________________________________________________
        
       Suture: A Ruby gem that helps you refactor your legacy code
        
       Author : mooreds
       Score  : 103 points
       Date   : 2021-09-05 13:30 UTC (9 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | jeremycw wrote:
       | The problem with these types of gems is that they're good for
       | refactoring functional style code that takes an input and
       | produces a result and has "few side effects" as they mention, but
       | this is generally not the type of code you find in an old legacy
       | rails application that you want to refactor. The whole thing that
       | makes these refactors tricky is that they can just write to the
       | db anywhere in a non obvious way.
       | 
       | If you naively go about refactoring something like:
       | 
       | POST /users
       | 
       | Thinking all you need to do is match the output of the current
       | request and match the record it makes in the users table you're
       | potentially missing a ton of side effects you didn't even know
       | about.The problem has always been the side effects and until one
       | of these gems can track and compare side effects in an
       | intelligent way I don't see how they are that useful.
        
         | emodendroket wrote:
         | Really this is what drives me nuts about Rails. You can never
         | really know what exactly any line of code is going to do.
        
           | weaksauce wrote:
           | Do you have an example of such code that does something off
           | label or tricky to intuit?
        
             | emodendroket wrote:
             | Besides the other examples already given, monkey patching
             | is another offender, as are proxy tricks with methods like
             | send or respond_to (technically not Rails-specific but I
             | associate this style with Rails).
        
             | zrail wrote:
             | Active record hooks. Observers especially are a spooky
             | action at a distance factory.
        
             | thih9 wrote:
             | Altering expected framework functionality. E.g. a custom
             | getter method for an ActiveRecord attribute.
             | 
             | Technically this isn't a Rails-only thing; but since Rails
             | relies so much on convention, there are many opportunities
             | to break it (and possibly bring suffering to other devs).
        
           | BurningFrog wrote:
           | Yeah, as much as really like Ruby, there is just too much
           | Magic going on.
           | 
           | I'm a programmer, not a wizard!
        
         | aeontech wrote:
         | You are right, but there are many many methods in any codebase
         | that really are, for all intents and purposes, read-only - ie,
         | get a bunch of data from data sources, stitch it together, and
         | return a json blob.
         | 
         | These tools would make me feel a lot more confident refactoring
         | code like this (actually, right now I use Postman automated API
         | response recordings with a manually extracted dataset of
         | representative query parameters from production logs to
         | validate our changes) - so this indeed looks like it might make
         | my life easier :)
        
           | joelbluminator wrote:
           | How do u stitch your logs params with Postman? And btw arent
           | controller/request tests better for that?
        
             | aeontech wrote:
             | Postman supports dynamic variables for tests [1]. Of course
             | nothing requires you to use postman, you could just as
             | easily script this with just ruby and curb/httparty.
             | 
             | The reason for this is that a lot of api endpoints support
             | a large number of parameters, and we want to be sure that
             | we test a decent sample of real world usage instead of only
             | a few examples that we can think of to implement in
             | controller/request tests.
             | 
             | We can take a month's worth of request logs from
             | production, deduplicate them, run the requests against prod
             | and record responses, then run same requests against stage
             | and verify responses match even after you rewrite half the
             | backing queries. This helps a lot with peace of mind when
             | we deploy :)
             | 
             | For another, more advanced approach to this idea, see
             | traffic mirroring/shadowing [2].
             | 
             | [1]: https://learning.postman.com/docs/writing-
             | scripts/test-scrip...
             | 
             | [2]: https://www.haproxy.com/blog/haproxy-traffic-
             | mirroring-for-r...
        
               | joelbluminator wrote:
               | Thanks for the detailed response! Never heard of this
               | technique
        
       | aeontech wrote:
       | Does anything similar exist in Python ecosystem?
        
         | kevinastone wrote:
         | Laboratory[0] comes to mind.
         | 
         | [0]: https://github.com/joealcorn/laboratory
        
           | aeontech wrote:
           | Thank you, looks very interesting!
        
       | obahareth wrote:
       | This looks really cool! It reminded me of another library I came
       | across a while back, Scientist from GitHub:
       | https://github.com/github/scientist
        
       | danfritz wrote:
       | I follow the readme of creating a seam so you get nice isolated
       | class you can easily test. Then I would suggest to write a lot of
       | tests, understand the code and then refactor and ensure your test
       | still pass.
       | 
       | No need for a gem like this. As others point out for functional
       | small pieces of code this might work but api endpoints I'll
       | rather go with a "add tests" approach
        
         | nerdponx wrote:
         | My impression is that this tool helps you do the exploratory
         | work required to write tests in the first place, as well as
         | helping you split up and rewrite the code to start making it
         | more testable.
        
       ___________________________________________________________________
       (page generated 2021-09-05 23:01 UTC)