| - Search for unique-looking strings from whatever view you're trying to modify to find the associated html/js file. - Pull up the commit history for the file to see what other files were modified along with it the last few times. This will give you dependencies and linkages. - Make your change and then ask your ide/command line to find all typing/lint errors in your project which will help you find other dependencies you may have missed. - If you get stuck, reach out to the authors or reviewers of previous PRs. (Hint: you may want to include them as reviewers. They'll give good feedback and you'll engender good will by keeping them in the loop when you touch their corner of the codebase) - Write a few solid unit tests. Maybe even clean up the testing code a little bit while you're there. - Write a concise but informative description of your changes in your PR. If you made two or more logical changes, split your PR and stack them. Your teammates will appreciate the shorter PRs and you will get feedback more quickly. - Land the PR in a timely manner and keep an eye on it until it hits prod. - Once in prod, test it yourself and keep an eye on the logs for a day or three. - Bonus: put all changes behind feature flags to do slow rollouts and so you can quickly revert without waiting for a deploy. Make a task to remind yourself to remove the dead code behind the flag in month or so when you're pretty sure it's stable. |