grace-joh / connect_four Goto Github PK

Miro Board

• #initialize - GJ
• #move - TEAM
• #update_board -GJ
• #valid_input helper for move -GJ

• #initialize
• #print_board
• #column_free? - MD
• #full? - GJ
• #win? - MD
  • vertical - MD
  • horizontal - GJ
  • diagonal - TEAM
• #row helper method - GJ

• Player
  • @symbol in #initialize
  • update test
• Computer
  • inherits from Player
  • @symbol in #initialize
  • update test
• Turn
  • refactor #move with #find_valid_space helper
  • test spec Player and Computer
  • remove winner instance variable
• Board
  • test spec Computer
  • remove win methods
• Game
  • remove .instance_of x3
  • win methods now live here

### Presentation points:

• Demonstration of functional completeness

  • Run runner
    • start menu
      • quit /run again
      • invalid
      • start
    • Play Game
    • user wins (invalid input example)
    • play again/reset
    • Computer Win video****
    • Draw video
      • column full at 1:04
      • draw shown at the end

• Technical quality and organization of the code (show Miro)

  • We started with Player/Computer, Board, and Game classes.
    • We built a flow chart to determine how the game plays, loops, and ends with consideration of edge cases.
    • We brainstormed all attributes and methods we might need based on the flow chart and rearranged them by Class.
    • We decided to make a Turn class.
  • Is there a design decision that you made that you’re particularly proud of?
    • Margaret - being able to move the win methods from Board to Game
    • Grace - the overall design process to figure out everything we needed and organizing them by class

• Identifying code that should be refactored and how it would be refactored

  • We asked a mentor to review. He led us to want a Printer class that can take care of any output methods in Game. Also was excited about the extensions in Iteration 4 but did not get to them.
  • Diagonal win method(isn't readable), or all of the win methods?
    • Hesitant about a hash for the board layout structure (maybe use a nested array instead to access each index and count spaces, etc.)
    • Turn class with its relationship with Game and Board

• Discussion of test coverage

  • Examples of a unit and an integration test: The board tests for win? with the horizontal/vertical/diagonal
  • Run your tests

• Discussion of Pairing/version control

  • How did you all work together? Did you use a particular pairing technique?
    • Driver/Navigator, but also split tasks
    • Document all ideas and decisions with Miro/Project Board, made PR template to communicate our addition/changes, communicated with daily standups and multiple check-ins
  • Walk us through your GitHub insights.
    • 28 PRs
  • How many commits did you make?
    • 71 + 62
  • Can you identify a PR that was made that demonstrates good commenting/partner review workflow?
    • PR # 7

Branch names

initials-class_method

Commit Messages
"feat: Add #method to Class"
"test: Add test for Class #method"

Begin the commit message with the type of the commit followed by a : and brief description.

Types of commits include:

fix - use if committed code is fixing a bug(broken code).
feat - stands for feature. This will likely be your most common type that you use. It should be used for any new functionality that is committed.
test - use if committed code is adding test functionality.
refactor - use if updating and/or removing existing code.
docs - use if updating your readme.
Examples of good commit messages:

fix: Broken calculation for percent high ranking cards
feat: Add shuffle to deck
test: Add test for shuffle

PR Descriptions

## Describe your changes
- 
- 

## Checklist before requesting a review
- [ ] I have performed a self-review of my code.
- [ ] I have added/updated corresponding tests.

Functionality Checklist

This checklist summarizes all of the functionality you are expected to build. This will be used to assess the completion of your project:

• Welcome:

  • A welcome message is displayed (can be combined with Main Menu)

• Main Menu:

  • User is shown the main menu where they can play or quit (can be combined with Welcome)

• Setup:

  • A new game board is displayed
  • The player is asked to place their first piece.

• Gameplay:

  • The player places their first piece in a valid column.
  • The computer places their first piece in a randomly selected valid column.
  • The player and computer take turns placing a piece until an endgame condition is met.
  • The game board is updated after each piece
  • A player attempting to place a piece in an invalid column prompts user to enter a valid column, except in the case of a draw

• End Game:

  • The player connects four of their pieces horizontally, vertically, or diagonally.
  • The computer connects four of their pieces horizontally, vertically, or diagonally.
  • The player cannot select a valid column.
  • The program reports the appropriate endgame status
  • Game returns user back to the Main Menu

https://backend.turing.edu/module1/lessons/inheritance

• #initialize
• #random_input

• #initialize
• merged to main branch

• #initialize
• #output_start
• #output_welcome
• #output_goodbye
• #output_end_game
• #output_play_again
• #output_turn
• #output_invalid
• #play - team

• rough draft
• updated draft
• final draft (after going through all the code)

Rough Draft