Let's Talk about how you work with your code. from planning to deployment...
For further actions, you may consider blocking this person and/or reporting abuse
Let's Talk about how you work with your code. from planning to deployment...
For further actions, you may consider blocking this person and/or reporting abuse
Weslley Neves -
SameX -
Carlos -
SameX -
Top comments (1)
My approach varies from project to project, but for complex projects, here's my strategy:
I spend as much time as needed ensuring that I understand the requirements.
I will not hesitate to repeat questions ten times if I have to because the implications of not asking are worse.
Then, I go to the whiteboard (or my large notepad sometimes) and start drawing boxes and arrows mapping my understanding of the high-level architecture.
I will validate that with either my manager or the customer
Once the high-level diagram is correct, I will transfer it into a flowchart application (Lucidchart in my case)
Depending on the type of project/client, I will then write a development spec calling out everything about the project starting with the requirements, risks, what's in scope, approach, previous work, what's out of scope, test plan, release plan, dependencies, etc. This phase varies depending on the team/project/client.
Depending on the complexity of the project, I will start to think about the libraries/dependencies that I would like to use for the project.
Then, I will tinker with libraries/frameworks that I'm unfamiliar with.
Finally, I will create the project repo, various environments, databases, integrate everything in a CI pipeline, and start creating work items in an issue tracker.
Now, it's time to code! The bottom line is that I don't write a single line of code until I'm clear about the requirements and everyone is on the same page.
Deployment is usually a breeze as the CI pipeline is created ahead of time and it helps catch most of the issues as they manifest.