Fråga:
Hur man hanterar html / css programmerare som kommenterar alla ändringar han gör i CSS istället för att radera dem
LennieCodes
2017-07-14 22:45:14 UTC
view on stackexchange narkive permalink

Jag mentorerar för närvarande en medarbetare som vägrar att radera kod. Han arbetar för närvarande som strikt en html / css-utvecklare, men när han redigerar CSS tar han inte bort koden. Han kommer att kommentera allt som han vill ändra och tillämpa sina ändringar.

Här är ett exempel på vad jag menar: När du blir ombedd att ta bort stoppning från ett element och ändra färg till rött:

  .sampleRule {/ * padding: 20px * / marginal till vänster: 20 pixlar; färg: / * svart * / röd;}  

När jag frågade honom om detta beteende - säger han att han gör det för att dokumentera. Han vill veta vad fastigheterna var innan förändringen gjordes. Han har en designerbakgrund så jag kan förstå hans tänkande, men vår kodbas är full av kod som ser ut så här.

Jag föreslog att han använder källkontroll om han är nyfiken på att visa tidigare ändringar (du kan till exempel använda TFS för att visa alla ändringar som gjorts i en fil).

Jag är för närvarande kod som granskar allt hans arbete, men jag är inte säker på hur jag ska hantera den här situationen. Ska jag prata med min chef? Ska jag ta bort detta beteende när jag ser det? Ska jag lämna det i fred?

Tack för hjälpen.

