Ticket content

• Summary
• Software version
• Reproducible in latest version?
• Environment details: compiler/interpreter, operating system, etc.
• Steps to reproduce
• Expected results
• Actual results
• Screen capture (if relevant)

References

• https://codingnest.com/how-to-file-a-good-bug-report/
• https://testlio.com/blog/the-ideal-bug-report/

General

• 3 different environments: development, staging, production
• Write migrations for schema changes
• Use ORM if possible over raw queries
• Always make it possible for testers to report the version they tested against
  • Simplest is to have a meta field in the head section

Steps

• Mockups
• SRS
• Database and software architecture
• Implementation
• Test/QA
• Deployment

See also

• Software project basics

Nowadays I do not write useful commit messages anymore.
The main reason is that most repositories I work in professionally use squash merges, meaning that all commits done in a branch are squashed into a single commit when merging the branch into the main branch.
The commit message of the squash commit is usually the title of the pull request, meaning that the individual commit messages are not very useful anymore.
The commit message ends up containing the PR description, which gives the what and why of the changes, which is generally enough.

With the rise of LLMs I have never found myself looking at the commit history and the commit messages to understand why things changed.
If something isn't working, I simply get the LLM to help me fix the problem.

Pre-LLMs era

• One liner describing what changed (not period terminated)
• A few lines describing in more details why things changed
• GPG signed commit

How to Write a Git Commit Message

• Separate subject from body with a blank line
• Limit the subject line to 50 characters
• Capitalize the subject line
• Do not end the subject line with a period
• Use the imperative mood in the subject line
• Wrap the body at 72 characters
• Use the body to explain what and why vs. how

References

• https://chris.beams.io/posts/git-commit/

When joining a new project without tests, here is the value you need to provide through the addition of tests:

1. the application works and doesn't crash
2. the application works and supports a few input cases
3. the application works and supports a variety of input cases
4. the application works and is robust to most input cases

• Write a test that tests the common case usage of your function
• Write tests that cover edge cases of your function
• Write tests to cover all statements, branches, paths

LLM-assisted flow

• Use the task background + acceptance criteria as plan prompt (manual)
• Use the planning feature of the agent and let it generate a plan (LLM)
• Review the plan and adjust as necessary (manual)
  • Ensure the presence of tests
• Let the agent implement the code based on the plan (LLM)
• Review the code implemented by the agent (manual)
  • Ensure it meets the acceptance criteria
  • Ensure code quality and standards
• Manually verify that functionality is working as expected (manual)
• Commit code on a branch (manual)
• Push to the central repository (manual)
• Verify that CI passes
• Create pull request (manual + LLM generated description)

Pre-LLMs flow

• Make sure you understand what you have to implement
• Make it work
• Write a test for what you implemented
• Refactor the code for reusability/code standard
• Verify that your code passes linting and tests
• Commit your code on a branch
• Push to the central repository
• Verify that CI passes
• Create pull request
• Annotate code to explain intent of changes