Habr jest pełen prognoz i porad na temat tego, co robić w przyszłym roku - jakich języków się uczyć, w jakie dziedziny się rozwijać, co zrobić ze swoim zdrowiem. Brzmi inspirująco! Ale każdy medal ma dwie strony, a my potykamy się nie tylko o coś nowego, ale przede wszystkim o to, co robimy każdego dnia. „Dlaczego nikt mnie nie ostrzegł!” wykrzykujemy rozdrażnieni, zazwyczaj zwracając się do siebie. Podejmij decyzję sam – przygotowaliśmy listę rzeczy, których NIE należy robić w 2020 roku (a może i w ogóle).
Ale o grawitację nawet nie zapytano
Chcielibyśmy uporządkować antyrekomendacje w kolejności od najważniejszych do najmniej istotnych. Są one jednak tak powszechne, równorzędne i znane niemal każdemu, że napiszemy je w niewłaściwej kolejności. No to może sprawdzimy listę?
Nie ma potrzeby wchodzić w IT, jeśli wszystko jest w porządku
Nie ucz się nowej technologii, żeby zmienić karierę lub zaczynać od zera. Nasze czasy są wspaniałe, bo można się uczyć, zmieniać pracę, radykalnie zmieniać kierunek studiów – i to aż do emerytury. To coś fajnego i kuszącego. Jeśli jednak masz ponad 28-30 lat, nie powinieneś rzucać wszystkiego, aby wejść do branży IT lub przechodzić na nowy obszar programowania (na przykład piszesz bardzo obciążone systemy w Javie i nagle decydujesz się przejść na sieci neuronowe w Pythonie). Powód jest prosty: nie będzie ci łatwo. Po pierwsze, istnieje duża konkurencja ze strony specjalistów, którzy „siedzą” na tym stosie od początku swojej kariery; po drugie, będziesz musiał znowu zostać juniorem z niską pensją; po trzecie, moralnie trudno będzie ci zostać podwładnym najniższego szczebla w hierarchii. Jeśli więc chcesz się rozwijać w innym kierunku, spróbuj zrobić to albo w zgodzie z obecną pracą i bieżącymi zadaniami, albo rozwijać nową wiedzę jako hobby, pracować nad ulubionym projektem, dzięki czemu do nowej pracy przyjdziesz już nie jako początkujący.
Zmiana stosów na stosy to tylko strata czasu
Nie zmieniaj technologii w trakcie swojego rozwoju. Jeśli piszesz projekt w jednym języku, korzystając z określonego frameworka i bibliotek, nie powinieneś rzucać wszystkiego w diabły i przepisywać go w Dart tylko dlatego, że wydał ci się ciekawy. Uczyń zasadą znajdowanie uzasadnienia dla zmiany technologii – nie tylko na poziomie „chcę – nie mogę”, ale także na poziomie finansowym i inżynieryjnym.
Nie ma potrzeby stawania twardo na ziemi i opalania się
Trzymanie się jednego języka lub technologii i nieuczenie się nowych rzeczy jest tak samo ekstremalne jak zmienianie stosu przy każdej nowej technologii. Koniecznie poznaj nowe biblioteki i frameworki, nie upieraj się, że wszystko, co lepsze, zostało już wymyślone przed Tobą i wykonane wyłącznie przez Ciebie. Prawie każdy język ma stale wydawane aktualizacje, które czasami mogą znacznie udoskonalić Twój projekt. Nie bądź leniwy w monitorowaniu dynamiki swojego stosu i gdy tylko znajdziesz coś fajnego i przydatnego, nie krępuj się przeciągnąć to do projektu!
Twoja własna głowa jest dobra, zawsze dobra
Nie myśl głową innych, twoja własna jest lepsza. Niestety, niektórzy programiści siedzą i czekają, aż otrzymają zadanie napisania kodu od pojawienia się poprzedniego błędu do końca, nie próbując wnieść własnego wkładu do projektu, nie tworząc nowej funkcji, nie testując jej i nie wprowadzając do produkcji. Po co zawracać sobie głowę, skoro masz lidera zespołu lub kierownika firmy, który sam podejmie decyzję? Jeśli znasz siebie, to mamy złą wiadomość: bierna postawa nie pomoże Ci w karierze i rozwoju. Masz szansę spróbować swoich sił jako inżynier ds. rozwoju, a nie programista, w prawdziwym projekcie produkcyjnym i zrozumieć, dokąd zmierzać, czego brakuje, ale wolisz poświęcić swój czas na coś innego i robić dokładnie „odtąd dotąd”. Tacy ludzie przeżywają coraz gorsze chwile w nowoczesnym IT, wychodzą z letargu.
Użytkownicy to przerażające osoby
Nie przeceniaj użytkowników swojego oprogramowania: jeśli nie piszesz dla programistów, spodziewaj się, że Twój program spotka się z niezrozumieniem. Przez pierwsze kilka dni lub tygodni użytkownik będzie nienawidził twojego oprogramowania, ponieważ „stare nie było aż tak głupie”. Aby tego uniknąć, należy przygotować dobrą dokumentację i materiały szkoleniowe. Podczas instalacji lub zakupu należy bardzo uporczywie przypominać, że instrukcję należy przeczytać przed rozpoczęciem pracy z programem, a nie dopiero po awarii bazy danych, utracie hasła i utracie samokontroli.
Nie należy również lekceważyć użytkowników: są mądrzejsi, bardziej przebiegli i ciekawi, niż nam się wydaje. Jeśli myślisz, że błąd związany ze zmienną formatem oraz wyjątek przy 138 naciśnięciu Enter w odstępie jednej sekundy nie wyskoczą, to się mylisz - wyskoczą i wpłyną na działanie Twojej aplikacji w najbardziej dziwaczny sposób. Zasada amatora działa: to amator najlepiej radzi sobie z testami. Jednak z jakiegoś powodu użytkownicy nie lubią znajdować błędów w środowisku produkcyjnym – nie ma wśród nich solidarności ze strony działu IT. Ogólnie rzecz biorąc, im bardziej ufasz swojemu oprogramowaniu, tym lepiej. Lepiej odłożyć wydanie niektórych funkcji na później, niż dodać je do działającej aplikacji i nagle uczynić ją surową.
Przestań szukać w Google!
Przestań polegać wyłącznie na Google. Nie będziemy się nawet kłócić – w sferze rozwoju można znaleźć wiele informacji, pytając bezpośrednio w wyszukiwarce. Im bardziej zagłębisz się w informacje, tym więcej „pobocznych” danych uzyskasz i tym więcej się nauczysz, ponieważ dowiesz się czegoś nowego, niezwiązanego z Twoim zapytaniem, ale prawdopodobnie przydatnego w przyszłości. Zapoznaj się z pełnoprawnymi materiałami, książkami, artykułami itd. Języki i biblioteki mają specyfikacje, społeczności, poradniki, dzięki czemu otrzymujesz najbardziej niezawodny sposób rozwijania umiejętności programistycznych - po prostu czytając dokumentację, a nie szukając cudzych lokalnych rozwiązań i fragmentów kodu. A co jeśli Twoje rozwiązanie jest bardziej optymalne, szybsze i chłodniejsze?
Zaufanie, ale sprawdzić
Nie korzystaj z bibliotek i frameworków stworzonych przez zewnętrznych programistów bez sprawdzenia kodu i dostosowania go do własnych celów. Nie masz powodu, aby bezwarunkowo ufać autorowi kodu, którego w ogóle nie znasz. Owszem, różnego rodzaju celowe złośliwe elementy w kodzie stron trzecich nie są aż tak powszechne i nie ma powodu popadać w paranoję, ale bezmyślne kopiowanie gotowych fragmentów oprogramowania do swojego projektu może mieć nieprzewidywalne konsekwencje. Dlatego pamiętaj, aby przeczytać i przeanalizować kod przed jego użyciem oraz przetestować go po zaimplementowaniu.
Twórz kopie zapasowe!
Nie rób kopii zapasowych i nie przechowuj ich na serwerach zewnętrznych, na których hostowany jest Twój projekt. Czy uważasz, że to zabawna i bezużyteczna rada? Jednak ponad 700 uczestników czatu na Telegramie, którzy niedawno znaleźli się w nieprzyjemnej sytuacji związanej z zamknięciem jednego z dobrze znanych centrów danych, nie uważało tak - było tam wszystko: od ulubionych projektów po duże strony rządowe. bazy danych podmiotów gospodarczych i korporacji 1C oraz rozliczenia. Znaczna część nie posiada kopii zapasowych lub posiada kopie zapasowe w tym samym miejscu. Dlatego rozłóż ryzyko i przechowuj kopię zapasową przynajmniej na głównym hostingu, na niezawodnym serwerze VDS i na lokalnym serwerze. Ostatecznie będzie znacznie taniej.
Przestań przynosić własne rzeczy, które szkodzą projektowi
Nie rób tego, co chcesz, w projekcie zawodowym. Rób to, czego potrzebują Twoi klienci. Tak, tworzenie własnej sieci neuronowej, trenowanie jej i implementowanie do oprogramowania jest niesamowicie interesujące i fajne, ale jeśli Twoi klienci potrzebują prostego menedżera kontaktów, będzie to kosztowny ekstrawagancja. Zobacz, jak działa projekt, przeczytaj dokumentację, przeczytaj recenzje i prośby klientów, a następnie wdróż to, co nada projektowi wartość biznesową. Jeśli chcesz stworzyć coś naukowego lub bardzo skomplikowanego, zacznij od własnego projektu.
Nie kod, ale kłębek nerwów
Nie pisz nieczytelnego i nieudokumentowanego kodu. Znamy ten trik: programista pisze kod tak, jak Bóg wkłada go w jego duszę, celowo trochę go myląc, aby nikt z jego kolegów nie zrozumiał, co jest napisane — rodzaj zemsty zapobiegawczej, zanim coś się stanie. Jednak narażasz na ryzyko nie tylko firmę (która płaci Ci za Twoją pracę), ale także siebie: całkiem możliwe, że Ty sam nie będziesz pamiętał, co chciałeś powiedzieć, stosując takie niezamierzone zaciemnianie informacji. Tak samo jest z nieudokumentowanym kodem: polegając na logice nadawania nazw zmiennym i funkcjom oraz dobrej pamięci, za kilka lat możesz nie pamiętać, dlaczego wybrałeś ten konkretny cykl, metodę, wzorzec itd. Dokumentowanie kodu i jego dobre ustrukturyzowanie to wielka przysługa dla współpracowników, pracodawcy i, co najważniejsze, dla samego siebie.
Niech to będzie możliwie proste
Nie komplikuj nadmiernie swojego kodu, rozwiązań i projektów. Nie ma potrzeby budowania skomplikowanej struktury i tworzenia bytów bez żadnego szczególnego znaczenia. Im bardziej złożony jest Twój kod, tym bardziej stajesz się jego zakładnikiem. Będzie Ci niezwykle trudno go utrzymywać i rozwijać. Oczywiście słynna zasada KISS („Keep it simple, stupid”) nie zawsze jest właściwa, ale została stworzona z pewnego powodu: prostota i elegancja kodu to klucz do jego skutecznego zastosowania i ponownego użycia.
Weź ochronę
Nie ignoruj kwestii bezpieczeństwa – w 2020 roku jest to po prostu przestępstwo. Nawet jeśli Twoja firma, rozwój i Ty nie interesują Cię jako osoby atakujące, możesz być narażony na problemy związane z pokonaniem jakiegoś segmentu sieci, dostawcy hostingu, atakiem na centrum danych, kradzieżą haseł do poczty elektronicznej i niebezpiecznym zachowaniem pracowników, którzy mogą ukraść dane firmy, klientów lub kod programowy całego projektu. Jeżeli leży to w Twoich kompetencjach i znasz się na tym, postaraj się chronić projekty, nad którymi pracujesz. No cóż, proszę, zadbaj o bezpieczeństwo informacji; nikomu to nigdy nie zaszkodziło.
Nie pluj do studni
Nie bądź niemiły dla swojego pracodawcy. Dziś komunikacja osiągnęła taki poziom, że na przykład wszyscy HR-owcy w mieście znają się zaocznie i mogą wymieniać się wszelkimi informacjami na czatach i w zamkniętych grupach (zarówno w celu pomocy w znalezieniu pracy, jak i napisania „Wasilij Iwanow, architekt systemów, przed odejściem zabił wszystkie konta, usunął kopie zapasowe i wyłączył sieć, przywrócenie zajęło 3 dni. Nie zatrudniajcie go”). W ten sposób Twoje zachowanie będzie działać wyłącznie na Twoją niekorzyść – czasami nawet przeprowadzka do innego miasta czy stolicy nie pomoże. Nawet jeśli odejdziesz z urazą, nie ma lepszej zemsty niż zostać użytecznym i fajnym pracownikiem konkurencji 🙂 I co najważniejsze, z całkowitą bezkarnością.
Ty również nie powinieneś tego robić. Ale jak pokazuje doświadczenie, nie zatrzymamy się
Generalnie, przyjaciele, przeczytajcie porady, ale zróbcie to, co uważacie za najlepsze - przecież prawdziwe odkrycia mają miejsce wtedy, gdy wątpimy w prawdy już odkryte. Życzymy Ci Szczęśliwego Nowego Roku, aby Twoje projekty odniosły sukces, Twoja kariera była ciekawa, Twoi współpracownicy i przełożeni byli dobrzy, a Twoje życie ogólnie rzecz biorąc, było udane. Ogólnie rzecz biorąc, życzę Nowego Roku i nowego kodu!
Z miłością,
Zespół RegionSoft Developer Studio
W nadchodzącym roku będziemy kontynuować pracę dla Państwa i rozwijać potężny system CRM na komputery stacjonarne oraz prosty i wygodny system pomocy technicznej i zgłoszeń .
Źródło: www.habr.com
