2020년에 IT 전문가가 하지 말아야 할 것은 무엇입니까?

허브에는 내년에 무엇을 해야 할지, 어떤 언어를 배워야 할지, 어떤 영역에 집중해야 할지, 건강을 어떻게 해야 할지에 대한 예측과 조언이 가득합니다. 영감을 주는 것 같아요! 그러나 모든 동전에는 양면이 있으며, 우리는 새로운 것뿐 아니라 대부분 우리가 매일 하는 일에서도 비틀거리게 됩니다. “왜 아무도 나에게 경고하지 않았나요?” 우리는 짜증스럽게 외치며 대개 자기 자신에게로 향합니다. 우리 스스로에게 불을 지르자 - 우리는 2020년에 (아마도 항상) 하지 말아야 할 일의 목록을 작성했습니다. 

하지만 그들은 중력에 대해 묻지 않았어

우리는 가장 중요한 것부터 가장 덜 중요한 것 순으로 반대 권장 사항을 정리하고 싶습니다. 그러나 그것들은 거의 모든 사람에게 매우 일반적이고 동등하며 친숙하므로 우리는 무작위로 쓸 것입니다. 자, 목록을 확인해 볼까요?

모든 것이 괜찮다면 IT에 갈 필요가 없습니다

직업을 바꾸거나 다시 시작하기 위해 새로운 기술을 배우지 마십시오. 은퇴할 때까지 공부하고, 직업을 바꾸고, 분야를 근본적으로 바꿀 수 있기 때문에 우리의 시간은 훌륭합니다. 멋지고 매혹적인 일입니다. 하지만 28~30세 이상이면 IT에 들어가거나 새로운 스택으로 이동하기 위해 모든 것을 포기해서는 안 됩니다(예를 들어, 로드가 많은 시스템을 Java로 작성했는데 갑자기 Python으로 신경망에 들어가기로 결정한 경우). 이유는 간단합니다. 쉽지 않을 것입니다. 첫째, 경력 초기부터 이 스택에 앉아 있던 전문가들과의 경쟁이 치열하고, 둘째, 낮은 급여로 다시 후배가 되어야 하며, 셋째, 도덕적으로 어려울 것입니다. 계층의 최하위 계층에 속하게 됩니다. 그러므로 다른 방향으로 나아가고 싶다면 현재 하고 있는 일과 현재 업무에 맞게 해보거나, 취미로 새로운 지식을 쌓거나, 새로운 직장에 왔을 때 더 이상 후배가 아니다. 

스택을 계속해서 바꾸는 것은 시간낭비일 뿐이다

개발을 위해 기술 스택 사이를 서두르지 마십시오. 특정 프레임워크와 라이브러리를 사용하여 하나의 언어로 프로젝트를 작성하는 경우 단지 흥미롭다고 해서 모든 것을 다 던져버리고 Dart에서 다시 작성해서는 안 됩니다. "원하거나 할 수 없음" 수준뿐만 아니라 재무 및 엔지니어링 수준에서도 기술 변화에 대한 정당성을 찾는 것이 규칙입니다. 

입장을 고수하고 청동으로 변할 필요가 없습니다.

하나의 언어나 기술을 고수하고 새로운 것을 배우지 않는 것은 새로운 기술이 나올 때마다 스택을 바꾸는 것만큼 극단적입니다. 새로운 라이브러리와 프레임워크를 반드시 연구하고, 모든 것이 당신보다 먼저 발명되었고 당신이 독점적으로 완성했다는 사실을 고집하지 마십시오. 거의 모든 언어에 대한 업데이트가 지속적으로 제공되고 있으며 이로 인해 때로는 프로젝트가 크게 향상될 수 있습니다. 게으르지 말고 스택의 역학을 모니터링하고, 멋지고 유용한 것을 발견하자마자 자유롭게 프로젝트에 끌어다 놓으세요!

네 머리는 좋아, 항상 좋아

다른 사람의 머리로 생각하지 마십시오. 자신의 머리가 더 좋습니다. 아아, 일부 개발자는 프로젝트에 자신의 기여를 시도하지 않고 새로운 기능을 개발하고 테스트하고 생산을 위해 제안하지 않고 이전 오류부터 끝까지 코딩하는 작업을 받을 때까지 앉아서 기다립니다. 모든 것을 스스로 결정하는 팀장이나 회사 관리자가 있는데 왜 귀찮게합니까? 자신을 인식한다면 나쁜 소식이 있습니다. 수동적인 입장은 경력이나 개발에 도움이 되지 않습니다. 실제 전투 프로젝트에서 코더가 아닌 개발 엔지니어로서 손을 뻗어 어디로 가야할지, 무엇이 누락되었는지 이해할 기회가 있지만, 다른 일에 시간을 보내고 "여기에서 여기까지"정확하게 수행하는 것을 선호합니다. 지금." 그런 사람들은 현대 IT에서 점점 더 나빠지고 정지된 애니메이션에서 나옵니다. 

