Hacker pełen jest prognoz i porad na temat tego, co robić w nadchodzącym roku — jakie języki się uczyć, na jakie sektory się przestawiać, jak dbać o zdrowie. Brzmi inspirująco! Ale każda moneta ma dwie strony, a my potykamy się nie tylko w czymś nowym, ale głównie w tym, co robimy na co dzień. "Dlaczego nikt mnie nie ostrzegł!" — wołamy zirytowani, zazwyczaj zwracając się do samych siebie. Przypinamy ogień na siebie — zebraliśmy dla was listę rzeczy, których NIE warto robić w 2020 roku (a może i zawsze).
A grawitacja nie zapytała.
Bardzo chcielibyśmy uporządkować antyrekomendacje w kolejności od najważniejszej do najmniej znaczącej. Ale są one tak powszechne, równorzędne i znane praktycznie każdemu, że będziemy pisać bez ładu. Co, sprawdźmy listę?
Nie należy wchodzić do IT, jeśli wszystko jest w porządku.
Nie ucz się nowej technologii, aby zmienić zawód lub zacząć od nowa. Nasz czas jest wspaniały, ponieważ można się uczyć, zmieniać pracę, całkowicie zmieniać branżę — i tak aż do emerytury. To świetna, kusząca sprawa. Ale jeśli masz więcej niż 28-30 lat, nie rzucaj wszystkiego, aby wejść do IT lub zmienić stos (na przykład, jeśli piszesz wysoko obciążone systemy w Javie i nagle postanawiasz przejść do sieci neuronowych na Pythonie). Powód jest prosty: będzie ci trudno. Po pierwsze, konkurencja ze strony specjalistów, którzy „siedzą” na tym stosie od początku swojej kariery, jest wysoka, po drugie, będziesz musiał znowu zostać juniorem z niską pensją, po trzecie, moralnie będzie ci ciężko stać się podwładnym najniższego szczebla hierarchii. Dlatego jeśli chcesz iść w inną stronę, staraj się to robić albo w ramach obecnej pracy i bieżących zadań, albo rozwijaj nową wiedzę jako hobby, pracuj nad projektem pobocznym, aby przyjść do nowej pracy już nie jako junior.
Zmiana stosu technologii to tylko strata czasu.
Nie skacz między stosami technologii w swojej pracy. Jeśli piszesz projekt w jednym języku, używasz określonego frameworka i bibliotek, nie rzucaj wszystkiego i nie przepisywuj na Dart tylko dlatego, że to wydaje ci się interesujące. Przyjmij za zasadę, aby znaleźć uzasadnienie dla zmiany technologii — nie tylko na poziomie „chcę-nie mogę”, ale także na poziomie finansowym i inżynieryjnym.
Nie trzeba obstawać przy swoim i zdrętwieć.
Przywiązywanie się do jednego języka lub technologii i ignorowanie nowości jest tak samo skrajne, jak zmiana stosu z każdą nową technologią. Zawsze ucz się nowych bibliotek i frameworków, nie bądź uparty, myśląc, że wszystko co najlepsze zostało wymyślone przed Tobą i ulepszone wyłącznie przez Ciebie. Dla prawie każdego języka regularnie pojawiają się aktualizacje, które mogą znacząco poprawić Twój projekt. Nie bądź leniwy, śledź dynamiczność swojego stosu i w momencie, gdy znajdziesz coś fajnego i przydatnego, śmiało wprowadź to do projektu!
Własna głowa to dobrze, zawsze dobrze
Nie myśl cudzymi myślami, twoje są lepsze. Niestety, niektórzy programiści siedzą i czekają, aż dostaną zadanie, aby pisać od poprzedniego błędu do końca, nie próbując wnieść czegoś swojego do projektu, opracować nową funkcję, przetestować i zaproponować do produkcji. Po co się trudzić, skoro jest głowa team leada lub kierownika firmy, który sam wszystko załatwi? Jeśli się w tym rozpoznajesz, to mamy złe wieści: pasywna postawa nie pomoże ani w karierze, ani w rozwoju. Masz szansę spróbować swoich sił jako inżynier programista, a nie jako programista w prawdziwym projekcie i zrozumieć, w jakim kierunku iść, czego brakuje, ale wolisz spędzić swój czas na czymś innym, robiąc dokładnie „od do”. Tacy w nowoczesnej IT przetrwają coraz gorzej, wyjdź z anabiozy.
Użytkownicy to straszni ludzie
Nie przeceniaj użytkowników swojego oprogramowania: jeśli piszesz nie dla programistów, przygotuj się na to, że program spotka się z nieprzeniknionym niezrozumieniem. Przez pierwsze kilka dni lub tygodni użytkownik będzie nienawidził twojego oprogramowania, ponieważ „stary nie był taki głupi”. Aby tego uniknąć, stwórz świetną dokumentację i materiały szkoleniowe. Przy instalacji lub zakupie bardzo nachalnie zasugeruj, że instrukcje warto przeczytać przed rozpoczęciem pracy z programem, a nie po załamaniu bazy danych, utracie hasła i samokontroli.
Nie należy lekceważyć użytkowników: są sprytniejsi, mądrzejsi i ciekawsi, niż myślisz. Jeśli sądzisz, że błąd związany z formatem zmiennej i wyjątek przy 138. naciśnięciu Enter co sekundę nie wystąpią, mylisz się — pojawią się i wpłyną na działanie Twojej aplikacji w najbardziej nieprzewidywalny sposób. Działa zasada amatora: to on najlepiej radzi sobie z testowaniem. Jednak użytkownicy w jakiś sposób nie lubią znajdować błędów w produkcie — nie ma w tym żadnej solidarności IT. Generalnie, im bardziej jesteś pewny swojego oprogramowania, tym lepiej. W końcu lepiej opóźnić wydanie niektórych funkcji, niż dodać je do działającej aplikacji i nagle sprawić, że będzie niedopracowana.
Dość googlowania!
Przestań polegać tylko na Google. Nawet nie będziemy się spierać — w dziedzinie programowania można znaleźć bardzo wiele za pomocą bezpośredniego zapytania do wyszukiwarki. Im głębiej zagłębisz się w poszukiwania informacji, tym więcej „pobocznych” danych zdobędziesz i więcej się dowiesz, ponieważ poznasz coś nowego, niezwiązanego z Twoim zapytaniem, ale prawdopodobnie przydatnego w przyszłości. Korzystaj z pełnowartościowych materiałów, książek, artykułów itp. Języki i biblioteki mają specyfikacje, społeczności, poradniki i w ten sposób zdobywasz najbardziej niezawodny sposób rozwijania umiejętności programisty — po prostu czytając dokumentację, a nie szukając cudzych lokalnych rozwiązań i fragmentów kodu. A nuż Twoje rozwiązanie będzie bardziej optymalne, szybsze i lepsze?
Ufaj, ale sprawdzaj
Nie korzystaj z bibliotek i frameworków stworzonych przez zewnętrznych deweloperów, nie sprawdzając kodu i nie dostosowując go do swoich celów. Nie masz żadnych podstaw, by bezwarunkowo ufać temu autorowi, którego w ogóle nie znasz. Tak, różne celowe złośliwe elementy w zewnętrznym kodzie występują niezbyt często i nie ma powodu do paranoi, ale ślepe kopiowanie gotowych fragmentów oprogramowania do swojego projektu może prowadzić do nieprzewidywalnych konsekwencji. Dlatego zawsze czytaj i analizuj kod przed użyciem oraz przeprowadzaj testy po wdrożeniu kodu.
Twórz kopie zapasowe!
Przestań nie robić kopii zapasowych lub trzymać ich na tych samych zewnętrznych serwerach, na których hostowany jest twój projekt. Myślisz, że to zabawna i niepotrzebna rada? A jednak ponad 700 uczestników czatu na Telegramie, którzy znaleźli się w trudnej sytuacji z powodu przerwy w pracy jednego znanego Data Center, tak nie myślało — co tam się działo: od projektów osobistych po duże strony instytucji państwowych oraz korporacyjne bazy 1C i systemy billingowe. Znaczna część — bez kopii zapasowych lub z kopiami w tym samym miejscu. Dlatego rozdzielaj ryzyko i przechowuj kopię zapasową przynajmniej na głównym hostingu, na jakimś niezawodnym VDS i u siebie na lokalnym serwerze. W końcu będzie to znacznie tańsze.
Dość przynosić swoje na szkodę projektu
Nie rób w projekcie roboczym tego, co chcesz, ale rób to, czego potrzebują klienci. Tak, stworzenie własnej sieci neuronowej, przeszkolenie jej i wdrożenie w swoim oprogramowaniu jest niezwykle interesujące i fascynujące, ale jeśli twoim klientom potrzebny jest prosty menedżer kontaktów, to będzie to niepotrzebny wydatek. Zobacz, jak działa projekt, przeczytaj dokumentację, przeczytaj opinie i zapytania od klientów i wdroż to, co nada projektowi wartość biznesową. Jeśli chcesz tworzyć coś naukowego lub nadmiernie skomplikowanego, rozpocznij od swojego własnego projektu.
Nie kod, a zbiór nerwów
Nie pisz nieczytelnego i niedokumentowanego kodu. Znamy ten kawałek: programista pisze kod jak mu dusza podpowiada, specjalnie go nieco myli, aby żaden z kolegów nie mógł się w nim odnaleźć — taka swoista prewencyjna zemsta zanim coś się wydarzy. Narażasz jednak nie tylko firmę (która płaci ci za pracę), ale i siebie samego: prawdopodobnie nie przypomnisz sobie, co chciałeś przekazać w tej niezamierzonej obfuskacji. To samo dotyczy niedokumentowanego kodu: polegając na swojej logice nazewnictwa zmiennych i funkcji oraz dobrej pamięci, po kilku latach możesz nie pamiętać, dlaczego wybrałeś ten konkretny cykl, metodę, wzór itd. Dokumentowanie kodu i jego dobra struktura to wspaniała usługa dla kolegów, pracodawcy, a przede wszystkim dla samego siebie.
Keep it simple, stupid
Не усложняйте код, решения и проекты. Не нужно городить сложную структуру и плодить сущности без особой значимости. Чем сложнее ваш код, тем больше вы становитесь его заложником — вам будет максимально сложно его поддерживать и развивать. Конечно, знаменитый принцип KISS («Keep it simple, stupid») подходит не всегда, но он создан не зря: простота и изящность кода — залог успешного его применения и переиспользования.
Предохраняйтесь
Не игнорируйте безопасность — в 2020 году это буквально преступно. Даже если ваша компания, разработка и вы не интересны злоумышленникам, вас могут затронуть проблемы, связанные с поражением какого-то сегмента сети, хостинг-провайдера, с атакой на дата-центр, с хищением паролей почты и с небезопасным поведением сотрудников, которые могут украсть данные из компании, увести клиентов или программный код всего проекта. Если это в ваших силах и относится к зоне компетенции, постарайтесь защитить те проекты, с которыми работаете. Ну и сами соблюдайте информационную безопасность, это ещё никому не мешало.
Не плюйте в колодец
Не гадьте своему работодателю. На сегодняшний день коммуникации достигли такого уровня, что, например, все HR-ы города заочно знакомы между собой и могут обменяться любой информацией в чатах и закрытых группах (как помочь трудоустроиться, так и написать «Василий Иванов, системный архитектор, перед уходом убил все учётные записи, затёр бэкапы и отключил сеть, восстановление заняло 3 суток. Не берите его на работу»). Таким образом, ваше поведение сыграет исключительно против вас — и иногда не поможет даже релокация в другой город или столицу. Даже если вы уходите с обидой, нет лучше мести, чем стать полезным и классным сотрудником конкурента 🙂 А главное, полностью безнаказанно.
Так делать тоже не стоит. Но, как показывает опыт, не перестанем
А вообще, друзья, читайте советы, но делайте так, как вам кажется лучшим — ведь настоящие открытия совершаются тогда, когда мы сомневаемся в уже открытых истинах. Поздравляем вас с Новым Годом, пусть ваши проекты будут успешными, карьера — нескучной, коллеги и руководители — адекватными, а жизнь в целом удаётся. В общем, за Новый Год и за новый код!
Z miłością,
zespół RegionSoft Developer Studio
W nowym roku nadal będziemy pracować dla Ciebie i rozwijać potężny system CRM na komputer stacjonarny oraz prosty i wygodny helpdesk i system zgłoszeń .
Źródło: habr.com
