Scenario: someone asks for feedback on this piece of code where they want to centralize object instantiation to solve the problem. In their mind they use defensive programming to make sure we do not cause errors. The person is driven and likes to communicate.
In a team, we are asked to strive to reach consensus for how to tackle technical challenges and encourage collaboration and open discussions.
Everyones opinion carries equal weight, in discussion about the review someone on the team says that the nested if-statements makes the code hard to read and suggests that we break them into early returns instead.
Someone read an article about SOLID and suggests that it tries to tackle too many responsibilities and suggests that we break logic into standalone functions with clearer names such as TryToAddDependencyIfParent(...). Everyone on the team seems happy with contributing to making this code great.
I suggest that this code is missing the bigger picture, that we should strive to make object lifetime deterministic. That we need to be clear on errors and what happens when we don't follow the happy path.
People on the team don't understand.I phrased it wrong, it didn't get enough traction. Someone believes they understand my concern, and suggests we change the function to bool TryCreateEntity(...). The Team is happy of having built a solid solution to the problem as a group and incorporated everyones oppinion into the final solution, we have built something great together.
GO TEAM!
public void CreateEntity(GameBlueprint blueprint)
{ if (blueprint != null) { if (blueprint.Template is GameObject prefab) { var instance = Object.Instantiate(prefab); if (instance.TryGetComponent(out GameEntity entity)) { if (entity.transform.parent.TryGetComponent(out GameEntity parent)) { _system.AddEntityDependency(parent, entity); } _system.NotifyEntityCreated(entity); } } } }
Inga kommentarer:
Skicka en kommentar