Ruby devs, how do you work?

Whenever I collaborate and write Ruby code, I feel a little bit powerless

Eh eh I can see that if you're used to IDEs plus statically typed languages. I'm used to no IDE and dynamically typed languages which tend to rely on best practices and "code hygiene" on bigger code bases.

I code in Ruby all day lately, I'm going to comment adding notes about my workflow

The first thing I do when I open a project which is not my daily code base, I scroll around the directories and files, and look around.

The first thing I do in a new codebase is either try to fix a bug or read tests (or both). Reading code around, at least for me, makes it really hard to understand what fits together, mostly because code in editors is listed file by file alphabetically, so it doesn't really help :D

Another technique which I find very helpful is to set a breakpoint, hit it and then use step debugging.

Find all the usages of the class/function we are working in (get to know the context of the work);

Whenever I have to answer the question "where does this method come from" I open the terminal and grep with ripgrep which is super fast.

This does not work in Ruby (and many other interpreted languages), as any piece of code can call any other piece of code.

To be fair "calling any other piece of code" (not sure I understand the full meaning) is probably not a property of being interpreted but likely of being dynamically typed and Ruby having open classes. Ruby has encapsulation though, you can mark methods private and not be able to call them from outside without raising an exception.

Things like dependency injection are not really a thing

Ruby supports it, as all languages do. Maybe the issue here is that developers tend not to use it much and rely on mixins to inject behavior, but you can absolutely pass functions, classes and whatever using DI

How do you find out about usages or definitions of models in code that you did not write, know little about but have to refactor for some reason?

I grep for the methods, as you can see I use ripgrep quite a lot, whatever the language:

➜  history | grep rg | wc -l
     174

Apart from test coverage, how do you make sure you do not break anything when changing something else? Even with test coverage: do you unit test every property call?

Mmm aside from test coverage? You can do manual testing but testing (be it integration, functional or unit) is still the best course of action if you want to shield from regressions.

BTW Ruby kinda has properties (if you mean the getter/setter combo). See attr_accessor. You can also customize its behavior, like custom property accessors in other languages by using meta programming, see define_method

How do you store knowledge in the code about some model, like which properties mean what, which are required during construction, which must exist together etcetera

I'm not sure I understand the question. Is it related to the concept of Java property or property of the application? In the latter case you have tests and documentation.

I fail to understand how to encapsulate something that any other piece of code can extend or modify.

The philosophy is different but you can still use access modifiers to "protect" methods. Ruby supports protected and private and they work fine. You can still call them from outside if you really need to, but at least you need to be explicit about it.

Hope this helps!

It's odd you say "things like dependency injection are not really a thing" and link to an article talking about how someone made a DSL-type dependency injection system. Ruby does a lot of things through dependency injection, it's a fairly common pattern. Many different behaviours can be layered on using that approach and you see it in various forms in different Ruby projects.

One good example is Rails Engines, a way of completely encapsulating a component of a Rails application in a way that's modular. You can plug in an Engine and have new models, views, controllers, and all the supporting code for that Engine, and also a clean way to remove it if it becomes obsolete or unnecessary.

When it comes to finding out about definitions, many modern editors, Visual Studio Code included, have a fairly capable method discovery and backtracking system. This is done through tools like Solargraph that can dig into your Ruby code and make a map of method definitions.

This ties into your question about method arguments. Solargraph can parse out documentation that's in the source and show you how to use any given method. If you write comments in a form Solargraph understands, which is also useful when automatically exporting documentation, it'll give you all the help you need.

As for testing, that's something of an art more than a science. When working on Ruby code you should be aware of the contract that method is fulfilling, implied or express, and work to avoid violating that. This generally means if a method accepts data in a particular form you continue to accept that form, you don't arbitrarily change the rules, and if it emits results in a particular form or forms you commit to do the same.

A good way to verify that this continues to be the case is unit tests, but these can only test so much. If you want to be a sneaky jerk, intentionally or unintentionally, you can change how the method works in a subtle, yet important way. Like you might mangle your arguments with in-place modifiers like gsub! or delete that the test might not notice, but which is against the spirit of the original "contract" where you normally do not "own" arguments you're given, you must treat them gently and with respect, unless you've made it clear in the documentation that you're assuming control of them.

A lot of Ruby boils down to the "Duck Typing" principle, and by extension, the "Duck Method" principle. If your method does exactly what it says on the tin, reliably and predictably, under all the advertised use cases, then it's a valid implementation. It doesn't matter how you do things internally, there's a lot of latitude there. You just need to pay attention to your obligations and work to adhere to those boundaries.

I see that your company likes to utilize the Java ecosystem... To your knowledge, has your company ever made use of JRuby or JRuby on Rails?