Refactoring Safety?

[samuelgoto]

I was wondering if any thought was put into how this fits with refactoring tools: could this make it easier to break code? For example, suppose I'm about to send data from the client to the server, using this operator:

function sendData(data) {
  const request = { data.x };
  // send request to server ...
  // .. server expects an object with an "x" property, equivalent to
  // const a = { x: o.x };
}

If someone else on my team (think a team of 200 engineers working on this codebase) refactors the data object to change its attribute from x to y, would this cause my request to change its interface with the server?

Without the simplification, such a refactoring would be safe:

function sendData(data) {
  const request = { x: data.y };
  // If one wanted to change the shape of data from "x" to "y", the request shape
  // wouldn't change.
}

More generally, wouldn't this be hazard that teams would try to prevent from usage in style guides? Any anecdotes/experiences in other languages that you'd like to share to mitigate this?

[fuchsia]

You'd have a similar problem with:

const {x,z} = data;
const request = {x,z};

I'd hope a team of 200 engineers would have tests to catch this. ;) And my practice, on renaming a property, is to add an accessor that throws on access to the old name. Or you could "guard" the whole object (set it up to throw on access to undefined properties; it was discussed on the list a while back and I'm finding myself doing it more and more).

But the perils of refactoring javascript are orthogonal to a feature so useful I keep writing it by mistake.