소프트웨어 엔지니어링에 대한 잘못된 생각이 있습니까? [닫은]

최근 직장에서 인턴으로 제기 된 질문이 있습니다.

상황을 이해하기 위해-저는 21 살이고 시스템 관리자 / QA 작업을하는 데 약 2 년의 경험이 있기 전에 2 년제 대학을 마치고 기본적으로 어떻게 다른지 알 수 있습니다. IT 부문이 운영되었습니다. 현재를 향해 전진하며 영국 최고의 연구소 중 하나에 인턴쉽을 시작합니다.

내가해야 할 일은 다양한 기술 (주로 AWS / Java / Bash)을 사용하여 내부 도구를 만드는 것입니다. 모든 것이 정상입니다. 저는 일을하고 있지만 행복하지는 않습니다. 그 이유는 무엇입니까-내가 임시 문제로 일할 것으로 예상되기 때문입니다. 디자인에 시간을 들이지 않고 빠르게 물건을 만들 수 있습니다. 제 관리자는 문제가 발생할 때 우리는 본질적으로 문제를 "돌출"할 것이라고 명시 적으로 말했습니다. 결과적으로 일을 다시하고 다시 엔지니어링해야하며 여전히 완벽하지는 않은 것으로 나타났습니다. 테스트에 관한 한, 작동하는 것처럼 보이는 한 최소한으로 유지하십시오.

이런 일을하는 방식에 동의하지 않는 것이 잘못입니까? 시스템 전체에 대해 생각한 다음 다른 구성 요소에 중점을두고 서로 상호 작용할 수있는 방법을보고, 나중에 문제가 될 수있는 다른 "핵심 포인트"를 제로화하는 것이 잘못입니까? "빠른 일"이 아닌 좋은 일을하는 것이 범죄입니까? 특정 문제 세트에 따라 최상의 것을 선택할 수 있도록 문제에 적용 할 수있는 데이터 구조를 조사하는 것이 실수이거나 잘못된 태도입니까? 내가 아는 한 "소프트웨어 엔지니어링"의 "엔지니어링"비트는 정확히 이와 관련이 있습니다. 문제 영역을 조사하고 정보에 기초한 솔루션을 찾은 다음 필요에 따라 수정 하시겠습니까?

나는 영국 팔 사무실에서 인터뷰를했고 그들은 저에게 SCRUM 방을 보여 주었고 프로젝트 관리 방법에 대해 꽤 좋은 생각을 보였습니다. SCRUM의 일반적인 문제-문제가 "여기"에서 실행되는 방식과 완전히 다른 문제를 해결하는 데 걸릴 수 있습니다.

소프트웨어 산업에 대한 잘못된 아이디어를 만들었습니까? 당신의 의견을 듣고 싶습니다. 나는 단순하고 단순하게 물건을 만들고 싶지만 양질의 물건을 만들고 싶기 때문에 소프트웨어 개발에 순전히 "진입"했다. 다양한 시나리오에서 사용되는 소프트웨어를보고 싶습니다. 방탄으로보고 싶습니다. 모든 소프트웨어 엔지니어의 원동력이 아닙니까? 나는 구문을 배우는 것만으로 누구나 프로그래머 / 코더가 될 수 있다고 생각하지만 실제 재미가 시작되는 곳은 실제로 현실에서 가능한 디자인을 생각해 내야 할 때입니다.

예전에는 대학 과제를보고 직접 코딩을 시작하여 75 % 이상을 쉽게 획득 할 수 있었으며 "소프트웨어 개발 수명주기"모듈을 결코 높이 평가하지 않았습니다. 그러나 현실 세계에서 공식적인 프로세스없이 작업하는 것이 얼마나 나쁜지를 보았을 때 요구 사항이 내일 변경 될지 모른다는 상황에서 내재 된 좌절은 (오, 우리는 그렇지 않다고 말했습니까? 요구 사항 분석이 명확하게 정의되어 있지 않습니까?)

나는 사람들이 더러운 작업을 수행하기 위해 코드 원숭이가 필요했던 위치를 방문했다고 생각하고 싶습니다. 이는 소프트웨어 세계가 크게 작동하는 방식이 아닙니다.