사용자는 끔찍한 사람들이다

소프트웨어 사용자를 과대평가하지 마십시오. 프로그래머를 위해 글을 쓰는 것이 아니라면 프로그램이 뚫을 수 없는 오해에 직면할 것으로 예상하십시오. 처음 며칠 또는 몇 주 동안 사용자는 "이전 소프트웨어가 그렇게 멍청하지 않았다"는 이유로 귀하의 소프트웨어를 싫어할 것입니다. 이를 방지하려면 훌륭한 문서와 튜토리얼을 만드세요. 설치 또는 구매할 때 데이터베이스 충돌, 비밀번호 손실 및 자제력 상실 이후가 아니라 프로그램 작업을 시작하기 전에 설명서를 읽어야 한다는 점을 암시적으로 암시하십시오.

사용자도 과소평가해서는 안 됩니다. 사용자는 생각보다 더 교활하고 똑똑하며 호기심이 많습니다. 가변 형식의 버그와 138초 간격으로 XNUMX번째 Enter 키를 눌렀을 때 발생하는 예외가 나타나지 않을 것이라고 생각한다면 착각입니다. 이러한 버그가 나타나서 가장 기괴한 방식으로 애플리케이션 작동에 영향을 미칠 것입니다. 아마추어의 규칙이 적용됩니다. 그는 테스트에 가장 잘 대처하는 사람입니다. 그러나 어떤 이유에서인지 사용자는 프로덕션에서 버그를 찾는 것을 좋아하지 않습니다. 버그에는 IT 연대가 없습니다. 일반적으로 소프트웨어에 대한 자신감이 높을수록 좋습니다. 결국, 작동하는 애플리케이션에 기능을 추가하고 갑자기 원시 상태로 만드는 것보다 일부 기능의 출시를 연기하는 것이 더 낫습니다.

 

인터넷 검색을 중단하세요!

이제 Google에만 의존하지 마세요. 우리는 논쟁조차 하지 않을 것입니다. 개발 분야에서는 검색 엔진에 직접 요청하여 많은 것을 찾을 수 있습니다. 정보 검색을 더 깊이 파고들수록 더 많은 "측면" 데이터를 받게 되고 더 많이 배우게 됩니다. 왜냐하면 귀하의 요청과 관련이 없지만 아마도 미래에 필요할 수 있는 새로운 것을 배우게 되기 때문입니다. 본격적인 자료, 서적, 기사 등을 참조하십시오. 언어와 라이브러리에는 사양, 커뮤니티, 방법이 있으므로 프로그래머 기술을 개발하는 가장 신뢰할 수 있는 방법을 얻을 수 있습니다. 문서를 읽기만 하고 다른 사람의 로컬 솔루션 및 코드 조각을 찾지 마십시오. 귀하의 솔루션이 더 최적이고, 더 빠르고, 더 시원하다면 어떨까요? 

정말이야,하지만 확인

코드를 확인하고 목적에 맞게 조정하지 않고 타사 개발자가 만든 라이브러리 및 프레임워크를 사용하지 마십시오. 전혀 모르는 이 코드 작성자를 무조건 신뢰할 이유가 없습니다. 예, 제3자 코드에 포함된 다양한 고의적 악성 요소는 그다지 흔하지 않으며 편집증을 겪어서는 안 됩니다. 그러나 기성 소프트웨어 부분을 맹목적으로 프로젝트에 복사하면 예측할 수 없는 결과를 초래할 수 있습니다. 따라서 사용하기 전에 반드시 코드를 읽고 분석하고, 코드 구현 후 테스트를 하시기 바랍니다. 

백업을 하세요!

백업을 만들지 않거나 프로젝트가 호스팅되는 동일한 타사 서버에 보관하지 마세요. 이것이 우스꽝스럽고 쓸모없는 조언이라고 생각하십니까? 그러나 잘 알려진 데이터 센터가 폐쇄되면서 최근 불쾌한 상황에 처한 Telegram의 700 명 이상의 채팅 참가자는 그렇게 생각하지 않았습니다. 거기에는 애완 동물 프로젝트부터 대규모 정부 웹 사이트에 이르기까지 모든 것이있었습니다. 당국 및 기업 1C 및 청구 데이터베이스. 중요한 부분은 백업이 없거나 같은 장소에 백업이 있다는 것입니다. 따라서 위험을 분산시키고 최소한 기본 호스팅, 신뢰할 수 있는 VDS 및 로컬 서버에 백업을 저장하십시오. 장기적으로 보면 훨씬 더 저렴해질 것입니다. 

프로젝트에 해를 끼치는 일을 중단하십시오.

