[C#] werkwijze obsolete code

[PdeBie]

Hoi allen,

Niet echt een technische vraag, maar meer over een slimme werkwijze.

Hoe geven jullie aan dat een bepaalde (al dan niet kritische) functie in je C# code binnen een bepaalde termijn komt te vervallen/wordt vervangen?

Ik gebruik daar nu obsolete voor, zodat het in de warning lijst getoond word. Daarnaast informeer ik andere ontwikkelaars via de mail en pas ik de documentatie (voor zover die er is) aan.

bv.

C#:

[Obsolete("This function will be replaced by <nieuwe functie> no later than 14th may 2013")]

Zodra de termijn is verstreken, maak ik er een error van:

C#:

[Obsolete("This function is replaced by <nieuwe functie> on 14th may 2013", true)]

Is dit een correcte werkwijze? Of zijn hier andere methoden voor? Hoe doen jullie dit?

[ Voor 6% gewijzigd door PdeBie op 14-05-2013 09:26 ]

[Laurens-R]

Ik vind 'm goed

Ik denk eerlijk gezegd dat je dat behoorlijk netjes doet in tegenstelling tot de gemiddelde praktijk.

Ik werk zelf in een omgeving waar de druk vaak nogal hoog ligt. Daar doen we dit toch een stuk minder hoewel het wel zou moeten imho.

[ Voor 35% gewijzigd door Laurens-R op 14-05-2013 09:21 ]

[PdeBie]

Nu moet ik wel even toevoegen dat wij hier maar met 3 ontwikkelaars zitten, dus het informeren per e-mail is niet moeilijk. Probeer het zo min mogelijk mondeling te doen, zodat het 'op papier' staat en het niet vergeten kan worden.

[ Voor 30% gewijzigd door PdeBie op 14-05-2013 09:22 ]

[Laurens-R]

Ik zou dat normaliter ook zeggen over de gemiddelde project teams ... maar dat gaat ook niet altijd op

Kan ook te maken hebben met de scrum master die de gewoonte heeft veel werk in een sprint stopt (focus ligt dan meer op dingen maar 'af' krijgen ipv kwaliteit borgen - op meerdere niveaus)

[ Voor 50% gewijzigd door Laurens-R op 14-05-2013 09:25 ]

[Cyphax]

Ik zou het ook met dat obsolete-attribuut aangeven maar niet met een datum erin. Ik zou dat liever met een versienummer doen denk ik. Datums/deadlines kun je missen, en dan klopt je melding niet meer en weet je wellicht niet wat je moet verwachten.
Op gegeven moment haal je die functie er helemaal uit en zet je dat in je changelog, zodat het niet een overbrugging blijft.

[ Voor 20% gewijzigd door Cyphax op 14-05-2013 09:43 ]

[PdeBie]

Ja, dat is inderdaad nog wel een goeie.

[Corniel]

Wat wij proberen (maar wat vaak niet lukt). Eerst obsolete met warning. Volgende release warning naar error, release erop: methode verdwenen. In praktijk blijft het wat langer een warning. Uiteraard meld je dit ook in de release-notes (if any ).

[YopY]

Staat de code in een of andere publieke, openbare API waar 3rd-party developers aan werken? Zo ja, als deprecated / obsolete markeren en in een volgende major release (2.0) verwijderen.

Zo nee, 'find usages' (hoe dat maar in C# heet) en gewoon alle aanroepen / usages zelf vervangen. Of gewoon verwijderen en de evt. compile / test failures oplossen.

Maar misschien maak ik hier teveel aannames over de opzet en grootte van het project, of jullie werkwijze. Sowieso zou ik zo weinig mogelijk e-mailen; de waarheid staat in de code en je versiebeheer, niet in een email die na een week onvindbaar en vergeten is, zeker bij een teamgrootte van 4.

[decipherer]

Laurens-R schreef op dinsdag 14 mei 2013 @ 09:23:
Ik zou dat normaliter ook zeggen over de gemiddelde project teams ... maar dat gaat ook niet altijd op

Kan ook te maken hebben met de scrum master die de gewoonte heeft veel werk in een sprint stopt (focus ligt dan meer op dingen maar 'af' krijgen ipv kwaliteit borgen - op meerdere niveaus)

Lichtelijk off-topic, maar lees ik hier nu dat de scrum master veel werk in een sprint stopt? Het lijkt me toch dat het ontwikkelteam werk in een sprint neemt. En daarbij de gewenste kwaliteit niet uit het oog verliest. Wij hebben bij de acceptatiecriteria in ieder geval ook zaken staan die de kwaliteit moeten waarborgen.