소프트웨어 재사용 및 방탄을 만드는 것은 소프트웨어 엔지니어링의 원동력 이 아닙니다 . 엔지니어링은 실제 제약 조건 내에서 실제 문제를 최적으로 해결하는 것입니다 . 대부분의 엔지니어는 페라리 작업을 선호하지만 스테이션 왜건은 많은 엔지니어링이 필요하며 스테이션 왜건이 (어떻게 든) 성능이 좋지 않은 이유는 더 어려운 엔지니어링 제약 때문이 아니라 설계 제약이 더 까다롭기 때문입니다. .

"빠른 일"보다는 "좋은 일"을하고 싶을 때, 대부분의 엔지니어들은하지만 좋은 일을 정의하는 것의 일부는 얼마나 빨리 완료 하는가입니다. 따라서 "좋은"과 "빠른"을 반대 선택으로 생각하는 것은 옳지 않습니다. 또는 당신이 시간에 최선의 작업을 수행하기 위해 당신이 나쁜 일을하고 있거나 "코드 원숭이"라고 생각합니다.

물론 프로세스가 최적화되지 않았을 수 있으며, 조금 더 설계를하면 더 나은 결과를 얻을 수 있습니다. 산성 테스트는 사용자에게 해결하는 것보다 더 많은 문제를 일으키는 일을하는 현재의 방법입니까, 아니면 그 방식으로 작업해야하는 개발자를 괴롭히는 것일까 요? 실제로 사용자에게 문제를 일으키는 경우 업무의 일부는 이것이 사실임을 입증하고 사람들을 좀 더 통제 된 프로세스로 이끄는 것입니다.

사실, 이것은 나를 귀찮게합니다. 당신은 연구 과학자를위한 도구를 개발하는 직업에 있습니다. 그러나 이러한 프로그램을 신속하게 작성하고 최소한으로 작동하는 것으로 표시됩니다. 놀람. 이것은 단순히 실제 프로그래머에게 전달 된 벅으로 프로그래밍에 대한 연구원의 전형적인 접근 방식입니다.

여기서 중요한 문제는 도구가 중요한 목적을 가지고 있다면 특히 테스트 부족이 윤리적으로 모호 할 수 있다는 것입니다. 테스트 시간이 최소로 제한되어 소프트웨어에 결함이 있는지 확실하지 않은 경우 소프트웨어의 작동 상태에 대해 책임을지지 않는 사람이 아무도 없으며 Atlas는 어깨를 으 rug합니다.

그래도 잠시 멈추고 생각해 보자. 어떤 종류의 도구를 개발하고 있습니까? 데이터를 모델링하는 소프트웨어를 개발하는 경우 여기 에는 큰 윤리적 딜레마가 있습니다. 어떤 상황에서 과학적 연구는 많은 사람들에게 큰 영향을 미치는 결정을 내립니다.

인공 기후 변화라는 논란의 여지가있는 주제를 즉각 생각해 보자. 그들이 오늘날의 결론에 도달하기 위해 사용하는 모델링 소프트웨어에 대해 동일한 표준을 설정했다고 가정 해 봅시다. 이 주제는 환경 및 국제 정책을 올바르게 관리하는 방법에 큰 영향을 미칩니다.

모델링 소프트웨어가 예측에 큰 문제가 없는지 확인하는 것이 윤리적이지 않습니까?

온실 가스가 지구를 따뜻하게하는 것은 문제가 아닙니다. 문제는 피드백 효과의 최종 결과가 온도의 가속 이득인지 여부이며, 임계 값을 초과 한 후에는 더 이상 가역적이지 않습니다.

상기 이득이 발생했다면, 순 결과의 증거는 아마도 오류 범위 내에서 한계가있을 것입니다.

따라서 데이터 저장 및 백엔드 검색과 관련된 방법론조차도 약간의 오해로 인해 실패의 한 끝에 심각한 환경 문제를 무시하거나 많은 사람들에게 영향을 미치는 국제 정책 (직업 파괴, 연금 파괴 등)을 초래할 수 있습니다. )에.

네, 맞습니다. 연구의 속도가 얼마인지는 상관하지 않습니다 ... 연구원들이 데이터를 관리하고 계산을 수행하기 위해 소프트웨어 도구에 의존하려면 소프트웨어가 올바르게 수행되는 것을 기다리는 법을 배워야합니다. 그렇지 않으면이 소프트웨어는 자신이 책임을지지 않는 이론의 취약점이되어 윤리적 위법 행위를 초래합니다.

