Inb4 sorry if this is cringe or whatever

We don’t do code review

  • 2
  • 11
    @electrineer @irene yeah we don’t, “just make it work” is our motto

    And I’m about to leave
  • 4
    @devTea even if you don't do reviews as a team thing, you should be doing it as a solo thing do check that what you have written makes sense and is clear before adding into the codebase.
  • 3
    @C0D4 I did for my own code
  • 6
    Tdd, test first, clean code, pair reviews can be good tools.
    But like any tool, it depends on the users.

    I know a lot of codebases where they say they do pair review and TDD. And I wouldn't touch it even if I wear a hazmat suit.
  • 2
    @devTea that's better then nothing.
    I find shoving in github, creating a PR and just going down the changes and spot checking everything works well.

    If you don't already I would try and introduce TDD if the code base allows for it, not all codebase are.. hmm wHats the word... well thought through enough to actually have testing added to them without decent refactoring.
  • 2
    @irene It's more common than you might realise. I'd go as far as saying *most* companies probably don't, or it's close to 50-50.
  • 0
    @C0D4 this TDD, does it mean I have to write the unit test along or just a manual testing? Because I always do the latter on every bit of code I’m working on
  • 2
    My place is the same way. I eat spaghetti on a daily basis cleaning up after contractor's absolute garbage code. It's an intern position but I don't plan on staying with the company.
  • 3
    @devTea Strictly speaking, in TDD you have to write your tests and method stubs *before* you write a line of implementation. You then ensure all tests fail, and as you implement more of your solution, more tests pass.

    It *sounds* nice, but I find it a bit utopian in practice. I've done it, but it tends to discourage refactoring your code as you go (since you've already written all the tests to conform to your original design), and I find that to be quite limiting.
  • 2

    TDD is generally code to test that your methods and classes produce the results expected.

    Most people tend to write them after, but it's better practise to write them before your actual code as to know what your code should return and become valid.

    For asp.net (I looked at your profile) you could use this as an example:


    It's always great if you can physically test your product, you can generally automate that with selenium.
  • 1
    @C0D4 @AlmondSauce thanks a lot, I’ll read it. Well I’m going to be solely a front dev *cough* js *cough* next month

    Edit: the link broke
  • 1
    @devTea jest, mocha 😏
  • 1
    @devTea 😐chrome be weird and copied a bogus link.
  • 2
    @irene πŸ˜‚I know what you mean.
    And yes you're tests could actually be wrong, but they should match the requirements and should be testing expected results with predetermined inputs, Not the logic it's self. unless you have methods with a bunch of if statements for some reason which can't be broken down, but then you just add additional tests and data suitable to cater for the branches of logic.
  • 4
    @irene that's why I write my tests after I've proven my code works correctly.🀫

    So much time can be lost writing tests firsts, especially in a place that changes requirements constantly... err I mean "agile".
  • 2
    @irene that's the man problem. Most exampled of Unit Testing are so fucking wrong.
    First, they don't discriminate Unt Testing from Integration Testing.

    Then, the only show basic tests. And no conception. So when you a small portion of your code, the whole test must be changed.

    It's often focused on code coverage, and not function coverage.

    And finally, you should test your tests! Because, having a 100% code coverage, doesn't mean shit.
    Perhaps add test mutation...

    So it can be awesome, few companies do it. And for even fewer companies it's really useful.

    A tool doesn't do shit without proper processes and motivation.
  • 2
    Just make it work.™
  • 3
    @theKarlisK "wE dOn'T hAvE tImE", "BuT iT wOrKeD bEfOrE, We DoN't hAvE tO LeArN aNy NeW tOoLs"
  • 1
    @irene that's the main reason I only enforce Integration tests and end2end tests.

    External explicit interfaces change less often than internal, sometimes implicit ones. And there I can put random and mutation.

    And as we mostly do SOA or MSOA, I mostly enforce UT on pure functions (stateless).
  • 1
    I know your pain.
    I used to work at a very large company the insisted that code reviews were a waste of time.
Add Comment