Ja, vårt företag använder källkontroll.Vi kontrollerar alla ändringar så att han bara kan använda det men han vägrar att göra det just nu.
Att fråga hur problematiskt detta beteende är och om det är tillräckligt allvarligt för att kontakta din chef eller om du bara ska ignorera det är inte en fråga som är lämplig för den här webbplatsen.Detta är inte en programmeringssida, vi är inte här för att bedöma lämpligheten av kodningsvanor.Om du tror att detta beteende är oacceptabelt (och / eller att det tydligt tillåts enligt dina kodningsstandarder) och något måste göras, är svaret tillräckligt enkelt: prata med din chef.
Möjlig duplikat av [Hur man undviker dåliga arbetssätt från anställda] (https://workplace.stackexchange.com/questions/79190/how-to-avoid-bad-practices-of-work-by-employees)
"Jag föreslog att han använder källkontroll om han är nyfiken på att se tidigare förändringar ..." Nonsens.Jag använder också källkontroll, men för snabba ändringar är jag inte 100% på att jag kommenterar saker och sedan tar jag bort dem senare i processen.Till exempel är det idag fredag ... Jag har ändringsförfrågan.Jag gjorde ändringen, distribuerar koden och går hem ... Men jag vill verkligen inte öppna ett nytt webbläsarfönster bara för att granska ändringar när jag kommer tillbaka till jobbet på måndag med ett tydligare, mer vilat huvud.Det är vettigt att behålla "sida vid sida" saker så här tills du är 100% solid.
@Emotive.io, du har nu identifierat två problem - lämnar kommenterad kod på plats och väljer att inte använda ett versionskontrollverktyg.Den andra motiverar den första.Jag kan inte tro att Devs inte introduceras till versionskontroll i den första klassen av någon CS-kurs.Förklara fördelarna med versionskontroll, privata filialer etc. (och kontrollera ändringar med användbara inchecknings kommentarer) och hur det gör hans prestanda bättre.Varför / när gjorde han den förändringen?Se incheckningsskäl och datum.Gjort och där för alla att se, såvida inte på en privat filial.
Hur skulle han ta bort den `color: / * black * / red;` -deklarationen, eftersom CSS-kommentarer inte är placerade?
För att sätta ner foten om det måste du ha det som en standard, inte bara din åsikt, och jag skulle rekommendera att det är din standard.När du väl har det måste han förstå begreppet mentorskap är att lära sig, inte ignorera.
Fyra svar:
curt1893
2017-07-14 22:54:26 UTC
view on stackexchange narkive permalink

Från det jag samlar in använder han källkontroll som alla andra, men snarare än att bara ta bort den gamla koden när han är klar, vill han behålla all den gamla koden som kommentarer.

Detta måste hanteras i en företagspolicy. Om din företagspolicy anger att all gammal kod ska tas bort så att filer förblir så små som möjligt, så är det policyn han ska följa.

Ja, du bör prata med din chef för att se vad företagets policy är. Nej, jag skulle inte ta bort något av hans arbete.

Om det inte finns någon policy och detta bara är din personliga känsla, verkar det som om du bara borde gå med på att inte hålla med. Bara för att du tycker att det här är rätt sätt att koda betyder inte att alla håller med dig.

Om det inte finns någon policy, gör det inte nödvändigtvis det "bara en personlig känsla".Om du tycker att det påverkar kvaliteten på dina leveranser, prata med din chef om det och se om du kan hjälpa till att upprätta en policy.När du gör det, var försiktig så att konversationen inte handlar om personlig smak eller du-mot-kollega.Fokusera på produktens kvalitet och underhåll.Se till att den nya policyn innehåller en lösning för att tillgodose din medarbetares behov av dokumentation.
Du bör flagga detta i Peer Review och inte acceptera det förrän det har fixats.Ett av de många syftena med ett kodgranskningssystem är att bygga och upprätta standarder över förvar.Som en andra åsikt, när det finns ett källkontrollsystem på plats, är någon kommenterad kod rättvist spel för borttagning.
ditt team behöver ett arbetsavtal som också beskriver sådana saker - alla följer avtalet och lämnar det inte upp till en "känsla"
Uh, ingen företagspolicy kommer någonsin att kunna ta itu med * allt * och att använda sunt förnuft bör krävas.Denna "kodstil" är konstig, jag har aldrig sett det förut, och någon kompetent programmerare borde vara överens om att det inte är användbart.Källkontroll är för spårningshistorik, inte kommentarer.
Old_Lamplighter
2017-07-14 22:55:25 UTC
view on stackexchange narkive permalink

Detta är faktiskt en ganska vanlig praxis och "rättighet" eller oriktighet i detta varierar vilt enligt butiksstandarder.

Om det inte finns några butiksstandarder som förbjuder detta, så är det inget fel, om det finns , han bryter mot förfarandet.

Fråga din chef vad butiksstandarderna är för detta och agera därefter.

Om du tycker att dessa borde vara butiksstandarder och inte är det, ta med det till din chefs uppmärksamhet och gör ditt fall att ha det som en etablerad standard att radera kod snarare än att kommentera den.

Oavsett om det finns några "butiksstandarder" eller oavsett om det är en "ganska vanlig praxis", är det i allmänhet en dålig praxis.Att bara kommentera det gamla värdet säger inte varför det förändrades, vilket ofta är viktigare än vad det gamla värdet var.
Det hjälper inte heller att förstå vilka delar av en fil som ändrats vid ett visst ögonblick.Du vet bara vad som fanns tidigare men inget mer.Med källkontroll istället vet du exakt hur koden muterades över tiden.
efarley
2017-07-15 04:38:25 UTC
view on stackexchange narkive permalink

Förord: Jag har varit i fält i 11+ år och har varit ledande team för frontend-utvecklare i 3+ år, ett stort företag som Nike.

Jag håller inte med de tidigare svaren på en några av deras poäng. (Detta antas baserat på det faktum att du sa att du mentorerar honom att du också är hans ledare, om inte och med chef menar du ledarutvecklaren än att lyssna på de tidigare svaren och prata med dem, om med chef menar du en ägare, avdelningschef eller någon annan icke-utvecklare, fortsätt läsa)

För det första: Jag skulle INTE gå till din chef. Du bör se att gå till din chef som ett kärnkraftsalternativ för att vara reserverad som en absolut sista utväg. Din chef hade förtroende för din förmåga att mentorera den här utvecklaren och hantera saker som detta. Varje gång du kommer till din chef för att få honom att hantera något sådant kommer det att urholka lite av självförtroendet. Jag försäkrar dig att din chef har mycket bättre saker att göra än att diktera kodstandarder. Engagera bara din chef om du behöver klargöra något eller saker måste eskaleras till en formell tillrättavisning eller uppsägning.

För det andra: detta är inte ett företagspolitiskt beslut. Kodformatering och kodstandarder är helt enligt ledarutvecklarens gottfinnande. Din chef bryr sig inte eller behöver bry sig om nyanser som formatering och kommentarer.

För det tredje: Detta är inte vanligt, på 11 + år har jag bara någonsin stött på ett företag som skulle göra det möjligt att lämna kommentarer i koden för historia. De enda platserna jag förväntar mig att se den här typen av kodning är en föråldrad butik som ignorerar bästa praxis och har ingen källkontroll, PR eller GIT-repor, och om så är fallet springer KÖR långt borta och titta aldrig tillbaka.

Om jag var du skulle jag först ge honom en rundtur i GIT och visa honom hur det fungerar eftersom han tydligt inte förstår begåvningshistoria. Förhoppningsvis hjälper det att lindra hans bekymmer och får honom att förstå var du kommer ifrån när du säger att du inte ska göra det och det kommer att vara slutet på det.

För det andra skulle jag vägra att godkänna någon av hans PR tills han följer dina förslag, du är ledaren, så led. Om koden inte uppfyller dina standarder ska den inte slås samman, så enkelt är det.

Om han ändå vägrar att ändra det och låter sina PR-personer sitta för evigt medan du blockerar det, är det dags att prata med din chef om utvecklaren. Kanske låta chefen be honom att lyssna på dig, eller skriva upp honom eller eventuellt till och med uppsägning beroende på hur han reagerar och hans övergripande prestation.

Du är hans mentor och om han vägrar att lyssna på din mentorskap så gör han inte sitt jobb och hindrar dig från att göra en viktig del av dig. Kom ihåg om du är chef känner att den här utvecklaren inte lär sig någonting eller lyssnar på dig och du inte har sagt något till din chef, så det reflekterar dåligt om dig inte utvecklaren din mentorskap.

Slutligen, om ditt företag inte använder GIT eller PR (pull-förfrågningar) är det ett mycket större problem än utvecklaren som lämnar kommentarer och du borde trycka på att få företaget att följa moderna bästa metoder som förhindrar problem som detta eller börjar köra bort och leta efter ett jobb som kommer att vara mer fördelaktigt för din karriär.

Ghosts
2017-07-15 00:40:25 UTC
view on stackexchange narkive permalink

På många språk är detta en ganska bra praxis, åtminstone tillfälligt, eftersom det gör att ändringar enkelt kan återställas och andra i kodbasen kan se den senaste utvecklingen och de förändringar som inträffat. Det är dock lite konstigt att göra det i CSS där förändringarna är ganska små och lätta att byta runt och det är vanligtvis lätt att omedelbart se förändringar.

Trots det är det inte ovanligt, men vad skulle vara ovanligt lämnar kodkommentarerna efter ett tag. Jag skulle bara säga till honom att det är bra men efter att ändringarna har gjorts och han bestämmer att de är bra att stanna, gå tillbaka och ta bort kommentarerna. Det finns egentligen ingen anledning att de behöver vara där om ändringarna accepteras och förväntas stanna.

Det kan också vara en bra idé att lägga till ett verktyg för att minifiera filerna och ta bort kommentarer innan distribution, på det här sättet spelar ingen roll i teknisk mening om filerna är större eller om hans kommentarer kvarstår. Det är inte ett botemedel mot källan till problemet utan en bra åtgärd för att förhindra dess effekter.

Definitivt går hela fördelen med att flagga de senaste ändringarna helt bort om koden täcks av dessa flaggor.
Jag kan inte föreställa mig att detta är bra att göra med tanke på att saker som git kommer att täcka väskan helt och 10000% mer elegant.Håller han kommentarer efter en andra / tredje förändring?Det räcker för att få mina ögon att blöda genom att bara tänka på att försöka behålla en sådan sak."Jag ska bara till Ctrl + F där den här stilen tillämpas ... 1000000 kommenterade resultat .."
Det är OK att kommentera koden medan du arbetar med den, men inte när du gör ändringarna.Alla system för förändringskontroll ger bättre metoder för att göra allt du listade."Tillfälligt" är bra, men det blir "permanent" när du gör det.


Denna fråga och svar översattes automatiskt från det engelska språket.Det ursprungliga innehållet finns tillgängligt på stackexchange, vilket vi tackar för cc by-sa 3.0-licensen som det distribueras under.
Loading...