Comments by "" (@defeqel6537) on "Why CI is BETTER Than Feature Branching" video.

  1. He has made a video in the past about preferring pair programming, and seeing it as valid continuous code review.
    5
  2.  @jev5  Sounds like a PR would be a good point of contact to get you to align with your team mates. Not knowing what is going on in a PR, and then contacting your team mate, sounds less scary than the changes happening without knowing anything about them at all.
    2
  3.  @jev5  why do you assume the tests cannot get broken? pair programming might work if you can always get pairs that complement each other, or at the very least one elevates the other (though, that usually reduces input from the one) at least personally, I get kind of tunnel-visioned when working on a feature, and code review helps to create that separation and bring my focus on an issue, especially if helped along with a standup
    2
  4.  @DanielSanchez_dsanc89  I've found that talking about your goals and ideas before-hand can help reduce the burden when reviewing PRs. The reviews go from "what is being attempted here" to actually evaluating whether the code accomplishes the intended changes (without side effects).
    2
  5.  @DerDoMeN  Yeah, I'm not sure I agree with him on that, but lacking the experience, I couldn't really say.
    1
  6. That's part of what I consider as the danger of "Agile". Not going slow enough to enforce a) good architecture and a.2) good tests, so you can b) refactor the code into something more manageable. We have that issue too, to some extent; "chasing the feature", where the constant push for having features done by X date (only to have the specification change later), and then pushing on more and more feature without giving the code a chance mature. It takes real effort and confidence from the team to say "no, we cannot do that and keep our code clean enough to be workable next year too".
    1
  7. A) We are pretty much stuck with feature branches on an organizational level - we are trying to keep our branches small and frequent though (still not perfect, but we are improving), in the end, communication is key here whether on the individual feature-branch level or when talking about the "complete" feature and the plans for it B) I fear CI is too straightforward (for a lack of a better word) - you either need really good pairs programming together to avoid silly and/ or hard to find bugs creeping in, especially as less capable developers are just as capable of breaking tests as any other part of the code - you miss that part of separation that a pull request and review gives you; this is personal, but I can better focus on reviewing changes and trying to figure out what they affect when I go into code review for a (small[ish]) PR. This is also true of my own PRs. This, I think, is especially true when your code deals with multiple concepts that you need to mentally context switch from. I'm fully willing to accept that this might be my prejudice talking, since I haven't really been involved in a real CI project thus far. edit: I do adore your videos though, including this one
    1
  8. You are basically describing what he did in the video though.
    1