소프트웨어 엔지니어링이 무엇인지에 대한 잘못된 생각이 없습니다. 그러나 매우 중요한 부분을 놓치고 있습니다. 이것이 서비스 산업입니다. 우리 중 일부는 몇 년 동안 제품을 연구하고 v1에 들어가기 전에 디자인을 반복 한 다음 여러 번 반복합니다. 다른 사람들은 3 시간 안에 무언가를 생산해야합니다. 서비스를받는 사람과 목적에 따라 다릅니다.

3 시간 (또는 며칠) 내에 원하는 기능을 수행 할 수있는 응용 프로그램을 제작할 수 있다면, 초기 설계에 더 많은 시간을 투자해야하는 이유는 무엇입니까? 당신은 돈을 낭비하고 있습니다. 돈 낭비는 일반적으로 Good Idea ™가 아닙니다.

다른 사람들이 이미 말했듯이 소프트웨어 엔지니어링의 주요 부분은 "외부 적 제약"입니다. 예. 시간, 예산, 서비스, 지원, 비이성적 인 바보 같은 요구를 충족시키는 등

우리 중 많은 사람들 (나 자신을 포함하여)은 프로그래밍 자체에 관한 모든 것을 생각하고 프로그래밍에 들어갔다. 아름답고 우아한 소프트웨어를 진공 (또는 적어도 상대 진공)으로 코딩하는 것이다. 거의 없습니다. 가까운 학문적 또는 R & D 소프트웨어 작업이있을 수 있지만 대부분의 경우 소프트웨어 개발 작업이 압도적으로 많은 것은 아닙니다. 특히 유지 보수 단계 (일반적으로 제품 수명의 90 % 이상)와 대부분의 영구 상용 소프트웨어 작업의 일상적인 빵과 버터.

오랫동안, 나는 이것에 대해 내부 갈등을 일으켜 종종 내 일에 대해 불행하게 만들었습니다. 나는 항상 아름다운 코드를 만들고 적절하게 수행하는 데 시간이 걸리는 것이 아니라면 일이 짜증 났다고 느꼈습니다 . 그러나 실제로 이것은 현실이며 일부 사람들은 실제로 매우 서비스 지향적 인 작업 흐름에서 번창합니다. 그것이 실용적이고 유용하다고 느끼게하는 것입니다. 프로젝트의 실제 "순수한 소프트웨어 엔지니어링"측면이 비교적 서두르고 조잡합니다.

어쨌든, 지금이 질문을하는 것이 좋습니다. 이것은 그들이 학교에서 제대로 설명하지 못하는 것들 중 하나입니다. 그리고 회사는 비록 그렇지 않더라도 아주 훌륭한 엔지니어링 관행을 따르는 척하는 것을 좋아합니다. 힌트 : 대부분 그렇지 않습니다.

말한대로 상황이 다릅니다. 특정 회사 (주로 소프트웨어가 핵심 비즈니스이며 의료 장비와 같이 안전이 중요한 소프트웨어를 사용하는 회사)는 매우 엄격한 엔지니어링 프로세스를 따릅니다. 그러나 전반적으로, 대부분의 상용 소프트웨어 작업이 상대적으로 조잡 해졌다는 것을 빈칸으로 지적하겠습니다. 일반적으로 공식적인 절차가 있지만,이를 준수하는 것은 거의 항상 고객의 의견 및 기타 상업적 압력에 대응하기 위해 뒷좌석을 취합니다. 그것은 실제로 "느슨 함"이 아니라 단지 실제적인 실용적인 유용성입니다. 비결은 틈새를 찾아서 "순수한 프로그래밍"측면이 얼마나 멋진지가 아니라 제공하는 서비스의 관점에서 역할을 보는 것입니다.

편집 : 내 초기 평가에서 너무 일방적으로 들렸다 고 생각합니다. 프로젝트가 기술적 부채로 이어져 실제로 비즈니스에 좋지 않은 점까지 너무 조잡하고 좋은 프로세스가 부족한 문제 가 종종 있다고 덧붙이고 싶습니다 . 그러나 이것을 보는 것은 경험과 함께 제공됩니다. 초기의 요점은 여전히 ​​기본적입니다. 오늘날 대부분의 상용 소프트웨어 작업은 순수 주의자가 원하는 것처럼 공학 지향적이지 않습니다.

