JavaRush /Java Blog /Random-KO /소프트웨어 엔지니어는 누구입니까? 소프트웨어 엔지니어링 VS "그냥" 프로그래밍

소프트웨어 엔지니어는 누구입니까? 소프트웨어 엔지니어링 VS "그냥" 프로그래밍

Random-KO 그룹에 게시되었습니다
우리는 소프트웨어 엔지니어링과 프로그래밍의 차이점, 또는 소프트웨어 개념 개발이 "단지 코딩"과 어떻게 다른지에 대한 Samer Buna의 기사를 각색한 내용을 알려드립니다 .
소프트웨어 엔지니어는 누구입니까?  소프트웨어 공학 VS
모든 소프트웨어 엔지니어는 코딩을 할 수 있지만 모든 프로그래머가 소프트웨어 개념을 개발할 수 있는 것은 아닙니다. 어떤 사람들은 "소프트웨어 엔지니어"(일명 소프트웨어 엔지니어)라는 용어를 좋아하지 않습니다. 예를 들어 건설과 같은 좀 더 물리적인 것에 대해 이야기할 때 "엔지니어"라는 단어를 가장 자주 사용하기 때문입니다. 물론 우리 기사는 용어 자체에 관한 것이 아닙니다. 갑자기 거절을 당하게 된다면 창의성과 관련된 것으로 쉽게 대체될 수 있습니다. "소프트웨어 제작자", "소프트웨어 작성자"... 심지어 "소프트웨어 제작자"!
"소프트웨어 엔지니어"에 대해 말할 때, 주요 업무가 코드 작성뿐 아니라 고품질 애플리케이션을 만드는 사람을 의미합니다. 그리고 여기에서 그는 자신의 작업에 과학적 접근 방식과 통계적 방법을 적용하는 자신의 소명을 봅니다. 그에게 프로그래밍은 단지 음식값을 벌기 위한 수단이 아닙니다.
프로그래밍 능력이 있다고 해서 자동으로 소프트웨어 엔지니어가 되는 것은 아닙니다. 누구나 코딩을 배울 수 있으며 보기보다 훨씬 쉽습니다. 누구나 자신이 사용할 간단한 프로그램을 만들 수 있지만 이것이 동일한 프로그램이 다른 사람에게도 작동한다는 보장은 없습니다. 제가 가장 좋아하는 예는 다음과 같습니다. 우리 중 많은 사람들이 샤워 중에 노래를 부르지만, 아쉽게도 이 공연이 항상 전문적인 무대에 어울리는 것은 아닙니다. 물론, 고품질의 음악적 경험을 위해서는 프로에게 의지할 가능성이 높습니다. 더 많은 예가 필요합니까?
  • 우리 모두는 학교에서 수학과 글쓰기를 배우지만 그것이 우리를 수학자나 작가로 만드는 것은 아닙니다.
  • 우리 대부분은 무난하고 때로는 매우 맛있는 요리를 준비할 수 있지만 모든 사람이 대사관 만찬 파티를 위해 감히 100인용 테이블을 요리할 수는 없습니다. 이 경우에는 요리사를 고용합니다.
  • 레고로 인상적인 걸작을 만들어내는 이웃집 아이에게 새 집 건설을 전적으로 맡길 준비가 되셨나요?
이 글에서 제가 전달하려는 요점은 단순한 프로그램은 엔지니어가 설계한 프로그램과 매우 다르다는 것입니다. 프로그래밍 프로세스의 가장 간단한 정의: 주어진 입력 매개변수에 따라 특정 출력을 얻기 위해 컴퓨터에 대해 순서화된 동작 순서를 그리는 것입니다. 소프트웨어 엔지니어링 프로세스는 많은 사용자의 문제를 해결하기 위해 컴퓨터 프로그램을 설계, 작성, 테스트 및 큐레이션하는 것입니다. 이는 시간의 시험을 견디고 분명하지 않은 알려지지 않은 과제에 대해 작동할 수 있는 안정적이고 안전한 솔루션을 만드는 것입니다.
소프트웨어 엔지니어는 누구입니까?  소프트웨어 공학 VS
소프트웨어 엔지니어는 자신이 해결하는 문제, 제안하는 솔루션, 해당 솔루션의 한계, 개인 정보 보호 및 보안에 대한 모든 것을 알고 있습니다. 제 생각에는 문제의 본질을 이해하지 못하는 사람은 솔루션 프로그래밍을 시작해서는 안됩니다.

