4 ms·

Minimal change, or minimal code? Refactoring code can make code smaller but depends on good testing. Applying minimal changes results in redundant and complic

• sirsinsalot 3y ago
  In the first instance, both. However, i'd take more code that was better reasoned and easily understood over less verbose code that was smaller for smaller sake. In terms of minimal change, we refactor when there's a clear business case to permit taking on the risk. Otherwise, we make the most minimal, most stable, least risk change to the existing code even if that code isn't optimal/pretty/well-structured/has-errors/... Like most other engineering in the world really.
  • paulryanrogers 3y ago
    IME this can be hard if built on a platform or dependencies one doesn't control, which is common at early stage companies. Because often the dependencies require surfing latest, or close enough, versions to maintain a secure system or avoid stalls for jumping major versions. Sometimes even core languages and standard libraries may require staying at least near latest versions.
    • sirsinsalot 3y ago
      This is true, but in our case all dependencies are vendored and frozen. We _do_ have instances where target systems for deployment become ABI/API incompatible with the libraries, which is rare and happens roughly every 5 years. The project was structured to put stability at the core, rather than being cutting edge.