The Whiteboard

« first day (1782 days earlier) ← previous day next day → last day (3207 days later) »

10:00 PM

Imagine 100 developers all coding against the same code base, and the discipline required to keep that from flying apart, and you can get a sense why you would need Interface First programming.

user55340

@Ixrec current code base of actual code is about 1k sloc.

Telastyn

In my experience, it means uber-configurable more than "big". Tons of YAGNI ignored (usually because some asshole somewhere is going to need it).

Ixrec

1000 lines? that's it?

Robert Harvey

A hundred thousand lines.

user55340

I admit to going overboard with testing in this because I'm handing it off to another team and I want it to be an example for my team.

Robert Harvey

10:00 PM

But that's still pretty small. I single-handedly wrote a program almost that large for NASA. It had about a dozen interfaces in it.

Ixrec

@Telastyn ah, I think that explains it; our stuff is big and our UI is configurable as hell, but most of our software doesn't need to be configurable at a code level

user55340

It's code that is going to go sit somewhere for a few years and not be touched... And you need the next dev to jump into your mind quickly. Standards.

Ixrec

I should really go count the sloc in my project at work

it's gotta be over 100k but I have no idea how much higher

user20683

F*** Word and it's hidden spaces f***ery

Ixrec

WYSINWYG

user55340

10:10 PM

WYGIWYG

user55340

Ps. andDo(print()) in spring-test rocks

gnat

100 developers all coding against the same code base are probably as efficient as would be 20 developers coding against such a codebase split to 5-10 loosely coupled components. But of course enterprise has enough money to hire 100...

Ixrec

and too many conflicting requirements to find a place to split them into components

user55340

There are times a non distributed vcs is called for. Locking files can be good.

user20683

@MichaelT every time someone says merge conflict that video of the brawling legislature comes to mind

Ixrec

10:22 PM

I have a hard time seeing a file lock (on non-binary files) as anything other than a historical curiosity, though maybe I'll run into a use case someday

user55340

If you have small enough units of code and you are making changes - lock them all. No one else changes. Ensured the repo is consistent.

user55340

Others wait for you to complete. Yes, slows down development. Speeds up merges and less merge hell.

Ixrec

doesn't modern version control ensure repo consistency without locking?

ratchet freak

needing a file lock is often a symptom of a god-file

user55340

Lock one file - yes. Lock half a dozen - no.

Ixrec

10:25 PM

in my experience most merges are very simple, and the only times they aren't, they indicate a branch that has drifted way too far from master (and there's one particular guy who keeps doing that...)

ratchet freak

god-component then

Robert Harvey

@ratchetfreak And yet I've heard so many developers say "Locking files exclusively? How can anyone possibly work that way?"

user55340

@Ixrec that question has constant drift of code in. No stablity on the accumulation branch.

Ixrec

???

Robert Harvey

My question is, how can anyone work in an environment where more than one developer works on the same file on a regular basis?

Ixrec

10:27 PM

user55340

Q: Avoid branch conflicts/race conditions with task branches

Background Support and Sprint are the test branches for bugs and tasks Each bug gets a new branch from master, which is merged into Support, when tested good, a pull request is made between the Support branch and master. Each task gets a new branch from master, which is merged into Sprint, when...

Robert Harvey

If only one person ever works on the same file, you don't need merges at all.

Oh, branches.

Ixrec

it's common for us to end up changing the same file on two different branches, but usually it's so minor git can automerge it for us or there's only a few lines of conflict that the slower human can trivially resolve

I can't recall any time we've had two people make major conflicting changes to the same file, except when one guy had way too many changes on a single branch

user55340

And when it's not...?

Ixrec

when it's not what?

Robert Harvey

10:31 PM

Trivially resolvable.

Ixrec

it increases the incentive to get the conflicting branch cleaned up enough to pass code review =)

gnat

@MichaelT I think you gotta love this!

Q: A guide to Code Review for Stack Overflow users

You're on Stack Overflow and you've found a question that seems to be about improving code. You are trying to be helpful, and you put a comment in the question: You should try asking on CodeReview.SE instead. —YourName 2 minutes ago … and suddenly, out of nowhere CodeReview.SE users swoop i...

discussion faq scope migration

I got there following recommendation from Shog...

Also, please read this before you let the words "code review" re-enter your head: meta.codereview.stackexchange.com/questions/5777/… — Shog9 ♦ 15 mins ago

1 hour later…

user55340

11:57 PM

There have been times where I've either done, or been the victim of architectural changes while other work is going on. The type of thing where the entire structure of a package is changing. Suddenly the factory, interface, and a dozen classes all have a good chunk of code changed or the like. Where every active piece of work on that code is invalidated.

user55340

Its times like that when locks are desirable. You lock everything you can until you have the locks on all the files that are going to change, then you change them and commit them.

user55340

Its a semaphore. It keeps the resulting effects sane/non-problematic.

user55340

non locking version control is perfectly ok if none of the changes are interacting with each other or only do so in minor ways.

user55340

As soon as the changes start being significant issues in multiple files, then you might wish for a lock.