✅
Phecks
  • User Guide
    • Getting Started
    • Configuration
    • Command-line interface
    • The Baseline
    • Continuous Integration (CI)
  • About phecks
    • The idea behind it
    • What is a check?
  • Writting checks
    • Making a Check
    • Check Sources
    • Pipes
  • Examples
    • Check inspirations
    • Spatie checks
  • Advanced
    • Making sources
    • Making Pipes
    • Formatters
Powered by GitBook
On this page
  • The need
  • The role of Phecks
  1. About phecks

The idea behind it

PreviousContinuous Integration (CI)NextWhat is a check?

Last updated 2 years ago

The need

At , we move forward using an approach called the .

This basically means that whenever we adopt new technology, a new pattern, or a new approach to solve our problems, we don’t refactor the entire codebase at once, but we slowly replace the old implementation with the new one.

This presents a problem: both implementations, legacy and new, share the same codebase. As a result, developers (especially new developers that are not aware of what is legacy and what is not) can mistakenly base their code on old legacy code, simply because they don't know any better.

This bottles up in the PR process, where more experienced developers notice new code done with legacy components, so they leave comments explaining what the latest practices are.

The role of Phecks

Phecks is here to automate the previous process.

Each team is responsible of defining what is legacy and what is not in their codebase, and create the set of that will make sure no new violations are introduced.

Phecks can be run as part of pre-push git-hooks, and/or as a , so it catches problems before they get merged into the main branch.

Studocu
strangler fig pattern
Checks
CI check