Drie kolommen die zijn overgebleven uit Stats4U 2

De hoofdtabel met tellers heeft hier 166.436 regels en een aantal kolommen die eruitzien alsof ze ertoe doen. Drie ervan zijn lastdomain, firstdomain en userdomain. Er zitten gegevens in:

lastdomain	niet leeg in 15.525 regels
firstdomain	niet leeg in 15.457 regels
userdomain	niet leeg in 2.982 regels

Niets schrijft ze. Nergens in de code staat een opdracht die een van de drie zet. De waarden komen uit de vorige generatie van deze dienst, bevroren op wat ze waren toen die ophield te draaien, en elke regel die sindsdien is aangemaakt, is leeg.

Waarom een halfgevulde kolom lastiger leest dan een lege

Een volstrekt lege kolom is duidelijk dood. Niemand bouwt erop, niemand rapporteert eruit, niemand besteedt er een middag aan zich af te vragen wat hij betekent.

Een kolom die voor 9 % van de regels gevuld is, is een valstrik. Hij ziet eruit als een veld dat soms gevuld is en soms niet — wat voor een kolom volstrekt gewoon is. Wie hem vindt, concludeert redelijkerwijs dat er een regel bestaat die bepaalt wanneer hij gezet wordt, en gaat die regel zoeken. Die is er niet.

En de verouderde waarden zitten niet weggestopt op slapende regels waar ze geen kwaad kunnen. Van de regels die een lastdomain dragen, horen er 1.613 bij tellers die dit jaar nog werden bijgewerkt. Een levende teller met een domein dat tien jaar geleden is vastgelegd, ziet er precies zo uit als een levende teller met een actueel domein.

Erger nog, de gegevens zijn geloofwaardig. Het zijn domeinen, ze zien eruit als de domeinen van tellers, en een bevraging die erop koppelt, geeft regels terug. Ze zou een vraag beantwoorden over een web dat verder is gegaan.

Hoe je het snel vaststelt

Grep naar schrijfopdrachten, niet naar de naam. Een kolomnaam duikt op in SELECT-lijsten, in schemadumps, in oude migraties, in opmerkingen — en dat bewijst allemaal niets. Wat de doorslag geeft, is of enige INSERT of UPDATE hem noemt. Die zoektocht kost een minuut en ze is doorslaggevend op een manier waarop rondlezen in de code dat niet is.

De tweede controle zijn de gegevens zelf: is de nieuwste regel met een waarde jaren oud, dan is de kolom een fossiel, wat de code ook lijkt te zeggen.

Waarom ze er nog staan

Een kolom laten vallen is goedkoop en het is niet gratis. Elk van deze regels hoort bij iemands teller, sommige lopen sinds 2006 onafgebroken, en de veilige stap vóór een schemawijziging op zo'n tabel is een dump die ook werkelijk één keer is teruggezet in plaats van alleen gemaakt. Die oefening is inmiddels gedaan. Tot het laten vallen op zichzelf de moeite waard is, kosten drie ongebruikte kolommen niets dan een ogenblik verwarring, en de hieronder beschreven opmerking neemt zelfs dat weg.

Ze zijn dus in plaats daarvan gedocumenteerd. Er is geen voor de hand liggende plaats voor die opmerking — het schema van deze database bestaat alleen in de draaiende database en in geen enkel bestand in de repository — dus is ze terechtgekomen waar iemand er daadwerkelijk over struikelt: in de klasse die een tellerregel leest, precies waar de kolommen langskomen. Een opmerking in een bestand dat niemand opent, is geen documentatie. Ze maakt van een valstrik pas een voetnoot als ze op het pad ligt.