Habr staat vol voorspellingen en tips over wat te doen volgend jaar - welke talen te leren, in welke sectoren je je moet verplaatsen, hoe om te gaan met je gezondheid. Het klinkt inspirerend! Maar elke medaille heeft twee kanten, en we struikelen niet alleen over iets nieuws, maar vooral over datgene wat we elke dag doen. 'Waarom heeft niemand me gewaarschuwd!', roepen we gefrustreerd, meestal tegen onszelf. We trekken de aandacht naar onszelf - we hebben een lijst samengesteld van dingen die je NIET moet doen in 2020 (of misschien altijd).
En de zwaartekracht werd niet gevraagd
We zouden graag de anti-aanbevelingen op volgorde willen zetten, van het belangrijkste tot het minst belangrijke. Maar ze zijn zo wijdverspreid, gelijkwaardig en bekend dat we het in willekeurige volgorde zullen schrijven. Dus, zullen we de lijst doornemen?
Ga niet in IT werken als alles goed gaat
Leer geen nieuwe technologie om van beroep te veranderen of helemaal opnieuw te beginnen. Onze tijd is geweldig omdat je kunt leren, van baan kunt veranderen, zelfs hele velden kunt veranderen - en dat kan tot aan je pensioen. Het is een geweldige, verleidelijk idee. Maar als je ouder bent dan 28-30, is het niet verstandig om alles op te geven om in de IT te komen of naar een nieuwe stack te gaan (bijvoorbeeld als je hoge belastingssystemen in Java ontwikkelt en plotseling besluit om over te stappen naar neurale netwerken in Python). De reden is eenvoudig: het zal niet gemakkelijk voor je zijn. Ten eerste is er grote concurrentie vanuit de specialisten die al vanaf het begin van hun carrière met deze stack werken, ten tweede zul je opnieuw junior moeten worden met een laag salaris, en ten derde zal het moreel moeilijk zijn om een ondergeschikte van het laagste niveau in de hiërarchie te worden. Dus, als je een andere kant op wilt, probeer dit dan te doen binnen de mogelijkheden van je huidige werk en taken, of ontwikkel nieuwe kennis als een hobby, werk aan een pet-project, zodat je bij een nieuwe baan niet meer junior bent.
Veranderen van stack verspilt alleen tijd
Spring niet tussen technologie-stacks voor je ontwikkeling. Als je een project op een bepaalde taal schrijft, een specifiek framework en bibliotheken gebruikt, is het niet verstandig om alles overboord te gooien en opnieuw te schrijven in Dart, alleen omdat het je interessant lijkt. Maak het je regel om een onderbouwing te vinden voor het wijzigen van technologie - niet alleen op het niveau van 'ik wil-ik kan niet', maar ook op financieel en technisch niveau.
Standaard niet je ideale visie en word niet verstoft
Vastzitten aan één taal of technologie en niet nieuwe te leren is net zo extreem als elke keer je stack te veranderen bij een nieuwe technologie. Blijf nieuwe bibliotheken en frameworks leren, wees niet koppig in de veronderstelling dat alles al beter is bedacht en enkel door jou is verfijnd. Bijna elke taal krijgt voortdurend updates die je project aanzienlijk kunnen verbeteren. Wees niet lui en volg de dynamiek van je stack, en zodra je iets geweldigs en nuttigs vindt, breng het dan met vertrouwen in je project!
Eigen hoofd is goed, altijd goed
Denk niet met de hoofden van anderen, je eigen is beter. Helaas zitten sommige ontwikkelaars en wachten af totdat ze de opdracht krijgen om van de vorige fout tot het einde te coderen, zonder te proberen iets van zichzelf in het project te brengen, een nieuwe functie te ontwikkelen, te testen en voor productie voor te stellen. Waarom zou je je moe maken als er altijd een teamleider of bedrijfsleider is die alles zelf oplost? Als je jezelf hierin herkent, hebben we slecht nieuws: een passieve houding helpt je niet in je carrière of ontwikkeling. Je hebt de kans om je vaardigheden als ontwikkelingsingenieur uit te proberen, en niet als een coder in een echt project, en te begrijpen waar je naartoe moet en wat ontbreekt, maar je kiest ervoor om je tijd aan iets anders te besteden en precies van 'dit tot dat' te doen. Diegenen in de moderne IT overleven steeds minder, kom uit de anesthesie.
Gebruikers zijn verschrikkelijke mensen
Overwaardeer de gebruikers van je software niet: als je niet voor programmeurs schrijft, moet je ermee rekenen dat het programma zal stuiten op onbegrip. De eerste paar dagen of weken zal de gebruiker je software haten, omdat "de oude niet zo stom was". Om dit te voorkomen, maak geweldige documentatie en leerzame materialen. Bij installatie of aankoop, geef duidelijk aan dat handleidingen moeten worden gelezen voordat je aan de slag gaat met het programma, en niet pas na de crash van de database, het verlies van een wachtwoord en zelfcontrole.
Overschat gebruikers ook niet: ze zijn slimmer, slimmer en nieuwsgieriger dan je denkt. Als je denkt dat die bug met het variabele formaat en de uitzondering bij de 138e Enter-toetsdruk met een interval van een seconde niet opduikt, heb je het mis - ze zullen opduiken en de werking van je applicatie op de vreemdste manieren beïnvloeden. De regel van de amateur werkt: juist hij doet de tests het beste. Maar om de een of andere reden hebben gebruikers geen zin om bugs in productie te vinden - er is geen IT-solidariteit. Kortom, hoe zekerder je bent van je software, hoe beter. Uiteindelijk is het beter om de release van bepaalde functies uit te stellen dan ze toe te voegen aan een werkende applicatie en deze plotseling onbeheerd achter te laten.
Stop met googelen!
Stop met alleen maar naar Google te verwijzen. Ik ga er niet eens over discussiëren - in de ontwikkelingswereld kun je met een directe zoekopdracht naar de zoekmachine heel veel vinden. Hoe dieper je in je zoektocht naar informatie graaft, hoe meer "zijdelingse" gegevens je zult krijgen en meer zult leren, omdat je iets nieuws leert dat niet gerelateerd is aan je oorspronkelijke zoekopdracht, maar waarschijnlijk in de toekomst nuttig zal zijn. Maak gebruik van volledige materialen, boeken, artikelen, enz. Talen en bibliotheken hebben specificaties, gemeenschappen, how-to's en zo krijg je de meest betrouwbare manier om programmeervaardigheden te ontwikkelen - gewoon de documentatie lezen in plaats van op zoek te gaan naar lokale oplossingen en codefragmenten van anderen. Wat als jouw oplossing optimaler, sneller en beter is?
Vertrouw, maar controleer
Gebruik geen bibliotheken en frameworks die door derden zijn ontwikkeld zonder de code te controleren en aan te passen aan jouw doelen. Je hebt geen reden om deze auteur van de code, die je helemaal niet kent, onvoorwaardelijk te vertrouwen. Ja, verschillende opzettelijke schadelijke elementen in externe code komen niet zo vaak voor, en je hoeft niet in paranoia te vervallen, maar blind het kopiëren van kant-en-klare softwareonderdelen naar jouw project kan leiden tot onvoorspelbare gevolgen. Lees en analyseer dus zeker de code voordat je deze gebruikt en voer testen uit na de implementatie van de code.
Maak back-ups!
Stop not backing up or keeping backups on the same third-party servers where your project is hosted. Think it's a funny and unnecessary piece of advice? More than 700 participants in a Telegram chat, who recently faced an unfortunate situation with the shutdown of a well-known data center, did not think so — there were all sorts of projects: from pet projects to major sites of government bodies and corporate 1C and billing databases. A significant portion was without backups or had backups stored there as well. So distribute risks and store your backup at least on the primary hosting, on a reliable VDS, and on your local server. In the end, it will be much cheaper.
Stop bringing your own issues at the expense of the project
Don't do in the working project what you want, but do what the clients need. Yes, it's incredibly interesting and great to create your own neural network, train it, and implement it into your software, but if your clients need a simple contact manager, that would be an unnecessarily expensive luxury. Look at how the project works, read the documentation, read reviews and requests from clients, and implement what will add business value to the project. If you want to create something scientific or overly complicated, start with your own project.
Not code, but a bundle of nerves
Don't write unreadable and undocumented code. We're familiar with this trick: a developer writes code however they feel like, intentionally makes it a little confusing so that none of the colleagues can understand it — a sort of preventive revenge before something happens. However, you put at risk not only the company (which pays you for your work) but also yourself: it's quite likely you won't remember what you meant with this unintentional obfuscation. The same goes for undocumented code: relying on your logic for naming variables and functions and good memory, after a couple of years, you may not remember why you chose this specific loop, method, pattern, etc. Documenting code and having a good structure is a great service to colleagues, to the employer, and most importantly, to yourself.
Keep it simple, stupid
Verander de code, oplossingen en projecten niet in onnodige complexiteit. Maak geen ingewikkelde structuren en genereer geen entiteiten zonder wezenlijk belang. Hoe complexer uw code, des te meer wordt u er een slaaf van — het wordt voor u zeer moeilijk om deze te onderhouden en verder te ontwikkelen. Natuurlijk is het beroemde KISS-principe («Keep it simple, stupid») niet altijd van toepassing, maar het is niet voor niets bedacht: eenvoud en elegantie van code zijn de sleutel tot haar succesvolle toepassing en hergebruik.
Bescherm uzelf
Negeer de veiligheid niet — in 2020 is dat letterlijk crimineel. Zelfs als uw bedrijf, uw ontwikkeling en u zelf niet interessant zijn voor kwaadwillenden, kunt u toch geconfronteerd worden met problemen die verband houden met een segment van het netwerk, de hostingprovider, een aanval op het datacenter, het stelen van e-mailwachtwoorden en onveilig gedrag van medewerkers die gegevens uit het bedrijf kunnen stelen, klanten kunnen afpakken of de programmatuur van het hele project kunnen saboteren. Als het binnen uw macht ligt en tot uw competentie behoort, probeer dan de projecten die u beheert te beschermen. Houd bovendien uzelf aan de informatiebeveiliging; dat heeft nog nooit iemand kwaad gedaan.
Spuug niet in de put
Verraad uw werkgever niet. Tegenwoordig hebben communicatiekanalen een niveau bereikt waarin bijvoorbeeld alle HR-werknemers in de stad elkaar op afstand kennen en elke informatie kunnen uitwisselen in chats en gesloten groepen (zoals helpen bij het vinden van een baan of zeggen: 'Vasili Ivanov, systeemarchitect, heeft voor zijn vertrek alle accounts gewist, back-ups verdoezeld en het netwerk uitgeschakeld, herstel kostte 3 dagen. Neem hem niet aan.'). Uw gedrag zal uitsluitend tegen u werken — en soms helpt zelfs verhuizen naar een andere stad of hoofdstad niet. Zelfs als u met een slechte ervaring vertrekt, bestaat er geen betere wraak dan een waardevolle en geweldige medewerker van een concurrent te worden 🙂 En vooral: volledig onbestraft.
Dat is ook niet de juiste aanpak. Maar zoals de ervaring leert, stoppen we daar niet mee.
Over het algemeen, vrienden, lees de adviezen, maar doe zoals u het beste vindt — immers, echte ontdekkingen worden gedaan wanneer we twijfelen aan reeds openbaarde waarheden. We wensen u een gelukkige nieuwjaar, moge uw projecten succesvol zijn, uw carrière boeiend, uw collega's en leidinggevenden redelijk, en moge het leven in het algemeen goed verlopen. Kortom, op het nieuwe jaar en op nieuwe code!
Met liefde,
team RegionSoft Developer Studio
In het nieuwe jaar blijven we voor u werken en ontwikkelen we een krachtige desktop CRM-systeem. en een eenvoudige en gebruiksvriendelijke helpdesk en ticketsysteem. .
Bron: habr.com
