프로세스

[IEEE] 소프트웨어 개발자가 되기(Being a Software Developer)

하루삼십만원 2020. 12. 18. 01:24
반응형

[IEEE] 소프트웨어 개발자가 되기(Being a Software Developer)

좋은 software 개발자가 되기 위해 필요한 mindset을 잘 정리된 글이라, 한글 번역으로 옮겨 봅니다. 출처는 글 하단에 명시되어 있습니다.

 

Authors

Diomidis Spinellis, Athens University of Economics and Business

 

 전문적인 소프트웨어 개발자라가 되는 일은 만만치 않습니다." 이것은 내가 회사의 코딩 테스트를 통과하지 못한 많은 대학 졸업자 지원자들을 한탄하는 매니저에게 한 말이었다. 프로그래머들은 추상화의 layer들 위의 layer들을 통해 정의되는 symbols(code)를 조작함으로써 가장 복잡한 human artifacts(인간 유물, 프로그램)을 개발한다. 그런 다음 그 결과 instructions(명령어)들은 5년마다 10배 더 강력해지는 원자 규모의 프로세서에서 (종종 비결정적인 방식으로) 초당 수십억의 속도로 처리된다. 컴퓨터 과학, 정보학 같은 관련 학위들은 필요한 지식과 기술의 껍데기만을 긁을 수 있다(수박 겉햝기). 전문 소프트웨어 엔지니어링 학위는 더 깊이 들어갈 수 있지만 필요한 전문 지식과 경험을 모두 제공할 수는 없다. 의대 졸업자나 항공대 졸업자가 심장 개방 수술을 하거나 에어버스 A380을 조종하는 것이 허용되기까지는 수년이 걸린다는 것을 생각해 보자.

 

 production code(판매되는 제품에 들어가는 code)에 대한 작업은 빠르게 demanding(까다로워지기) 때문에 전문 개발자가 되려면 지속적으로 상당한 시간을 투자하여 전문 지식을 습득하고 다양한 기술을 개발해야 한다. 대학은 여러분의 열정을 자극하고 여러분의 시야를 넓히기 위한 인센티브를 제공할 수 있고, 여러분의 고용주는 전문 교육을 지원할 수 있다. 하지만 결국, 전문 소프트웨어 개발자가 되는 것은 여러분의 결정이자 책임이다.

Knowledge

 Bloom의 인지-영역 학습 분류법 원본에서 첫 번째 요소는 knowledge(지식)이다. 대학 학위는 소프트웨어 작성에 필요한 중요한 이론적 지식을 제공한다. 여기에는 적절한 data structures와 algorithms의 선택, computer's architecture와 OS가 성능에 미치는 영향의 이해, 적절한 programming-language features, 소프트웨어 엔지니어링 방법 적용 등이 포함된다. 많은 커리큘럼은 일반적으로 인간-컴퓨터 상호작용, 컴퓨터 그래픽, 정보 보안 및 관리, 네트워킹 및 지능형 시스템과 같은 상황별 전문 지식을 다룬다. 대학 프로그램이 일반적으로 제공할 수 없는 것은 전문 domain know-how(예: 토목 공학 또는 항공 공학에서의 computing application)와 소프트웨어 구성 도구에 대한 포괄적인 지식이다.

 

 전문 개발자로서 여러분은 프로그래밍을 가르치는 데 자주 사용되는 sandbox 개발 도구로부터 더 발전해야 하며, 완전한 기능을 갖춘 IDE와 강력한 범용 코드 편집기를 통해서 생산성을 높일 수 있어야 한다. 이러한 tools의 예로는 Eclipse, Visual Studio, Vim, Atom 및 Emacs가 있다.

 

 Java 또는 Go와 같은 범용 프로그래밍 언어와 .NET과 같은 application developement framework 또는 API에 대한 심층적인 지식도 필요하다. 언어의 모든 features에 익숙해질(accustomed with) 때쯤이면 일상 업무에서 생산성을 발휘할 수 있을 만큼 충분한 자신감을 얻게 될 것이다. 마찬가지로, 프레임워크에서 다루는 모든 영역에 어느 정도 익숙해지면 각 상황에 맞는 적절한 features을 찾고 선택할 수 있다.

 

 마지막으로, 다양한 소프트웨어 구성 도구도 완벽하게(thoroughly) 익혀야(acquainted) 한다. 여기에는 build automation, configuration management, debugging, testing, static analysis, continuous integration 및 package management를 위한 도구가 포함된다. 당신은 특정 요구 사항을 포함하도록 그것들을 구성하고 실행할 수 있을 뿐만 아니라 작동 원리에 대해서도 파악할 수 있어야 한다. Git은 revision을 어떻게 저장할까? build 또는 package 종속성들의 transitive order는 무엇이지? 정적분석에서 false positive와 false negative는 왜 발생을 하지? data breakpoint는 무엇인지? 정기적으로 직면하게 될 다양한 ad hoc software construction 작업을 고려할 때, Unix command-line tools 또는 Python 및 해당 모듈과 같은 몇 가지 범용 도구 세트도 마스터해야 한다.

 

더보기

Static analysis에서 false positive/negative란?

1) false positive : 코드 상에서 실제로 존재하지 않는 문제들. 수정할 필요가 없다. rule 위반이 없지만 diagnostic이 생성될 때 발생함.

2) false negative : 발견이 되지 않는 문제들. rule 위한이 존재하지만 diagnostic이 생성되지 않았을 때 발생한다.

 

Cognitive Skills (인지 능력)

 

 지식과는 대조적으로, 소프트웨어 개발자로서 당신이 필요로 할 대부분의 congnitive(인지) skills은 대학에서 간접적으로만 가르쳐질 수 있다. 비판적 사고와 관련된 것들과 같은 그것들 중 일부는 심지어 훨씬 더 이른 생애에(어린 시절에) 연마(honed)된다. 하지만, 여러분은 항상 practive(연습), introspection(자기성찰), 그리고 training(훈련)을 통해 여러분의 약한 부분을 개선할 수 있다. 놀랄 것도 없이, 개발자의 주요 인지 기술은 application(적용), comprehension(이해), analysis(분석), synthesis(합성) 및 evaluation(평가) 등 블룸의 분류 체계에 남아 있는 모든 요소를 포함한다. 여기 몇 가지 예가 있다.

 

 이론적 지식을 application(적용)한다는 것은 특정 소프트웨어 요구 사항(예: 고객과 제품 간의 연관성)을 상응하는 개념(여기서 다대다 관계 모델링)으로 일반화하는 것을 의미한다. 또한 software reliability, user experience 또는 system performance과 같은 것을 평가하기 위해 quantitative reasoning(정량적 추론)을 적용하는 것을 의미할 수 있다. (lock's contention이 5% 증가하면 transaction latency(지연)에 어떤 영향을 미칩니까?) 어렵게 얻은 이론 지식의 다른 일반적인 applications(적용)에는 적절한 추상화(예: implementation inheritance(구현 상속), interface inheritance(인터페이스 상속) 또는 parametric polymorphism(매개 변수 다형성) 사용); 구조화된 코드를 통한 복잡성을 taming(control하기 쉽도록 단순화)하기, 특정 문제를 해결하기 위한 기존 방법, 도구, API 및 알고리즘을 적용하는 것이 포함된다.

 

더보기

lock contention이란?

하나의 process 또는 thread 가 다른 process 또는 thread에 의해 유지되는 lock을 얻으려고 시도할 때마다 발생한다. 사용가능한 locks들이 더 세밀할 수록, 하나의 process 또는 thread가 다른 process 또는 thread에 의해 고정되는 lock을 요청하지 않는다. (예를 들면, table 전체 보다 row 또는 하나의 cell을 lock하는 것.)

 

 comprehension(이해)와 관련하여 기존 code sequences를 해석하고, 새 요구 사항에 맞게 그것들을 확장하고, technical debt(기술적 부채)를 줄일 수 있도록 refactoring 할 수 있어야 한다. specification(사양)을 코드로 변환하고 코드를 간결한(concise) 주석으로 요약한 후 동료에게 설명해야 한다. 또한 명쾌한(lucid) narratives와 specified processing의 example를 제공하고 이를 clear writing과 integration 및 unit tests로 표현해야 한다.

더보기

Technical debt이란?

기술 채무(설계 채무 또는 코드 채무라고도 하지만 다른 기술적인 노력과 관련된 수 있음)는 소프트웨어 개발에서 더 오래 걸리는 더 나은 접근 방식을 사용하는 대신, 지금 쉬운 (제한적인) 솔루션을 선택함으로써 야기되는 추가 재작업의 묵시적 비용을 반영하는 개념이다.

 

 소프트웨어 개발 작업에서는 버그와 성능 문제의 가능한 원인을 추론(infer)하고, 복잡한 시스템을 보다 관리가 용이한 elements로 세분화하고, 요구 사항을 우선시하며(prioritize), mind-numbing special cases를 더 넓은 범주로 분류하기 위한 analytical(분석) 기술이 필요하다. 또한 가장 적합한 기능을 선택하기 위해 경쟁 소프트웨어 또는 특정 기능을 수행을 위한 사용자 인터페이스 설계를 비교할 때, analytical(분석) 기술이 유용하다.

 

 더 큰 문제를 더 작은 조각으로 나누도록 도와주는 analytical(분석) 기술과 함께, 기존 fragments(조각)을 더 가치 있는 aggregates(집합체)로 결합하는 synthesis(합성) 기술을 사용합니다. 여기에 대표적인 예가 기존의 소프트웨어 구성 요소와 맞춤형(bespoke) 소프트웨어 구성 요소들로 구성된 대규모 복합 시스템을 설계할 수 있는 능력이다. synthesis합성의 다른 applications(적용)에는 language features(특징)과 API를 활용하여 low-level code construction 하거나, diverse manifestations(다양한 표현)에서 기본 오류에 대한 가설을 도출하거나(deriving), 스크럼 iteration을 계획하거나, 새로운 알고리즘을 고안하는 것이 포함된다.

 

더보기

hand-in-hand(손에 손을 잡은, 친밀한)

be adept[expert] in[at] ..에 능숙하다

 

 마지막으로 evaluation(평가) skill입니다. 개발자로서 여러분은 code review를 수행하고, technical debt(기술적 부채)를 인지하고; 설계, 테스트 방법 및 프로세스를 평가해야 하며; 다양한 기술 대안 중에서 가장 적합한 솔루션을 추천해야 한다.

Interpersonal Skills (대인 관계 기술)

 소프트웨어 개발은 대부분의 경우 광범위한 팀워크와 상당한 개인의 leeway(자유) 및 책임을 결합하기 때문에 대인관계 기술에 크게 의존한다. 이러한 기술들은 또한 대학에서 정식으로 가르치는 경우가 드물다.

 

 이 분야에서는 먼저 collaboration(협업)과 관련된 스킬이 제공된다. 팀의 일원으로서, 조직 내에서 또는 고객과 효과적으로 작업하려면, 다른 사람의 작업에 대한 감사를 표시하고, 적극적으로 듣고, 원격으로 협업할 수 있는 건설적인 피드백을 받고 제공할 수 있어야 한다. 종종 code review, 테스트 및 고객 피드백을 통해 (잔인할 정도로 솔직한) 비판을 받기도 한다. 기분 나빠하지 않고 설계 및 코드를 개선하려면 이 input을 이용하는 데 능숙해야 한다. 또한 (관리를 받거나 다른 이들을 관리하는) 조직의 계층 구조 내에서 원활하게 작업할 수 있어야 한다. 

 

 그리고 ethic(직업윤리)다. 여기에는 professionalisom, respectfulness, dependability(신뢰도), positive attitude, 근무 공간과 software community's etiquette adherence(준수) 등이 포함된다. 정직하고 정확한 일정 추정치를 제공하고 신뢰할 수 있는(dependably) 수준으로 제공할 수 있어야 한다. 코드 및 개발 프로세스 및 공통 작업 소유권에 관한 조직의 conventions(규약)을 이해하고 존중해야 한다. 보다 광범위하게, 여러분은 Q&A forums, open source projects, conference presentations 및 publications(출판물)을 통해 professional 및 scientific community에 다시 기여해야 한다.

 

 개발자로서 여러분은 종종 조직 소프트웨어의 상당한 부분을 책임질 것이다. 이를 위해서는 이러한 책임을 받아들일 수 있는 자신감, 필요한 것을 전달하기 위한 persistence(끈기), 그리고 높은 품질을 유지하기 위한 thoroughness(철저함)과 perfectionism(완벽주의)가 필요하다. 기억하라. 잘못 배치된 bracket은 전체 빌드를 손상시킬 수 있으며, 오류 검사 누락은 전체 조직을 파괴할 수 있다.

 

 빠르게 진화하는 분야에서 전문가가 된다는 것은 새로운 skills, technologies, practives 및 tool 배우는 데 지속적으로 투자해야 한다는 것을 의미한다. 그러기 위해 professional magazines(IEEE 포함)를 읽고, conferences에 참석하고, 새로운 책뿐만 아니라 고전적인 책을 공부하고, 다른 사람들의 코드(open sources softare와 같은 훌륭한 material)를 세심하게 살펴봐라. 당신과 조직의 업무를 개선할 수 있는 측면을 찾고, 단점을 해결할 수 있는 새로운 방법을 배우고 실험할 준비가 되어 있어야 한다.

 

 잔인하게도, 복잡한 기술은 빠르게 deteriorate(나빠질 수 있다). 그렇기 때문에 민간 조종사들도 90일 이내에 최소 3회의 착륙을 수행해야 하며 면허를 최신 상태로 유지하기 위해 2년마다(biennial) 열리는 비행 심사를 통과해야 한다. 프로그래머로서, 이는 여러분이 더 많은 관리 책임을 맡더라도, 직장에서나 취미로 프로그래밍을 계속하는 것을 의미한다.

 

 이 모든 지식과 다양한 기술을 쌓고 유지하는 것은 어려운 일(tall order)처럼 보인다. 이것은 profession(특히 많은 교육이 필요한 적문적인 직업)의 입학금(entry price)이다. 수많은 사람들의 삶, 기업의 효율성, 정부의 기능을 개선할 수 있는 직업이다. 여러분의 두뇌와 키보드를 이용하여 세상을 더 나은 곳으로 만들 수 있는 직업이다.

 

IEEE Software Mission Statement

 

 빠른 기술 변화에 보조를 맞추고자 하는 주요 소프트웨어 전문가, 개발자와 관리자를 위한 신뢰할 수 있고 유용하며 peer-reviewed 정보를 제공하는 최고의 source가 되는 것이다.

 

원문 출처:

 www.computer.org/csdl/magazine/so/2018/04/mso2018040004/13rRUy0qnEp

 

CSDL | IEEE Computer Society

 

www.computer.org

 

반응형