3 ms·

No, because they inevitably lack at least one (usually all) of the following: - A working CI pipeline. - Comprehensive tests. - Enforced linting/formatting.

by l0b0 6y ago

No, because they inevitably lack at least one (usually all) of the following: - A working CI pipeline. - Comprehensive tests. - Enforced linting/formatting. - A script (or at least documentation) to set up a dev env from scratch (including resetting it if it already exists). - Documentation of things which would take days or weeks to discover when working without the original developers, such as high-level trade-offs, code style which is not enforceable using linting (such as "Use Foo.frobnicate rather than the built-in frobnicator because …") references to issue trackers, former non-committing project-related people such as business analysts, separate documentation, credentials etc. That said, I keep getting more and more picky about what it means to have a good code base, so in a few years I'm sure this list will be woefully incomplete.

xcubic 6y ago
If you pass along your codebases today, all that is included?
- l0b0 6y ago
  Re-reads Yes. It is a bit of work, but not huge: - Use natural in-repo CI configuration like GitLab and Travis. That way a fork of the project can easily establish an identical pipeline. I can't imagine going back to Jenkins or the like at this point, where the CI pipeline is this massive snowflake waiting to break down, and always being out of sync with the code. - The current code base has 97% coverage which is verified by the CI pipeline. I'll reiterate the old trope about this making the development faster, in no small part because we can do fearless refactoring. - Linters and formatters check the style pre-commit (only changed files) and in CI (all files). - I run a script nightly to reset my dev env completely. It + some documented configuration is all a new dev needs to get started. - Keeping the documentation in the repo makes sure that every change is peer reviewed. That not only sets a minimum bar for the quality but also makes sure at least one other person has already read it once it's available to everyone.

by l0b0 6y ago

xcubic 6y ago

If you pass along your codebases today, all that is included?

l0b0 6y ago
Re-reads Yes. It is a bit of work, but not huge: - Use natural in-repo CI configuration like GitLab and Travis. That way a fork of the project can easily establish an identical pipeline. I can't imagine going back to Jenkins or the like at this point, where the CI pipeline is this massive snowflake waiting to break down, and always being out of sync with the code. - The current code base has 97% coverage which is verified by the CI pipeline. I'll reiterate the old trope about this making the development faster, in no small part because we can do fearless refactoring. - Linters and formatters check the style pre-commit (only changed files) and in CI (all files). - I run a script nightly to reset my dev env completely. It + some documented configuration is all a new dev needs to get started. - Keeping the documentation in the repo makes sure that every change is peer reviewed. That not only sets a minimum bar for the quality but also makes sure at least one other person has already read it once it's available to everyone.