엔지니어링 사고방식 - 응용 솔루션 검색

소프트웨어 엔지니어는 소프트웨어 작성 자체를 주요 목표로 생각하지 않습니다. 그들은 필요를 충족시키고 문제를 해결하는 관점에서 생각합니다 . 모든 문제에 소프트웨어 솔루션이 필요한 것은 아니기 때문에 이는 중요합니다. 그 중 일부는 기존 프로그램을 사용하여 처리할 수 있습니다. 일부 문제의 발생은 때때로 사전에 예측될 수 있으며, 유능한 프로그램 설계의 도움으로 향후 이러한 문제를 피할 수 있습니다.

"지식인은 문제를 해결하고, 천재는 문제를 막는다"

- 알베르트 아인슈타인

소프트웨어 엔지니어는 누구입니까?  소프트웨어 공학 VS
복잡한 문제에는 종종 많은 프로그램을 작성해야 합니다. 병렬 실행 애플리케이션이 필요한 작업이 있는 반면, 여러 프로그램을 순차적으로 실행해야 하는 작업도 있습니다. 사용자를 교육하는 것만으로도 여러 가지 문제를 해결할 수 있습니다. 프로그램 작성을 시작하기 전에 소프트웨어 엔지니어는 스스로에게 다음과 같은 질문을 던집니다.
  • 어떤 문제를 해결해야 합니까?
  • 문제를 해결하기 위해 코드를 작성하는 것 외에 무엇을 할 수 있나요?
  • 앱을 사용하여 이러한 작업을 더 쉽게 만들려면 어떻게 해야 합니까?

프로그램 품질 및 코드 품질

좋은 프로그램은 명확하고 읽기 쉽습니다. 확장하기 쉽고 다른 프로그램과 잘 작동하며 작업하기에 악몽이 아닙니다. 코드 품질은 협상할 수 없습니다. 높아야합니다. 그게 전부입니다. 이를 고려할 때 코더의 기분이 좋지 않거나 마감일이 너무 빡빡하다는 변명(아, 마감일!)은 용납되지 않습니다. 소프트웨어 개발의 가장 중요한 측면 중 하나는 향후 유지 관리 및 수정이 쉽도록 프로그램을 설계하는 것입니다(안녕하세요, OOP!). 오늘날 거의 모든 소프트웨어는 수정 가능하며, 종종 이 프로세스는 사용자 참여 없이 발생하거나 "프로그램이 업데이트되었습니다. 확인 또는 연기를 클릭하십시오." 외에는 사용자에게 아무것도 요구하지 않습니다. 물론 사용자는 애플리케이션에서 새로운 기능을 요구할 권리가 있습니다(특히 Java로 작성되어 오랫동안 실행되는 엔터프라이즈 소프트웨어나 수년간 플레이할 수 있는 온라인 게임의 경우).
Java 프로그래밍에 대해 더 알고 싶으십니까? Java 개발자 그룹에 가입하세요 !
코드 자체는 유용하다고 할 수 없습니다. 소프트웨어의 유용한 기능은 서로 다른 응용 프로그램이 서로 통신하고, 데이터를 교환하고, 함께 작동하여 사용자에게 데이터와 인터페이스를 제공하는 작업을 수행하는 곳에서 시작됩니다.
소프트웨어 엔지니어는 누구입니까?  소프트웨어 공학 VS
프로그램은 이러한 점을 염두에 두고 설계되어야 합니다! 그들은 어떤 메시지를 받나요? 어떤 이벤트가 모니터링되나요? 인증 및 승인은 어떻게 이루어지나요? 좋은 프로그램의 또 다른 똑같이 중요한 신호는 애플리케이션이 통과한 테스트 수나 좋은 테스트 범위가 아니라 코드의 명확성입니다. 겉으로는 간단해 보이는 질문: "나 아닌 다른 사람이 내 코드를 이해할 수 있을까?", "오늘 이 코드를 작성하고 몇 주 후에 이해할 수 있을까?" 프로그래밍에서 가장 어려운 두 가지에 대한 유명한 인용문은 다음과 같습니다.

