Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?

OOP Design workshop

Part 1

  • Initial step: Plan the user story (goals, acceptance tests).
  • Getting familiar with the CEP SOAP API.
  • Test as a documentation for external API usage.
    • Introduce spec/use_cases.
  • byebug as a tool for API learning & discovering.
  • Don't be bothered about duplication while enough use cases are not fully covered yet.
  • Should I use VCR right now? Maybe yes, just for sake of convenience, since setting up response stubs manually can be error-prone (but we can keep it touching the network from now).
    • Most important and valuable thing: keeping real interaction with external services with a good level of integration.
  • Specs description are naturally used as the git commit messages.
  • First red green cycle is done. Time to the first refactoring.
  • Reinforce the importance of 4 phases of test.
  • Reinforce the importance of having minimal code that gets things done (don’t bother about questions like dotenv usage, public api, namespaces, lib vs model, since we’re still maturing knowledge).
    • No code is usually better than good code.

Part 2

Part 3

  • Integrating the CEP API with the CepConsultation service
    • Note that specs & behavior do not change, since, at this time, we have a solid interface established between architecture ports).
  • Working software is done. We have not open the browser since first step on part 2, and everything was conceived from TDD cycle. Code can be shipped to production.
  • Complexity is isolated (CepConsultation), but code is not well factored.
  • Primary code smells:
    • Test suite is slow
    • CepConsultation has many responsibilities (CEP api client, CEP response logic, presentation logic).
    • Boundaries are “violated”.
  • Refactoring techniques: extract method.
  • Listen to your code: FeatureEnvy.

Incidental divagations

  • DPY: Don’t precipitate yourself.
  • The correlation between TDD and automated tests.
  • Some thoughts about git messages:
    • Git messages exposes how you think about your software.
    • If you messages talk about your system and not about your framework, then you’re good.
    • Therefore, do not tell the obvious, let your code do.
    • Talk about your intentions, not the solution.

Incidental references

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.