정말 훌륭한 질문입니다! 때때로 당신은 금식 함으로써 가치있는 것을 만들 수 있습니다 . 이것은 일반적으로 우리가 모르는 것을 빨리 배울 수있는 연구소의 경우입니다. 귀하가 생산하는 소프트웨어는 질문에 답변하기 위해 존재합니다. 「폐기 코드」입니다. 고객이 실제로 무엇을 원하는지 모르는 신생 기업의 경우도 마찬가지입니다. 또한 처음으로 무언가를 만들면 엉망이 될 것입니다. 신화적인 남자-월을 읽으십시오 .

때때로 당신은 좋은 것을 통해 가치있는 것을 만들 수 있습니다 . 이것은 일반적으로 Adobe Photoshop과 같은 수축 포장 소프트웨어의 경우입니다. 연구는 이미 몇 년 전에 이루어졌으며 이제 문제는 고객이 원하는 기능 목록을 버그를 도입하지 않는 방식으로 추가하는 방법입니다. 아키텍처, 디자인 및 테스트, 테스트, 테스트의 문제입니다. 코드 자체는 배우는 것이 아니라 귀중한 것입니다.

당신이 연구에 만족하지 않는다면 (아무것도 모르는 새로운 것을 배우면서) 무엇인가 축소 된 소프트웨어를 사용해보십시오. 실제로, 당신의 나이에 가능한 한 많은 것을 시도해야합니다. 위험을 감수하십시오! 많은 것을 배우고 장기적으로 더 나아질 것입니다.

경력 초기에 적절한 디자인이나 적절한 테스트없이 빠르게 일을하는 것이 당신에게 물려 오는 경향이 있음을 알게되었습니다. 당신은 분명히 이것을 좋아하지 않으며 당신은하지 않을 좋은 이유가 있습니다. 특히 초기 솔루션이 부정확하거나 불완전한 경우 나중에 다시 방문해야하는 경우 "문제를 겪고"예상되는 것은 우스운 일입니다. 문제를 완전히 이해 한 경우에만 솔루션을 제공 할 수 있으며 시간과 신중한 계획이 필요합니다.

당신에게 나의 제안은 당신의 상사에게 이것이 당신을 귀찮게하고 그들에게 당신의 일을하는 더 나은 접근법을 제안한다는 것을 알리는 것입니다. 그들이 동의하지 않고 당신이 당신의 일을 계속해서 "러쉬"하기를 원한다면, 나는 다른 곳에서 일자리를 찾기 시작할 것입니다. 업계에서 기대하는 소프트웨어 개발 품질 표준은 물론, 자신의 표준에 맞지 않는 방식으로 작업을 수행하는 것은 의미가 없습니다.

여기 내 경험에 근거한 조언이 있습니다. 저는 20 살이며 현재 영국의 주요 금융 기관에서 일하고 있으며 몇 달 전과 같은 느낌을 가지고 있습니다. 당신이하고있는 일.

내가 의미하는 바는 다음과 같습니다.

"내가해야 할 일은 다양한 기술 (주로 AWS / Java / Bash)을 사용하여 내부 도구를 만드는 것입니다."

또한 특정 프로세스를 관리하고 자동화하는 데 도움이되는 내부 도구를 만들어야했습니다. 사실 빠르게 진행되는 환경에서는 "작은"것이 신속하게 구현되어야합니다. 몇 주 안에 도구의 작동 버전이 필요했기 때문에 2 년째에 배운 소프트웨어 엔지니어링 또는 알고리즘과 데이터 구조 원칙을 적용 할 수있는 고급 스러움이 없었습니다. 더 읽기 쉬운 코드를 작성하는 방법을 배웠으므로 모두 나쁘지는 않습니다.

나는 인내심을 가지고 최근에 10K + 사용자가 사용하는 사내 구축 시스템의 새로운 반복 작업을 수행하는 새로운 팀으로 교체했으며 소프트웨어 엔지니어링 측면이 매우 심각하게 보장되도록 할 수 있습니다. 요구 사항 캡처 / 분석에서 구현 및 테스트에 이르기까지 전체 소프트웨어 수명주기에 노출 될 것이라고 들었습니다. 내부 도구는 사용하지 않지만 대규모 사용자 기반을 갖춘 본격적인 시스템에서 작업하기 때문에 이러한 경험을 얻을 수 있다고 생각합니다.

