With SUM having a tight timeline and PHX receiving it’s first official pass towards a completed production product, we need to set up some unfortunate but necessary guidelines to follow during the development process
¶ Code Standards
- There is currently a read me in the core repo that contains information about local install, code standards and other things. https://dev.azure.com/clarity-ventures/Phoenix/_git/Projects?path=/readme.md
- We are continuing to bolster this information over the coming week
- These types of things will include
- How/Where to create a new entity
- How/Where to create a customer specific entity
- How/where to create a new pipeline
- How/Where to create a new override pipeline
- How/where to create a new endpoint/dto
- How/where to call a new endpoint and where to get the dto
- How/where to create new components in Remix
- How/where to structure components
- How/where to interconnect remix components/pages
- We understand that these will be new development standards and you may have questions as to effectiveness and ease of implementation vs ramping up
- Ideally we would like concerns to be noted as soon as possible following this procedure
- There has been a SUM/PHX Dev chat created that if you are not on, message Eric or Brandon to be added to
- In that chat @ Eric and Brendan with your current concern
- Due to the timeline our goal will be to triage concerns
- There may be a handful of concerns that need to be addressed immediately and we will work to ensure that they are followed up on as soon as possible to get you unblocked (if you are indeed blocked)
- Ideally you should continue to work the task via the given information and direction if at all possible
- We understand this may cause some concerning and messy code, but again due to timeline, right now we need to deliver functional code that can be refactored once we have delivered on the project
- We will note all of these concerns and anything deemed to be skipped will be readdressed in full in due course.
- Again, this may seem like we are moving in a direction that starts with sloppy code, but reiterating the client timeline is the primary factor in continuing to move forward in development and deliver the functionality that we can improve on later.
- Additionally any noted concerns will ideally get any resolution documented in the read me for future implementation help
Software development is not a perfected art. With many people working on projects and touching the code, different styles, implementations, and skills levels will cause some conversation around resolving the code. None of us are perfect and during code reviews implementation level details may cause a need for
- Waiting for merges
- Who
- When
- Issue reporting and resolution