"정말 어려운 일은 캐시 무효화와 엔터티 이름 지정이라는 두 가지뿐입니다."

— 필 칼튼.

코드 가독성은 일반적으로 생각되는 것보다 훨씬 더 중요합니다. 안타깝게도 코드 명확성을 위해 정확한 측정항목이나 매개변수를 정의하는 것은 불가능합니다. 일반적으로 수용되는 언어 규범, 좋은 소프트웨어 모델 및 개발 방법을 기억하는 것이 부분적으로 도움이 될 것입니다. 그러나 일반적으로 이것만으로는 충분하지 않습니다. 시간과 경험을 통해 진정한 전문가는 직관과 유사한 "명확성"을 개발합니다. 글쓰기 비유는 여기서 잘 작동합니다. 단어를 많이 아는 것은 간결하고 의미가 명확한 글을 쓰는 데 도움이 되지 않습니다.

“좀 더 짧게 썼으면 좋았을 텐데 시간이 없었어요.”

- 마크 트웨인.

빠르고 쉽게 버그를 수정하는 능력은 좋은 소프트웨어의 핵심 기능입니다. 프로그램의 오류는 명확한 메시지를 보내고 추적을 위해 중앙에서 기록되어야 합니다. 새로운 오류가 보고되면 이를 수정하는 사람은 해당 오류를 디버그할 수 있는 능력이 있어야 합니다. 그는 시스템에 쉽게 연결하고, 언제든지 실행 정보에 액세스하고, 시스템의 모든 부분의 기능을 쉽게 확인할 수 있어야 합니다.

환경 및 테스트

소프트웨어 엔지니어는 응용 프로그램을 개발할 때 다양한 아키텍처와 운영 체제의 컴퓨터에서 작동하도록 최선을 다합니다. 소프트웨어가 다양한 해상도와 화면 방향에서 작동하고 필요한 것보다 더 많은 메모리와 처리 능력을 "소모"하지 않는 것이 중요합니다.
소프트웨어 엔지니어는 누구입니까?  소프트웨어 공학 VS
웹 애플리케이션의 경우 모든 주요 브라우저에서 작동해야 합니다. 데스크톱 애플리케이션을 만들 때 Mac, Windows 및 Linux에서 올바르게 실행되고 작동하는지 확인해야 합니다. 글쎄, 프로그램은 데이터에 따라 다르므로 데이터 연결이 느리거나 연결이 없는 경우에도 응용 프로그램이 작동해야 합니다. 소프트웨어를 작성하기 위해 엔지니어는 모든 종류의 시나리오 옵션을 생각하고 테스트할 계획을 세웁니다. 모든 것이 오류 없이 작동하는 이상적인 옵션을 선택하는 것부터 시작됩니다. 그런 다음 잠재적인 문제를 문서화하고 이를 테스트 계획에 기록합니다. 일부 엔지니어는 발생할 수 있는 모든 문제와 오류에 대한 시나리오를 시뮬레이션하는 테스트 케이스라고 부르는 코드 작성부터 시작합니다. 그런 다음 고려된 모든 옵션과 함께 작동할 수 있는 프로그램이 작성됩니다. 재능 있는 소프트웨어 엔지니어의 고유한 능력은 코드 작성 방법을 아는 것이 아니라, 애플리케이션이 출력으로 정확히 무엇을 수행해야 하는지, 그리고 이를 달성하는 방법을 이해하는 것입니다. 고객의 소프트웨어 요구 사항이 불완전하고 모호할 수 있는 경우 엔지니어는 이를 올바르게 평가하고 "이해"해야 합니다.

