Tag Info

New answers tagged

7

You shouldn't track bug fixes in the code. It might make sense to track some unfixed bugs in the code, as a warning to other developers that look at that code that it has bugs that you didn't get around to fixing it. Something like: //Currently crashes - see PRJ110-345 myObject.initialize(); But noting in the code that the bug has been fixed is pointless, ...


4

Giving every line of source code a reference to all the tickets that affected it is not feasible. That's simply too much information, and most of it will be outdated soon after you write it. These kinds of comments are valuable, but they should be commit comments in your version control system, rather than code comments in your source files. But if I'm ...


4

If you try to record the fixes in code, you'll end up with a mess of comments over time that will leave the code unreadable. As a minimum, you could record the Jira number - PRJ110-345 - in the comment when checking your code in to eg git, or whichever source control solution you are using. Another option in to use Stash and link that to Jira. That way, ...


5

Yes, this is very acceptable for some more obscure features, especially when they are hidden away in the option menu. Perhaps it's nicer to disable the buttons and add some extra text "this feature on XXX and below" or "this feature works optimal on XXX and above" if it only works partial. No, this is not acceptable on a key function that takes up 75% of ...


1

If the problematic features are available via options, buttons or something similar, you could disable or hide these elements: I expect this to be less frustrating to the user than being offered a feature only to be told "doesn't work". If you know it's not going to work, then don't make it appear like it could. Disabling the option/button will allow you ...



Top 50 recent answers are included