내가 추천하는 것은 인내심이 있고 도구 작성을 마치고 훌륭한 일을 수행하여 감독자가 더 많은 신뢰를 얻고 소프트웨어 엔지니어링 원칙을 사용해야하는 더 어려운 과제를 할당하는 것입니다. 여분의 독서를 통해 추가 지식을 얻고 현재하고있는 일에 그 지식을 적용하십시오. 저는 전자 책 라이브러리 전체를 내 지식을 더 발전시키기 위해 회사에 보관하는 것을 기억합니다. 내가 읽은 모든 책에서 효과적인 Java는 정말 좋은 책이 많이 도움이되었습니다.

인내심을 갖고 자신의 지식에 많은 투자를하고 가능한 경우 해당 지식을 적용하십시오. 당신이 아주 좋은 일을하고 있다면 누군가 곧 알게 될 것입니다.

귀하의 현재 작업 방식이 최적이 아님에 동의합니다. 예. 그러나 그것이 전혀 효과가 없다고 말하고 싶다면 다양한 결과가 있고 기관이 여전히 남아 있기 때문에 동의하지 않을 것입니다.

다시 한 번 주된 질문은 의료 환자의 응급 처치를 제공하는 것과 마찬가지로 즉각적인 해결책을 요구하는 화재와 프로젝트로 설정하여 의료 환자와 매우 다른 규모로 처리 할 수있는 요청을 다루는 화재를 어느 정도 다루고 있는가입니다. 즉시 수행 할 필요는 없지만 가까운 시일 내에 테스트 및 다양한 절차를 예약해야합니다.

일을 잘하는 데 시간을내는 것은 조직의 성숙도에 따라 결정되며 어떤 일을 잘 수행하는 것이 중요하다고 주장하는 것과 중요합니다.

데이터 구조를 연구하는 데 대한 질문은 얼마나 오래 수행하고 싶은가입니다. 몇 시간을 원하는 것과는 다른 데이터 구조를 연구하는 데 10 년이 걸리는 경우. 최고의 답변을 얻고 자하는 소망에 감사 할 수는 있지만, 문제에 대해 시간을 보낸 후 수익 감소에 대해 할 말이 있습니다. 예를 들어 FizzBuzz에 대한 해결책을 찾기 위해 여러 언어로 문제를 해결할 수 있습니다. 실행 속도를 최적화하는 다양한 하드웨어.

연구하는 것이 중요 할 수도 있지만 무언가를 제공하는 것도 중요합니다. 당신이 무언가를 전달하지 않으면, 당신은 정말로 얼마나 좋은가? 덕트 테이프 프로그래머 는 여기에서 일을 처리하는 데 더 많은 예가 될 것입니다.

스크럼은 현재 직장에서 채택하려고 할 수있는 구체적인 방법입니다. 스크럼이 은색 총알이라고 생각하지 마십시오. 스크럼과 애자일 프로젝트는 어떤 상황에서 실패 할 수 있습니까? 관심이있을만한 주제에 대한 블로그 게시물입니다.

내 생각에 당신은 현재 장소의 프로세스가 얼마나 비공식적인지 보지 못하고 공식적인 방법론이있는 반대쪽에서 잔디가 엄청나게 녹색이라고 생각합니다. 그것이 더 나을지 모르지만, 어떤 사람들은 카우보이 가 될 수있는 엄청난 자유를 가지고있는 것을 선호 할 수 있습니다 .

나는 당신의 상황이 여전히 품질 측면에 대한 강조를 줄이기 위해 여전히 실제 규모에 있다고 생각합니다. 당신의 선호는 현실 세계의 다른쪽에 있습니다. 사양이 바뀌고 극복하십시오. 해야 할 일이 있습니다.

다음 직업을 신청할 때 이러한 유형의 회사를 식별하는 방법을 고려하십시오. 개발자가 자신의 디자인을 영원히 분석 할 수있는 비즈니스 모델이있는 곳은 거의 없습니다 (교수도 교육해야 함). 작업이 드라이 소거 보드를 떠나지 않으면 고객은 거의 지불하지 않습니다. 경력 초기에 자신을 미치게 만드는 것을 싫어하십시오.