비용과 효율성

대부분의 경우 소프트웨어 엔지니어는 문제를 신속하게 해결할 수 있습니다. "비싼" 숙련된 프로그래머를 고용하면 비용이 증가할 것이라고 생각한다면 다시 생각해 보십시오. 고용된 프로그래머의 경험이 많을수록 그는 간단하고 깔끔하고 안정적이며 사용하기 쉬운 솔루션을 더 빨리 제공할 수 있습니다. 장기적으로 이는 소프트웨어 개발 비용을 확실히 줄여줄 것입니다.
소프트웨어 엔지니어는 누구입니까?  소프트웨어 공학 VS
프로그램을 실행하는 데 드는 비용도 고려해야 합니다. 모든 프로그램은 컴퓨팅 리소스를 사용하며 무료가 아닙니다.
소프트웨어 엔지니어의 임무는 컴퓨팅 리소스를 불필요하게 사용하지 않는 효율적인 코드를 작성하는 것입니다.
예를 들어 자주 액세스하는 데이터를 캐싱하는 것은 원하는 결과를 얻는 데 사용할 수 있는 전략 중 하나입니다. 그러나 이는 프로그램을 더 빠르고 효율적으로 만들 수 있는 수백 가지 도구와 솔루션 중 하나일 뿐입니다. 초보 프로그래머는 저렴한 솔루션을 제공할 수 있지만, 그러한 솔루션을 사용하면 처음에 효과적인 솔루션을 만든 숙련된 개발자와 함께 작업하는 것보다 궁극적으로 귀하와 귀하의 고객에게 훨씬 더 많은 비용이 소요됩니다.

사용자 경험에 집중

좋은 프로그래머는 사용자 경험(UX)을 염두에 두고 개발합니다. 인간과 기계의 상호작용은 끝없는 연구와 솔루션이 필요한 주제입니다. 더 많은 솔루션을 적용할수록 프로그램은 더 좋아질 것입니다. 다음은 이 방향이 무엇인지에 대한 느낌을 주기 위한 몇 가지 예입니다.
  • 이메일과 같은 데이터 입력 양식을 디자인할 때 좋은 프로그램은 이메일 주소의 대소문자를 무시해야 합니다. 이메일 주소는 소문자로 고유하므로 CAPSLOCK 키를 눌러도 오류가 발생하지 않습니다. 프로그램이 새 이메일 주소를 입력으로 받아들이면 입력 프로세스 초기에 이를 확인하여 사용자에게 잘못된 주소 형식을 사용하고 있음을 알립니다. 이 솔루션에는 "@" 기호 누락과 같은 명백한 검사와 "gmail.ocm"과 같은 잘못된 문자 순서 검사와 같이 그다지 명확하지 않은 검사가 모두 포함됩니다.

  • 사용자가 어떤 작업을 수행하도록 리디렉션되면 좋은 프로그램은 사용자의 현재 위치를 기억하고 작업이 끝나면 다시 사용자에게 반환해야 합니다. 좋은 프로그램은 사용자가 이미 전송한 데이터도 기억해야 하며, 이는 사용자와의 추가 상호 작용에 중요합니다.

    Expedia에서 손님으로 항공 여행을 검색하고 있다고 가정해 보겠습니다. 나중에 계정을 만들기로 결정합니다. 앱은 모든 이전 검색을 새 계정에 저장해야 하며 다른 기기에서 해당 검색에 액세스할 수 있어야 합니다.


  • 소프트웨어 엔지니어는 누구입니까?  소프트웨어 공학 VS
  • 좋은 프로그램은 사용자 행동 시나리오를 염두에 두고 설계됩니다. 단순히 "그렇다"라는 기준으로 새로운 기능을 추가할 필요가 없으며 사용자의 입장에서 생각해보세요. 어느 날 비행기 표를 예약하다가 상용 고객 번호를 입력하는 것을 잊어버렸습니다. 확인을 받은 후 항공사 홈페이지에 가서 추가해서 할인을 받기로 했어요. 이 작업을 수행하는 방법을 알아내기 위해 저는 10분 동안 사이트를 둘러보았습니다. 응용 프로그램이 너무 눈에 띄지 않아서 필요한 것을 찾기 위해 사이트의 여러 페이지를 목적 없이 돌아다녔습니다. 나중에 나는 이미 몇 번이나 올바른 페이지에 도착했음을 발견했지만, 내가 필요한 필드가 거대한 형태의 다른 유사한 필드 중에서 손실되었기 때문에 그것을 이해하지도 못했습니다.

    여행 정보를 편집하려면 약 20줄의 양식을 스크롤하고 로열티 카드 번호와 전화번호를 입력해야 했는데, 그렇지 않으면 확인을 위해 양식을 보낼 수 없었습니다. 이는 사용자가 얼마나 편안하게 사용할지 고려하지 않고 개발된 프로그램의 예입니다.