업무 프로젝트에서 원하는 것을 하지 말고 고객이 필요로 하는 것을 하십시오. 예, 자신만의 신경망을 만들고, 훈련시키고, 소프트웨어에 구현하는 것은 믿을 수 없을 정도로 흥미롭고 훌륭합니다. 하지만 고객이 간단한 연락처 관리자를 필요로 한다면 이는 과잉이 될 것입니다. 프로젝트가 어떻게 진행되는지 확인하고, 문서를 읽고, 고객의 리뷰와 요청을 읽고, 프로젝트에 비즈니스 가치를 더할 사항을 구현하십시오. 과학적이거나 매우 복잡한 것을 만들고 싶다면 자신만의 프로젝트부터 시작하세요.

코드가 아니라 신경다발

읽을 수 없고 문서화되지 않은 코드를 작성하지 마십시오. 우리는 이 트릭에 익숙합니다. 개발자는 자신이 작성한 내용을 동료 중 누구도 이해할 수 없도록 의도적으로 약간 혼란스럽게 코드를 작성합니다. 이는 어떤 일이 발생하기 전에 일종의 예방적 복수입니다. 그러나 귀하는 회사(귀하의 업무에 대해 귀하에게 돈을 지불하는)뿐만 아니라 귀하 자신도 위험에 빠뜨리고 있습니다. 의도하지 않은 난독화로 인해 귀하가 말하고 싶었던 내용을 기억하지 못할 가능성이 높습니다. 문서화되지 않은 코드도 마찬가지입니다. 변수 및 함수 명명 논리와 좋은 메모리에 의존하면 몇 년이 지나면 특정 루프, 메서드, 패턴 등을 선택한 이유를 기억하지 못할 수도 있습니다. 코드와 코드의 좋은 구조를 문서화하는 것은 동료, 고용주, ​​그리고 무엇보다도 자신에게 훌륭한 서비스입니다. 

단순해, 바보야

코드, 솔루션 및 프로젝트를 단순하게 유지하세요. 복잡한 구조에 울타리를 치고 특별한 의미 없이 엔터티를 생산할 필요가 없습니다. 코드가 복잡할수록 인질이 될수록 코드를 유지하고 개발하는 것이 최대한 어려워집니다. 물론, 유명한 KISS 원칙("단순하게 유지하고 어리석게 유지하세요")이 항상 적합한 것은 아니지만 이것이 만들어진 이유는 다음과 같습니다. 코드의 단순성과 우아함이 성공적인 적용과 재사용의 열쇠입니다.

자신을 보호하다

안전을 무시하지 마십시오. 2020년에는 말 그대로 범죄입니다. 귀하의 회사, 개발 및 귀하가 공격자의 관심 대상이 아니더라도 일부 네트워크 세그먼트, 호스팅 제공업체의 패배, 데이터 센터 공격, 이메일 비밀번호 도용 및 직원의 안전하지 않은 행동과 관련된 문제로 인해 영향을 받을 수 있습니다. 회사의 데이터를 훔치고, 클라이언트나 전체 프로젝트의 프로그램 코드를 훔칩니다. 그것이 귀하의 권한과 전문 분야 내에 있다면 귀하가 진행 중인 프로젝트를 보호하도록 노력하십시오. 글쎄, 정보 보안을 직접 관찰하십시오. 누구도 귀찮게 한 적이 없습니다. 

우물에 침을 뱉지 마세요

고용주를 괴롭히지 마십시오. 오늘날 의사소통은 예를 들어 도시의 모든 HR 직원이 결석 중에 서로를 알고 채팅 및 비공개 그룹에서 정보를 교환할 수 있는 수준에 도달했습니다(구직을 돕고 "Vasily Ivanov, 시스템 설계자, 계정을 떠나기 전에 모든 것을 죽였고, 백업을 삭제하고 네트워크를 끄고, 복구하는 데 3일이 걸렸습니다. 그를 고용하지 마세요." 따라서 귀하의 행동은 전적으로 귀하에게 불리하게 작용할 것이며 때로는 다른 도시나 수도로의 이전조차도 도움이 되지 않을 것입니다. 원한을 품고 떠나더라도 경쟁사의 유용하고 멋진 직원이 되는 것보다 더 좋은 복수는 없습니다. :) 그리고 가장 중요한 것은 완전한 면책입니다.

당신도 그렇게해서는 안됩니다. 그러나 경험에서 알 수 있듯이 우리는 멈추지 않을 것입니다

일반적으로 친구 여러분, 조언을 읽으십시오. 그러나 최선이라고 생각하는 것을하십시오. 결국 이미 발견 된 진실을 의심 할 때 실제 발견이 이루어집니다. 새해 복 많이 받으세요. 프로젝트가 성공하고, 경력이 즐겁고, 동료와 관리자가 적절하고, 전반적인 삶이 성공하기를 바랍니다. 일반적으로 새해와 새 코드는 다음과 같습니다! 

사랑으로
RegionSoft 개발자 스튜디오 팀

새해에도 우리는 계속해서 귀하를 위해 일하고 강력한 데스크톱 CRM 시스템을 개발할 것입니다. 리전소프트 CRM 간단하고 편리한 헬프 데스크와 티켓 시스템 ZEDLine 지원.

출처 : habr.com