Changes between Initial Version and Version 1 of Ticket #31949, comment 27


Ignore:
Timestamp:
Jan 5, 2023, 2:42:38 AM (23 months ago)
Author:
Carlton Gibson

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #31949, comment 27

    initial v1  
    77As I see it, there are two groups of issue with the current approach:
    88
    9 * The bulk edit means the code in quite a few time not sensitive enough to the individual decorator. Looking at them, couldn't we write this one that way, or that one this way?, is the thought. (I left some more specific comments on the PR itself.) If we address them one-by-one (or in small related groups, likely) we can write the best code for each case. There are repeated patterns and opportunities for code-reuse, but I think extracting them as we go is going to work better than trying to determine them in advance.
     9* The bulk edit means the code is quite a few time not sensitive enough to the individual decorator. Looking at them, couldn't we write this one that way, or that one this way?, is the thought. (I left some more specific comments on the PR itself.) If we address them one-by-one (or in small related groups, likely) we can write the best code for each case. There are repeated patterns and opportunities for code-reuse, but I think extracting them as we go is going to work better than trying to determine them in advance.
    1010
    1111* Related, the tests for each decorator need to live with the existing related tests, not be centralised in one place. Five years hence, when we come to work on the login_required logic, say, we need to be able to open the relevants tests and see them all together. Having to track down a separate set of tests in another part of the test suite entirely would be a maintenance headache. If we address the decorators individually this tendency won't be there.
Back to Top