신뢰성, 보안 및 안전

제 생각에는 전문 소프트웨어 개발자와 아마추어 사이의 가장 중요한 차이점은 애플리케이션을 만들 때 애플리케이션의 신뢰성, 보안, 안전성과 같은 매개변수를 고려하는 것입니다.
진정한 전문가는 솔루션의 안전과 보안에 대한 책임이 자신에게 있다는 것을 알고 있습니다.
프로그램의 일부는 잘못된 입력, 잘못된 상태 및 잘못된 상호 작용을 허용해야 합니다. 이는 실제로 시행하기가 매우 어렵고 소프트웨어 버그로 인해 사람들이 사망한다는 이야기를 듣는 주된 이유입니다. 사용자는 프로그램에 잘못된 데이터를 입력했고, 입력하고 있으며 계속 입력할 것입니다. 이는 사실로 받아들여야 합니다. 또한 일부는 애플리케이션을 중단하고 사용 가능한 리소스를 확보하려는 목적으로 의도적으로 이 작업을 수행합니다.
소프트웨어 엔지니어는 누구입니까?  소프트웨어 공학 VS
실제 사례는 다음과 같습니다. 최근 Equifax 데이터 유출 사건에 책임이 있는 것으로 알려진 사람은 대중에게 제공되는 모든 소프트웨어 제품에서 나쁘고 악의적인 입력에 저항하는 솔루션을 개발하는 직무를 수행하지 못했다는 이유로 기소되었습니다. 정보보안 관련 사고에는 부정확하고 악의적인 입력뿐만 아니라, 부정확하게 입력된 데이터도 포함됩니다. 사용자가 비밀번호를 잊어버린 경우 몇 번이나 비밀번호 입력을 시도할 수 있습니까? 이 후에는 그 사람을 차단할 건가요? 다른 사람이 자신의 계정을 차단하려고 하면 어떻게 되나요? 사용자가 암호화되지 않은 데이터 채널을 통해 자격 증명을 전송할 수 있습니까? 로그인 요청이 비정상적인 위치에서 온 경우 어떻게 되나요? 로그인 시도가 자동으로 이루어진 것으로 나타나면 어떻게 하시겠습니까? 교차 사이트 스크립팅, 교차 사이트 요청 위조 및 일반적인 피싱으로부터 사용자를 보호하기 위해 어떤 조치를 취했습니까? 서버에 DDoS 공격이 발생할 경우를 대비한 백업 전략이 있습니까? 이러한 질문은 고려해야 할 몇 가지 문제를 강조합니다. 보호된 프로그램은 중요한 정보를 텍스트 형식으로 저장하지 않습니다. 복잡한 단방향 암호(암호화하기는 쉽지만 키 없이는 해독이 거의 불가능한 암호)로 이를 보호합니다. 프로그램이 해킹당할 경우를 대비한 백업 대책입니다. 해커는 자신에게 쓸모가 없는 암호화된 데이터를 발견하게 됩니다. 최고의 프로그램에서도 예상치 못한 문제가 발생합니다. 이러한 상황에 대비하지 않은 프로그래머는 전문가라고 할 수 없습니다. 예상치 못한 행동을 예상하기 전까지는 그는 엔지니어가 아닙니다. 그는 "안전하지 않은 프로그램의 작성자"입니다. 프로그램의 오류가 항상 명확한 것은 아닙니다. 알려진 오류를 예측하고 예방하는 우리의 지적 능력은 제한되어 있습니다. 이것이 바로 소프트웨어 엔지니어가 정확하고 안전한 소프트웨어를 작성할 수 있는 좋은 도구의 중요성을 이해하는 이유입니다.

