(Discussion) New PoGo file structure proposals

[jakubsuchybio]

Ok, so I made 3 proposals for structuring new PoGo Repo(s).

Main goals that STApps want to accomplish with this:

• Keep api and app code separate to avoid people messing with the api
• Add unit tests to the api without bloating the main project

I am adding them as separate posts, so everyone can upvote/downvote them. But please when you do, explain in the comment why you think that. Thanks!

Also in second and third I didn't include other dirs as in first one, but they will definitely be there.

[jakubsuchybio]

PoGo (repo)
    .github (folder for .md templates for github)
    ... gitignore and other git stuff
    packages
        ... all nugets
    modules
        PoGo-API (submodule)
    PoGo
        PoGo.csproj (reference to ../modules/PoGo-API/.../PoGo-API.dll)
        ... sources
    PoGo.Tests
        PoGo.Tests.csproj
        ... tests
    PoGo.sln

PoGo-API (repo)
    .github (folder for .md templates for github)
    ... gitignore and other git stuff
    packages
        ... all nugets
    PoGo-API
        PoGo-API.csproj
        ... sources
    PoGo-API.Tests
        PoGo-API.Tests.csproj
        ... tests
    ... Other API helping projects
    PoGo-API.sln

[jakubsuchybio]

PoGo (repo)
    PoGo
        PoGo
            Pogo.csproj
        PoGo.Tests
            PoGo.Tests.csproj
        PoGo.sln

    PoGo-API
        PoGo-API
            PoGo-API.csproj
        PoGo-API.Tests
            PoGo-API.Tests.csproj
        ... Other API helping projects
        PoGo-API.sln

[jakubsuchybio]

PoGo (repo)
    PoGo
        PoGo
            Pogo.csproj
        PoGo.Tests
            PoGo.Tests.csproj
    PoGo-API
        PoGo-API
            PoGo-API.csproj
        PoGo-API.Tests
            PoGo-API.Tests.csproj
        ... other API helping projects

    PoGo.sln
    PoGo-API.sln

[robertmclaws]

So, here is my suggestion, based on managing a 50K+ LoC project by myself for the last 5 years.

Principles:

• Keep It Simple.
• Keep It Clean.
• Keep It Functional.

Observations:

• No one besides @ST-Apps and @WallyCZ really mess with the API Client library. So putting it in a separate repo only increases complexity w/o solving any pressing issues.
• Gameplay logic has a very specific set of requirements, because there is an official app we're trying to replicate. Much of that logic is separate from managing the UI elements, and should not need UI interaction/manipulation to be testable. This gameplay logic has the biggest risk for devs checking in code that breaks things that could get users banned.
• The project needs LOTS more unit tests to ensure stability between checkins.
• Features need specs so that other devs don't check code in that runs counter to the feature's intent.

Given all of that, I propose the following structure for the Repo and the Solution:

Repo Structure:
PoGo (Repo)
   - docs (specs & to-do lists)
   - packages (excluded)
   - reference (screenshots, official app assets, etc)
   - src
      - Google.Protobuf
      - PoGo.ApiClient
      - PoGo.GameServices (or GameEngine(s) if you think that is better)
      - PoGo.Windows
      - PoGo.Tests.ApiClient
      - PoGo.Tests.GameServices
      - PoGo.Tests.Windows
      - PoGo.sln
      - PoGo.Api.sln (If necessary)

Solution Structure:
PoGo.sln
   - Core
      - Google.Protobuf.csproj
      - PoGo.ApiClient.csproj
   - Tests
      - PoGo.Tests.ApiClient.csproj
      - PoGo.Tests.GameServices.csproj
      - PoGo.Tests.Windows.csproj
   - Windows
      - PoGo.GameServices.csproj
      - PoGo.Windows.csproj

A dotted folder structure helps denote functionality while maintaining a reasonable sort order. Separating source from other stuff helps keep the repo clean. And reducing the nesting structure means my local GitHub folder doesn't look like d:\GitHub\PoGo\PoGo\PoGo.

In this structure:

• The PokemonGoAPI is renamed to PoGo.ApiClient (because this code is not the server-side API itself, it's the client-side implementation).
• The GameClient and non-UI-related game "helpers" are factored out into PoGo.GameServices. This allows them to be instantiated and tested outside the context of a UI app.
• PoGo,Windows simply becomes the project that connects the Views and ViewModels to separate, fully-tested game logic, and provides OS-specific enhancements.

If this next round of dev focuses more on structuring well for testing, we can have CodeClimate (or something else) run the unit tests before the PR can be accepted.

That's my $0.02. HTH!