필수 도구

다양하고 좋은 개발 도구가 필요하다는 것은 의심의 여지가 없습니다. 그들의 역할은 종종 과소평가되지만 실제로는 많은 시간과 노력을 절약하여 일부 작업을 대폭 단순화합니다. 배포를 위해 여전히 FTP를 통해 파일을 업로드해야 한다고 상상해 보십시오. 말하자면 구식 방식입니다. Chrome DevTools 없이 네트워크 및 성능 문제를 디버깅한다고 상상해보세요! 그리고 요즘 ESlit과 Prettier 없이 JavaScript 코드를 작성하는 것은 얼마나 비효율적일까요!
소프트웨어 엔지니어는 누구입니까?  소프트웨어 공학 VS
코드를 작성할 때 피드백 시간을 줄여주는 도구라면 환영받을 것입니다. 이전에는 나에게 낯설었지만 정말로 유용하고 효과적인 도구를 발견했을 때, 나는 그 행복한 순간 이전에 그것을 사용하지 않았다는 사실을 후회할 수밖에 없습니다.
더 좋고 더 현대적인 도구는 당신이 더 나은 프로그래머가 되는 데 도움이 될 것입니다. 그것들을 찾고, 사용하고, 감사하고, 가능하다면 개선하십시오. 그리고 같은 일에 매달리지 마십시오. 새로운 도구를 사용하면 한 번 설치하고 학습하는 데 시간을 소비하고 문제를 몇 배 더 빨리 해결할 수 있다는 것을 누가 압니까?

소프트웨어 공학의 진화

누구도 2개월, 6개월, 심지어 1년 안에 소프트웨어 엔지니어링을 배울 수 없습니다. 교육 과정, 대학 또는 부트 캠프에서는 소프트웨어 엔지니어가 되는 방법을 배우지 않습니다. 나는 지난 20여년 동안 공부해왔고 지금도 계속 공부하고 있습니다. 나는 수천 명의 사용자가 사용하는 응용 프로그램을 배우고 개발하고 만들고 유지 관리한 지 10년이 지나서야 자신을 숙련된 프로그래머라고 편안하게 부를 수 있었습니다. 소프트웨어 엔지니어링은 모든 사람을 위한 것은 아니지만 모든 사람은 컴퓨터를 사용하여 문제를 해결하는 방법을 배워야 합니다. 간단한 프로그램을 작성하는 방법을 배울 수 있다면 배워야 합니다. 공개적으로 사용 가능한 소프트웨어를 사용하는 방법을 배울 수 있다면 배워야 합니다. 오픈 소스 소프트웨어 사용법을 배우고 이를 스스로 맞춤화할 수 있다면 당신은 초능력을 갖게 됩니다! 매일 개발자에게 새로운 과제와 새로운 문제가 발생하므로 소프트웨어 엔지니어링이 필요합니다. 이 직업의 주요 임무는 일반인이 수년 동안 소프트웨어를 다룰 필요가 없도록 소프트웨어를 만드는 것입니다. 따라서 프로그램과 상호 작용하기 위해 오랜 연구를 할 필요가 없습니다. 그럼에도 불구하고 소프트웨어 엔지니어는 더 복잡한 알려진 문제를 해결할 수 있는 더 나은 도구를 만드는 방법에 대해 끊임없이 생각하고 있으며 새로운 문제가 가능한 한 거의 나타나지 않도록 가능한 모든 노력을 다하고 있습니다.
코멘트
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION