나의 부정적인 인턴십 경험이 실제 세계를 대표합니까? [닫은]

인턴으로서의 현재 경험이 실제 산업을 대표하는지 궁금합니다.

배경으로 저는 전공 대학의 두 전공과 수학 전공의 더 나은 부분을 겪고 있습니다. 나는 모든 수업을 밟고 모든 것을 숭배 했으므로 프로그래밍에 끔찍하지 않다고 생각하고 싶습니다. 저는 주요 소프트웨어 회사 중 한 곳과 인턴십을했으며 지금은 절반 정도의 낮은 품질의 코드에 충격을 받았습니다. 주석은 존재하지 않으며 모든 스파게티 코드이며 잘못 될 수있는 모든 것이 훨씬 나쁩니다. 나는 많은 과외 / TAing을 해왔으므로 나쁜 코드를 읽는 데 매우 익숙하지만, 내가 본 주요 산업 제품은 그 모든 것을 능가합니다. 나는 하루에 10 ~ 12 시간 일하고 어디로 가고 있는지 느끼지 않습니다. 문서화되지 않은 API를 파악하거나 (완전히 문서화되지 않은) 제품의 일부 다른 부분의 동작을 결정하려는 시간 나는 지금까지 일을 미워하는 일을 떠났고, 이것이 내 인생의 나머지 부분에 무엇이 있는지 알고 싶었습니다.

인턴쉽에 짧은 밀짚 모습을 했습니까 (이상하게도 월급이 낮 으면 품질이 낮지 않다는 것을 암시합니까) 아니면 실제 세계와 같은 것입니까?

그들은이를 이유로 Real World ™라고 부릅니다.

실제 기업 세계에서 당신이 겪게 될 것의 99 %는 쓰레기로 간주 될 것입니다. 쓰레기로 간주되지 않는 1 %는 결국 쓰레기가됩니다.

# 1 쓰기 코드, # 2 ????, # 3 Profit!

첫째, 사업체가 이익을 돌리기 위해 존재하지만, 완벽하게 황금 저장소에 보관 된 완벽하게 이론적으로 깨끗하고 깔끔한 학문적 코드를 생성하는 산은 존재 하지 않습니다 . 심지어 소스 코드를 판매하는 비즈니스조차도 가깝지 않습니다.

비즈니스 세계에서 코드는 끝 의 수단 입니다. 일부 코드가 비즈니스 문제를 해결하고 작성 및 유지 관리하는 데 드는 비용보다 많은 돈을 버는 경우 비즈니스에 바람직합니다. 코드 작성을 고용하는 것은 비즈니스가 코드를 얻는 한 가지 방법 일뿐입니다.

이론 0-실습 ∞

이상적으로는 유지 관리가 더 중요하지만 단기적으로는 재정적으로 이기지 않기 때문에 일반적으로 그렇지 않습니다. 장기적으로 소프트웨어는 일반적으로 상대적으로 짧은 수명주기, 특히 웹 기반 응용 프로그램을 사용하므로 더 빨리 사용되지 않으며 더 자주 다시 작성됩니다.

사내 업무용 응용 프로그램은 많은 운동량 기반 이유로 끝없는 좀비 프로젝트로 인식되는 응용 프로그램입니다. 이 프로젝트는 실제로 사업의 이익을 계속하기 때문에 계속해서 성공 합니다.

이론적으로는 이론과 실제에 차이가 없습니다. 실제로는 있습니다. -요기 베라

이론적으로 100 % 코드 적용 범위를 갖춘 완벽하게 깨끗한 원시 코드 기반은 회사의 비용을 절감해야하지만 실제로는 유효한 투자 수익률에 근접한 어떤 것도 제공하지 못합니다.

소프트웨어 라이프 사이클의 물리

또한 소프트웨어 세계에서 작동하는 초강력 엔트로피 힘이 있습니다. 모든 소프트웨어가 Big Ball of Mud 로 퇴화되는 것을 비난하는 불가피한 블랙홀입니다 .

BBM 에서 더 멀리 시작 할수록 더 나아지지만 모든 소프트웨어 시스템은 결국 충분한 시간을 갖습니다. 100 % 엔트로피에 얼마나 빨리 접근 하는가는 시작하는 위치와 기술 부채에 얼마나 빨리 쌓이는 지, 그리고 그것에 대한 관심이 얼마나 높은가에 따라 결정됩니다.

소프트웨어 시스템 은 유지 보수로 인해 성능 이 저하되거나 썩지 않습니다. 정의에 따라 코드를 변경하지 않고 몇 년 동안 설치된 시스템은 모든 요구 사항과 목표를 충족하며 성공합니다.

최대 엔트로피에 가까워지기 시작했기 때문에 지속적인 변화가 필요한 시스템은 끊임없이 찌르고 찌르는 시스템이며 부정적인 변화를 가속화하는 유지 관리 입니다.

충분합니다. 충분합니다.

상실 시간이 너무 짧아 비용을 보상 할 수 없기 때문에 지속적으로 변경되는 웹 사이트와 같은 짧은 수명주기 시스템은 단위 테스트에서 100 % 코드 적용 범위의 값 비싼 사전 설계의 이점을 얻지 못합니다.

위에서 언급 한 내부 업무용 앱과 같은 긴 수명주기 시스템은 100 % 코드 적용 단위 테스트에 대한 대규모 투자의 혜택을 실제로 얻지 못합니다. 프로젝트 수명 동안 변화율이 0에 가까운 상수에 근접하기 때문입니다. 비선형 패션.

그렇기 때문에 수명이 다한 계획이 더 중요하고 몇 년이 지나서 지원할 수없는 것이 아니라 새로운 제품이 제자리에 들어와야 할 때가 아니라 무언가가 출시되는 것처럼 교체 시스템을 계획해야합니다.

그들은 내가 아는 한 BBM에 대해 가르치지 않습니다. 나는 그것이 최근에 CS 졸업생을 만난 적이 없었습니다.

그렇기 때문에 Good Enough가 Good Enough 인 이유 는 무엇이든간에 그렇지 않습니다.

소프트웨어 슬럼로드

부동산 슬럼 영주가있는 이유는 그들이 소유 한 낡은 샨티 건물에서 이익을 얻는 것입니다. 런 다운 자산의 증분 유지 보수에 소비하는 것보다 더 많은 수익을 창출합니다. 그렇지 않은 경우 건물을 분해하고 교체합니다. 그러나 증분 비용이 전체 건물을 정비 또는 교체하는 것보다 훨씬 적기 때문에 그렇지 않습니다. 타락 재산에 대해 기꺼이 지불하려는 고객 (세입자)도 있습니다.

건물 소유주, 빈민가 영주 또는 유무는 관련 비용보다 실질적인 이익으로 해석되지 않는 학문적 완벽 함이라는 학문적 개념 때문에 부동산에 돈을 쓰지 않을 것입니다.

어느 고객도 자신의 소프트웨어 시스템에 대한 업그레이드 비용을 지불 할 의사가 없습니다. 실질적인 이익없이 코드를 작성하고 다시 작성하는 데 돈을 쓰지 않는 기업은 없습니다.

Microsoft는 가장 지배적이고 성공적인 소프트웨어 전문가입니다. Windows는 최근까지 주요 기초 재 작성을 시작하지 않았습니다. 그리고 그들은 여전히 ​​모든 기존 코드를 커널에서 삭제하지 않았습니다. 그들에게는 사업 상 이해가되지 않습니다. 사람들은 지난 10 년 동안 설정 한 기대치의 낮은 수준을 기꺼이 받아들입니다.

예지

이것은 제가 소프트웨어 개발에있어 온 20 년 이상의 패턴이었습니다. 곧 변하지 않을 것입니다. 이것은 사람들이 어떤 신념 체계에서 벗어나기를 원하는 방식이 아니며, 비즈니스에 대한 외부 세력의 현실입니다. 비즈니스는 의사 결정을 내리고, 급여를 지불하는 것이 악한 것이 아니며, 단기 또는 장기 비전은 무의미합니다. 이것은 정의에 의한 지속적인 변화의 단기 산업입니다. 이익을 창출 할만큼 선을 반대하는 사람은 사업을 이해하지 못합니다.

나는 15 년 동안 컨설팅을했고, 좋은 것이 그 자체만으로도 돈이 많이 들었다는 것을 매우 빨리 배웠다 . 예, 완벽하기를 원했지만 솔루션을 판매하는 시간의 99.99999 % 인 코드 기반을 판매하지 않는 한, 깨끗하고 체계적인 우아한 코드를 잃어 버리면 결코 상환받지 못할 시간을 낭비하게됩니다. .

진보와 희망

애자일 방법론은 적어도 철학적으로 올바른 방향으로의 좋은 단계입니다. 그들은 일류 시민으로서 혼란과 끊임없는 변화를 해결하고 받아들입니다. 그들은 방법론과 관행뿐만 아니라 요구 사항과 기술이 변경되어야한다는 것을 인정하면서 독단적 관행을 거부합니다.

그들은 시간 부족이나 변화하는 요구 사항, 직원 변경 및 기술 부채 개념을 가진 소프트웨어 시스템 의 생동감 으로 인해 야기 되는 엔트로피를 받아들 입니다.

그러나 애자일은 만병 통치약이 아니며 물리의 기본 법칙을 변경하지 않으며 코드베이스는 썩지 않습니다. 부패를 완전히 처리하고 관리 할 수 ​​없게되기 전에 부패를 다룰 계획을 세워야합니다.

민첩하게 처리하면 엔트로피 관리, 속도 저하, 추적, 측정 및 계획된 방식으로 처리 할 수 ​​있습니다. 그것은 멈추지 않을 것입니다!

경력 결정

이것이 당신에게 진정한 철학적 문제라면, 일이 작동하는 방식에 유효한 비즈니스 장점이 있기 때문에 다른 직업 선택을 고려해야 할 것입니다. 오픈 소스 프로젝트에는 더 나은 실적이 없으며, 대부분의 경우 코드는 내가 본 대부분의 회사 코드보다 훨씬 나쁩니다.

인턴으로서의 현재 경험이 실제 산업을 대표하는지 궁금합니다.

전혀 그렇지 않다. 경력 수준과 경험을 나타냅니다. 내부 품질 관리 관점에서 비즈니스가 작동하는 방식에 대해 배우는 것이 전부입니다.

배경으로 저는 전공 대학의 두 전공과 수학 전공의 더 나은 부분을 겪고 있습니다. 나는 모든 수업을 밟고 모든 것을 숭배 했으므로 프로그래밍에 끔찍하지 않다고 생각하고 싶습니다. 저는 주요 소프트웨어 회사 중 한 곳과 인턴십을했으며 지금은 절반 정도의 낮은 품질의 코드에 충격을 받았습니다.

당신의 기술, 경험, 교육은 다른 사람들이하는 일의 질에 영향을 미치지 않습니다. 이러한 관행을 변경할 권한이 없기 때문입니다. 대학에서 좋은지 나쁜지는 중요하지 않습니다. 그것은 당신이 일하는 회사가 현재 운영되는 방식을 바꾸지 않습니다. 따라서 훌륭하지만이 모든 배경을 가지고 있습니다. 그것은 실제로 자신의 이익을위한 것이지 그들의 이익을위한 것이 아닙니다. 그렇기 때문에 좋아하는 것을 연구하는 것이 중요합니다.

저는 주요 소프트웨어 회사 중 한 곳과 인턴십을했으며 지금은 절반 정도의 낮은 품질의 코드에 충격을 받았습니다. 주석은 존재하지 않으며 모든 스파게티 코드이며 잘못 될 수있는 모든 것이 훨씬 나쁩니다. 나는 많은 과외 / TAing을 해왔으므로 나쁜 코드를 읽는 데 매우 익숙하지만, 내가 본 주요 산업 제품은 그 모든 것을 능가합니다.

수년간의 프로그래밍에서 배운 것은 "코드 품질"과 "허용 가능한 코드"사이에 차이가 있다는 것입니다. 진실은 권한을 가진 사람이 소스 코드를 수용 가능한 상태로 찾거나 수용 할 수 없지만 필요한 것으로 판단한다는 것입니다. 우리가 참여한 프로젝트를 모두 정리할 수 있다면 좋을 것입니다. 종종 그러한 일을하기 위해 자원을 할당하는 것은 사업상의 관심이나 예산이 아닙니다. 다음 날 해가 올 때까지이 문제를 해결하는 것이 좋은 이유는 논리적 인 주장 일 수 있지만, 경영진이 현재 상태를 "허용 할 수있는"것으로 결정한 경우에는 거의 할 수없는 일입니다. 그것은 모두 누가 일을 하는가와 직접적으로 관련이 있습니다. 그들은 좋은 내부 품질을 소중히 여기거나 그렇지 않습니다. 당신은 그것을 분명히 소중히 여기며 따라서이 현재 상태는 당신을 귀찮게합니다.

내부 품질 관리에 의존하는 모든 산업에서 이러한 유형의 문제에 대한 예를 찾을 수 있습니다. 소프트웨어 개발에서 제조에 이르기까지 다양합니다. 이것을 문제가 아니라 단순히 소스 코드의 현재 상태로 보는 법을 배워야합니다. 이것은 방법입니다. 무언가를 찾는 데 X 분이 걸리고, 무언가를 고치려면 X 분이 걸립니다.

비즈니스는이 여분의 시간에 신경 쓰지 않거나 수용 가능하다고 생각합니다.

나는 문서화되지 않은 API를 알아 내거나 (완전히 문서화되지 않은) 제품의 다른 부분의 행동을 결정하는 데 많은 시간이 걸리기 때문에 하루에 10-12 시간 일하고 어디에서나 가고있는 것처럼 느껴지지 않습니다. 나는 지금까지 일을 미워하는 일을 떠났고, 이것이 내 인생의 나머지 부분에 무엇이 있는지 알고 싶었습니다.

대학에서 오랜 시간 동안 과목을 공부하는 것이 왜 허용 되었습니까? 그러나 이제 소스 코드를 공부하기 위해 오랜 시간을 투자하는 것은 허용되지 않습니까? 고용주가 당신을 고용 한 이유는 그들이 당신을 처리 할 수 ​​있다고 생각했기 때문입니다.

몇 가지 조언을 드리겠습니다. 훌륭한 개발자는 팀원에게 도움을 요청하는시기를 알고 있습니다. 답변이 항상 코드에 있다고 생각하지 마십시오. 사람들에게 몇 가지 질문을함으로써 시간을 절약했습니다. 속도를내는 데 도움이 필요한 것 같습니다.

둘째, 우리는 근무 조건을 모른다. 오랜 시간 일하는 것은 많은 산업에서 삶의 사실입니다. 스스로 해결해야하지만 말할 수는 있습니다. 당신의 직업을 미워하는 것은 결코 좋은 징조가 아닙니다. 그 느낌을 다루고 그 뿌리에 도달해야합니다. 불편을 끼쳐 드려 죄송합니다.

인턴쉽에 짧은 밀짚 모습을 했습니까 (이상하게도 월급이 낮 으면 품질이 낮지 않다는 것을 암시합니까) 아니면 실제 세계와 같은 것입니까?

당신은 학교에서 잘 지내고 있었지만 지금은 인턴쉽을 가지고 있고 잘 못하고 있습니다. 이미 현실 세계에있는 것 같습니다. 그것은 삶의 일부입니다. 문제는, 당신은 그것에 대해 무엇을 할 것입니까? 저의 친구는 유일하게 중요한 것입니다. 우리는 무엇을 해야할지 말할 수 없습니다. 당신은 당신의 자신의 마음을 구성해야합니다.

나는 당신의 나이에 당신의 경험이 내가 가진 어떤 기회보다 훨씬 나아 졌다고 말할 수 있습니다. 90 년대의 저의 인생은 집세를 내고 다음 계약을 찾기 위해 힘들었습니다. 운이 좋다고 생각하십시오.

25 년 후 다양한 회사와 업계에서 다음과 같이 말할 수 있습니다.
그렇습니다. 꽤 흔합니다.
그렇기 때문에 엔지니어들은 일반적으로 비용이 많이 들며 지저분한 호지-포지가 발생하는 데 능숙해야하며 여전히 엉뚱한 전체를 리팩터링하고 지옥이 무엇인지 알아 내려는 욕구에 저항하면서 변화를 계속해야합니다. 하기. 나는 당신을 위해 감정을 던졌습니다-당신이 만난 코드에 대해 그런 식으로 느끼는 것이 정상입니다!

당신이 보는 코드는 종종 다른 접근 방식과 표준 및 다른 명명 규칙 등을 가진 다른 프로그래머에 의해 끝없는 반복을 거쳤을 것입니다.

그러나 $ 압력은 항상 켜져 있습니다. 항상 더 나은 코드가 장기적으로 유일한 방법 인 이유와 이유를 설명하고 싶지만 많은 작업에서 시계가 단기 퀵 픽스 솔루션을 요구하고 있습니다. 프로젝트에서 표준을 파괴하는 데 단 1 명의 엔지니어 만 있으면됩니다. 이를 방지하고 올바른 접근 방식 (합리적으로 가능한 경우)을 실제로 해결하는 방법을 알고있는 훌륭한 관리자가 필요합니다.

한 가지 확실한 점은 '좋은 코드'라는 용어는 너무 주관적이어서 유용하지 않다는 것입니다. 물론 주관적이지 않으며 특정 이유 / 항목을 나열 할 수 있습니다. 그러나 다른 사람들은, 다른 항목과 우선 순위, 일부도 기술하지를 나열 그들이 생각 중요하며, 따라서 그것은 주관적인입니다.

Drekka와 마찬가지로 이것은 우울한 소리가 들리기 시작합니다. 그래서 좀 더 긍정적으로 바꾸어 보겠습니다.

• 조직의 가장 큰 기술적 구성 요소들은 사람이 있습니다 된다 옳은 일을하고는.
• 새로운 회사 ... 그리고 코드 ...는 청소기 경향이 있을 수 있습니다. 스파게티는 시간과 사람으로 인해 자랍니다.
• 어떤 사람들은 TDD와 BDD를, 다른 사람들은 그렇지 않습니다. 범위가 큽니다.
• 약 10 년 후, 현재 전체 기술 기반이 변경되어 업계에 머무르는 사람들은 초보자들과 마찬가지로 열심히 시간을 보낼 수 있습니다.

마지막으로 Anthony Blake가 지적했듯이 시간, 비용 및 품질이라는 세 가지 요소가 항상 있습니다.
나는 관련 표현을 좋아한다 : "pick 2" !

모든 사람의 경험이 다르기 때문에 이에 대한 의견이 많이 있습니다.

내가 경험하는 개발자의 약 절반은 의도가 있지만 평균적인 능력을 가지고 있습니다. 상단에는 작은 그룹의 훌륭한 사람들이 있고 하단에는 작은 그룹이 있지만 실제로는 그것을 얻지 못하기 때문에 기본적으로 다른 것을해야합니다. 불행히도 그들은 다른 사람들보다 영리하다고 생각하는 무능한 바보들의 또 다른 소그룹이 있습니다.

현명한 프로젝트로, 나는 많은 일을했고, 이미 확립 된 프로젝트, 즉, 마지막 개발자를 잃어버린 후에 비즈니스가 실제로 필요한 것을 발견 한 프로젝트를 즉시 조사해 달라는 요청을 받았습니다. 나는 보통 문서화되지 않고 과도하게 설계된 버그가 많은 스파게티라는 위에서 설명한 것을 정확하게 발견합니다. 때로는 고칠 수 있고 때로는 다시 시작하기도합니다. 구식 코드 일 필요는 없습니다. 나는 "도움을"요청받은 새로운 프로젝트에서 이것을 발견했습니다.

대부분의 회사가 인턴들에게 엉뚱한 직업을 줄 것이라는 사실을 염두에 두어야합니다. 재미있는 것은 당신이 두 가지 일을 한 후에옵니다. 1-자신을 입증하고 2-다른 사람들의 실수를 고치는 것 이외의 일을하기 위해 시간을 냈습니다. 다시 말해 능력과 주도권을 보여 주어야합니다.

잘못된 코드를 처리하는 실제 방법은 무엇이 구원 가능하고 무엇이 아닌지를 알아내는 것입니다. 이것은 경험과 연구에서 비롯됩니다.

당신이 가진 다른 직업 옵션은 기존 회사에서 일하는 것을 멈추고 신생 기업에서 일하는 것을 찾는 것입니다. 그런 다음 유지해야 할 레거시 코드가 없으므로 더 나은 무언가를 만들 수 있습니다. 단점은 시작 프로젝트에 배치해야한다는 압박은 종종 지름길과 핵을 사용해서는 안된다는 의미입니다.

프로그래머들은 너무 일찍 또는 적시에 제공하기 위해 기술 부채를 기꺼이 맡고 있습니다. 불행히도이 기술 부채의 영향은 개발자와 경영진이 너무 늦어서 문제가 생길 때까지 종종 극복, 최소화, 무시 또는 해고됩니다.

우울하게 들리면 죄송합니다. 다른 사람이 더 긍정적 인 일을 할 수 있다고 확신합니다. :-)

여기에 훌륭한 답변이 있지만 내 비트를 추가하겠습니다.

현실 세계에 오신 것을 환영합니다-불행히도 이것은 매우 일반적입니다.

아래 다이어그램을 참조하십시오.

회사 소프트웨어를 사용하면 2 이상 만 선택할 수 있으며 하나만 희생해야합니다.

당신이 발견 한 것처럼, 회사 세계의 대다수는 속도와 가격으로 움직입니다.

업계를 완전히 나타내는 것은 아니지만 5 년 이상 제한된 경험을 바탕으로합니다. 인턴십을 통해 일하면서 가능한 많은 경험을 통해 교훈을 얻었습니다. 특징 및 지표를 찾으십시오. 예를 들어 다음 직책의 경우 의심 할 여지없이 일련의 인터뷰를 거쳐야합니다. 이 과정은 양방향 도로이며 회사에 대한 느낌을 가질 수있는 기회를 제공합니다. 이것은 매우 중요하며 자신의 행복과 행복으로 이어질 것입니다.

요약하면, 이야기의 표시를 발견하십시오.

• 누가 회사를 운영하고 있습니까? 단일 관리자, 마케팅 팀 (있는 경우), 개발 팀 등입니까?이 각도는 프로젝트, 프로젝트에 소요 된 시간 등을 어느 정도 활용할 수 있음을 의미합니다.
• 기술적 인 감사가 있습니까? 관리, 감독자 및 팀 구성원이 서로를 어떻게 대하는지 살펴보십시오. 기술 책임자가 연설을 시작하면 관리자가 모든 종류의 눈썹 운동을하고있는 인터뷰에있었습니다. 그 후 그들은 소스 제어를 사용하지 않았다는 것을 알게되었습니다. 문을 충분히 빨리 보여줄 수 없었습니다.
• 사업 목표? 회사는 일일 재무 목표 에서처럼 매일 매일 살거나 귀하가 속한 장기 계획이 있습니까? 소프트웨어 개발은 ​​일반적으로 몇 개월에 걸쳐 이루어 지므로 정신 분열증을 가진 회사를 갖는 것은 대개 지저분한 소프트웨어로 이어집니다.
• 기술적 인 질문을 할 때 사람들이 뒤섞이는지 확인하십시오. 소스 제어, 문서 제어, 릴리스 프로세스, 버그 보고서, 관리 스타일, T & C 등

그러므로 살고 배우고 다음 역할에 대해 생각하십시오. 일과 비즈니스의 세계에 대해 더 잘 교육받을 수 있기 때문에 나쁜 경험을하는 것이 그렇게 나쁘지는 않습니다.

글쎄, 나는 사업에서 20 년 동안 일을 해왔고, 완벽한 깨끗한 코드는 거의 일어나지 않으며, 그렇게되었을 때 그렇게 오래 머 무르지 않는다고 말할 수 있습니다. 대체로 과거의 실수를 고치려고 노력하는 동안, (슬프게도) 현재의 실수를 저지르는 시간 제약과 열악한 지도력에 의해 강요된 것입니다.

매우 특정한 종류의 소프트웨어 비즈니스에 속하지 않는 한, 기능성 제품을 출시해야하는 압력은 다른 모든 문제보다 우선하며 특정 지점 이상의 최적화는 의미가없는 것으로 간주됩니다. 프로그램이 5 분 안에 실행되고 5 분만에 프로그램을 실행해야하는 경우, 아무도 2 주로 런타임을 낮추기 위해 몇 주를주지 않을 것입니다.

어떤 기적에 의해, 당신은 유능한 관리, 명확한 목표, 돈, 재능, 시간의 완벽한 합류를 가지고, 당신은 깨끗하고 superiour 제품을 생산하는 경우가 있다면 ... 그것은 그런 식으로 남아있을 것입니다 수있는 유일한 방법은 만지지 마십시오 다시 . 유지 관리 및 확장은 거의 항상 우선 순위가 매우 낮으며, 사실상 제로 통지에 변경이 필요하며, 결과적으로 불규칙하게 끝납니다.

어제이 프로젝트에 대해 생각하고있었습니다. 그것은 나에게 아주 명백한 파이프 꿈이었습니다. 나는 문에서 실제로 최소한의 기능을 부수 었습니다. 나는 그것을 시간과 자원의 낭비로 보았다.

놀랍고 놀랍습니다. 모두가 그것을 좋아했고 잘 작동했습니다. 그래서 나는 드로잉 보드로 돌아가서 제대로했습니다. 그리고 새 버전은 훌륭했습니다! 그러나 경영의 회전이 있었고 모든 것이 "새로운 사업 방향"을 위해 폐기되었습니다.

두 번째 반복은 회사 내에서 거의 절반에 가까운 배포를 가졌으며 그것에 대해 또 다른 소식을 듣지 못했습니다. 최소한 ~ 10 개의 사업 단위가 여전히 그것을 사용하고 있다는 것을 알고 있기 때문에 재미 있습니다 (우리가 업무를 수행하도록 위임하는 소프트웨어) 거의 2 년이 늦었습니다.)

이것이 나의 마지막 요점을 알려줍니다. 기적적인 것을 생산하더라도 그것이 잘 작동한다는 사실은 아무도 그것에 익숙하지 않을 것임을 의미하며, 그것이 깨질 때 (보통 어리석은 일을했기 때문에) 그들은 당신의 이름을 저주보다 더 저주 할 것입니다 세 번째 화요일마다 깨지는 것을 쓴 그 바보를 저주하십시오.

당신이 끔찍하게 저품질 코드를 어떻게 생각하는지 말하기는 어렵지만, 그래도 아주 좋은 프로그래머는 거의 없습니다 (정의상). 소프트웨어가 발전함에 따라 사람들은 실수를합니다. 시간이 지남에 따라 이러한 것들이 쌓이고 비즈니스 압력 (및 프로그래머 게으름 / 무지)이 리팩토링을 만듭니다.

모든 사람과 대화 할 수는 없지만 여기에 내가 말할 수있는 것이 있습니다.

나는 도메인에서 30 년 이상 일하지 않았지만 몇 가지를 말할만큼 충분히 보았다. 프로젝트는 인간과 거의 같은 수명을 가지고 있습니다. 초기 설계는 20 년의 개발 후 하나의 프로젝트에 대한 현재 요구에 맞지 않을 수 있습니다. 그것은 많은 시간 동안 많은 사람들이 코드를 엉망으로 만들었고 처음에는 불가능했던 것을 추가했습니다.

레거시 프로젝트 또는 상당히 오래된 프로젝트에서 못생긴 코드를 상상하는 것은 어렵지 않습니다. 우리는 모든 사람이 초기 설계를 완전히 이해할 것을 기대할 수는 없습니다. 슬프지만 그것이 그 방식입니다.

즉, 레거시 프로젝트를 리팩토링하는 것이 항상 가능하지는 않으며 때로는 원하지도 않는다는 것을 명심해야합니다. 나는 그들이 작업하고 있던 프로젝트의 대체물을 개발하고있는 회사에서 일했다. 새 프로젝트보다 더 잘 작동 할까봐 프로젝트를 너무 많이 리팩토링 할 수 없었습니다. 나는이 프로젝트가 새로운 새로운 프로젝트보다 더 잘 작동 할 수있는 방법이 없다고 확신한다. 그 구절은 "더 나아지지 말고 그냥 작동 시키십시오"와 비슷했습니다.

결국 나는 종종 읽고 듣는 것처럼 그런 종류의 프로젝트를 자주하지 않을 것입니다. 대기업 대신 신생 기업과의 작업을 찾아보십시오. 스타트 업은 매우 흥미롭고, 원하는 방식으로 진행되지 않는 것을 알게되면 결국 빠르게 진행할 수 있습니다.

또한 당신이 할 수있는 한 가지는 정말로 약속하지 않지만 코드가 실제로 그렇게 나쁘고 리팩토링이 필요하다고 느낀다면. 팀과 공유하십시오. 그 추악한 코드를 작성한 사람들이 당신과 함께 일하고 있다는 것을 명심하십시오. 그것은 사람들의 감정을 상하게하는 것이 아니라 당신이 작업하고있는 프로젝트가 언젠가 붕괴 될 것이라는 것을 알면 사람들은 그것을 개선하는 대신 그 일을 이해하는데 더 많은 시간을 할애 할 것입니다. 스스로 문제를 해결하는 것보다 문제를 말하고 의사 소통하는 것이 좋습니다. 운이 좋으면 프로젝트 리팩토링이 끝날 수 있습니다.

프로젝트 리팩토링을 끝내면 나쁜 디자인 선택을 지적하는 사람이 될 수 있습니다! 리팩토링이 왜 그렇게 자주 발생하지 않는지 이해할 수 있습니다. 전체 팀이 리팩터링해야한다면 아무도 지적하지 않기를 바랍니다. 그들은 단지 모든 사람을 해고합니다 =)

이 질문에 대한 답을 간단한 인용문으로 요약하려고합니다.

All code turns to crap given enough time and hands.

나머지는 단지 이야기입니다 ...

코드 품질은 주로 두 가지 요소에 달려 있습니다.

첫째는 항상 돈이다. 자궁 경부 압박이 높은 회사는 대개 임금이 낮고 경험이 적은 개발자를 고용하며 일정이 빡빡하며 개발자를 활용할 시간도없고 돈도 없습니다.

둘째는 사람들입니다. 우선 예산을 결정하는 사람들은 코드 품질에 대한 지출을 선택해야하며, 그에 따라 "살기"원하는 사람들을 참여시켜야합니다. 당신이 상상할 수 있듯이, 잘 생긴 50 세의 하향식 델파이 프로그래머를 고정 관념을 의도하지 않고 죄송합니다) CI 빌드 및 제작을하는 최신 Java 개발자로 전환하는 것이 어려울 수 있습니다 느슨하게 결합 된 코드. 많은 개발자들은 (아마도) 동료들에 의한 교훈에 대한 혐오감을 가지고 있습니다.

따라서 모든 회사 옆에 레거시 코드가 있다는 사실을 고려할 때 실제로 많은 것을 얻을 수 있다고 말하고 싶습니다. 당신이 할 수있는 일은 보이 스카우트처럼 행동하는 것입니다. 숲으로 가서 쓰레기를 줍고 청소하십시오. 다음에는 더 이상 혼란스러워 할 것입니다.

예산이있는 코드에 오신 것을 환영합니다! 계획을 세우지 않고 구석에 너무 빨리 경영진이 개발을 추진할 때 큰 차이가 있습니다. 대학에서 첫 프로그래밍 직업을 얻었을 때 비슷한 충격을 경험했습니다. 문서가 없습니다! 시간이 지남에 따라 많은 시간을 배웠고, 공식 문서를 작성하고 최신 상태로 유지하는 것은 시간 낭비입니다. 운 좋게도, 그것은 멋진 팀이었습니다. 그것은 자신이하고있는 일을 알고있는 한 사람과 다른 팀원이 코드를 올바르게 작성하는 것을 정말로 염려했습니다. 그 이후로 내 경험은 당신과 비슷했습니다. 많은 끔찍한 코드, 많은 나쁜 코드, 많은 단서가없는 "개발자". 모든 훌륭한 개발자에게는 100 명의 나쁜 개발자가있는 것 같습니다.

당신은 당신의 직업을 영원히 미워할 운명이 아닙니다. 당신은 조금 선불 투자 할 의향이있는 장기적인 혜택을 인식 할만큼 똑똑한 회사를 찾아야합니다. 나는 가장 빠른 방법 대신 올바른 방법으로 일을하는 것이 유익하다는 것을 증명했으며, 내가 일했던 회사에서 그 일에 대해 매우 존경 받고 신뢰를 얻었습니다. 시간이 지남에 따라 스파게티 코드는 고정되거나 더 이상 사용되지 않으며 코드가 대신합니다. 타협 할 준비를하십시오. 때로는 가장 멋지거나 가장 강력한 프로그래밍 방식이 너무 과장되어 빠르고 더러운 방식으로해도 괜찮습니다.

주요 소프트웨어 회사 중 하나와 인턴쉽을 받았습니다.

모든 회사가 같은 것은 아닙니다. 크 래피 팀과 크 래피 소프트웨어 코드 기반은 대부분의 회사에서 찾을 수 있습니다. 그러나 훌륭한 팀과 훌륭한 코드 기반을 찾을 수도 있습니다.

솔라리스 직원 들은 대기업에서 찾을 수있는 일종의 코드 기반에 대해 매우 정직하게 설명했다고 생각합니다. http://hub.opensolaris.org/bin/view/Community+Group+on/dev_solaris

나는 지금까지 일을 미워하는 일을 떠났고, 이것이 내 인생의 나머지 부분에 무엇이 있는지 알고 싶었습니다.

아니요, 저는 15 년 이상 코딩을 해왔으며 여전히 그것을 좋아합니다.

그것은 모든 것이 완벽하다는 것을 말하는 것이 아닙니다. 나는 끔찍한 코드베이스와 훌륭한 코드베이스를 보았습니다. 요령은 당신에게 맞는 장소를 찾는 것입니다.

큰 회사는 작은 회사와 다릅니다. 같은 회사 팀 A 내에서 때로는 다른 형태의 팀 B입니다. 예를 들어, 프로젝트, 도전적인 문화, 좋은 임금, 기타 등 자신에게 적합한 균형을 가진 팀을 찾으십시오.

행운을 빕니다!

나는 당신과 비슷한 것을 보았습니다. 두 가지 경우에 대한 경험이 있습니다.

1. 개발이 너무 프로젝트 중심 일 때. 중요한 것은 기능을 제 시간에 맞춰 제공 한 다음 사인 오프하는 것입니다. 다음 예산은 다른 사람, 다른 팀 / 프로젝트 관리자가 새로운 예산으로 변경합니다.
2. 오랜 시간 동안 소수의 사람들 만 소프트웨어를 유지 관리하는 경우 개발자는 소프트웨어를 알고 있기 때문에 게으른 경향이 있습니다. 학문적 원칙은 멀리 있습니다.

슬프지만, 그것이 어떤 장소에있는 방법입니다.

더 나은 것을 위해 약간의 변경을 할 수 있는지, 익숙해 지거나 다른 회사로 변경하고 인터뷰에서 코드를 스크린하도록 요청하십시오 :-)

이것은 짧은 대답이 될 것입니다.

교육은 자격을 갖추고 이상적으로 느끼게하는 데 매우 유용합니다. 이것은 좋은 일이며, 이상주의를 고수해야합니다.

당신이 모든 목표에 있고 미래에 자신의 작업을 되돌아 볼 수 있다면, 그것은 매우 만족스러운 경험이 될 수 없습니다. 자신에게 거짓말을하거나 아무것도 배우지 않는 한 자신이 한 일을 개선 할 수있는 여러 가지 방법을 보게 될 것입니다.

일반적으로 전 세계가이 일을하고 있습니다. 따라서 과거의 일을 제외하고는 예외를 제외하고는 열등하고 개선이 필요한 것처럼 보일 것입니다. 당신이 이런 느낌이 들지 않는다면, 그것은 당신이 잘못한 일을하고 있거나 돈을 너무 많이 지불한다는 것을 의미합니다.

좋은 소식은 다른 사람의 실수와 과거와의 비교로부터 이익을 얻을 수 있다는 것입니다. 모든 응용 프로그램이 제대로 작동하고 유지 관리가 쉬운 경우 새로운 개발자가 필요하지 않습니다. 제 생각에는 다른 개발자 부스러기를 유지하는 것은 유용한 학습 경험이며 모든 푸른 하늘 개발자에게 필수적인 교육 요소가되어야합니다.

당신의 부정적인 경험은 유명한 유명 브랜드 회사들로 가득 차 있습니다. 많은 개발자들이 처음으로 일할 기회를 얻었을 때보 다 많은주의와 멍청이로 접근하는 법을 배웁니다. 기본적으로 관리 계층이 많을수록 평범 성이 더 많이 사용됩니다. 중간 관리자는 코드 품질에 대해 상위 관리자에게보고하지 않습니다. 그들은 X 시간 동안 제공되는 기능에 대해보고하고 그들이 그것을 달성하기에 충분히 오래 작동하기를 원하는 깔끔한 UI 기능에 대한 파워 포인트 프레젠테이션을 제공합니다. 한 달 후에 모든 것이 무너지면 그것은 보통 다른 누군가의 문제이며 그것을 알고 있습니다.

그렇습니다. 그런 곳에서 살아남는 개발자들은 그다지 신경 쓰지 않는 경향이 있습니다. 그들은 그들이 거기에서 살아남을 수 없었습니다. 게으름을 피우고 싶다면 큰 이름 중 하나를 위해 일한다고 실리콘 밸리에 대해 들었습니다. 흥미 진진한 작업을 원한다면 아직 세대 이름이 아닌 최신 스타트 업을 찾으십시오. 저는 시카고에서 일하며 비슷한 현상을 보증 할 수 있습니다.

일반적으로 많은 예외를 제외하고는 코드를 계속 작성하는 사람들이 더 작고 관리하거나 소유 한 회사에서 품질 코드에 대한 인식이 높아질 것입니다. 보상은 종종 적지 만, 제 생각에는 작업이 훨씬 더 보상 적입니다.

엔트리 레벨 개발자는 처음에 일하는 사람을 많이 제어하지는 못하지만 이력서에 1 년 이상 큰 이름을 지니면 채용 담당자와 HR 직원을 확실히 흥분시킬 수 있습니다. 또한 처음 6 개월 정도 동안 완전히 끔찍한 사람을 위해 일하는 법을 배우지 않으면 상당히 배울 수 있으며 실제로 어떤 모범 사례가 실제로 중요한지, 왜 어떤 기술이 기술적인지에 대해 더 잘 파악할 수 있습니다. 페이드.

물론 더 많은 주류 대중 기업 도구로 작업 할 때 중간 수준의 인재 수준이 상당히 어려워지는 경향이 있습니다. 기본 기술이 Java와 C #의 조합이라면 시야를 조금 넓 힙니다. Erlang 또는 Python 또는 : o JavaScript를 작성하는 중간 수준에서 더 행복한 틈새를 찾을 수 있습니다.

그리고 다른 사람에게 말하지 마십시오. 진행 방법에 대해서는 선택의 여지가 없지만 쓰레기 코드는! @ # $ ing 비쌉니다.

귀하의 질문은 인턴쉽에 중점을 두었습니다. 나는 프로그래밍을 한 적이 없지만 라디오 방송국에서 인턴을 했으므로 실제로 적용 할 수는 없습니다.

귀하의 질문은 또한 인턴십 중 귀하의 경험을 언급했습니다. 인턴십 경험과 지금까지받은 답변은 이제 27 년 동안 소프트웨어를 작성한 후 (1985 년 6 월 중순에 시작한) 내 경험을 요약합니다.

우리 강사들이 실제로 코드를 작성하는 것보다 더 많은 생각이 있다고 말했을 때 나는 학교에서 그것을 믿지 않았습니다. 그들은 옳았다. 그리고 다른 사람의 코드를 알아 내려고하면 주석이 없으면 악화되고 주석이 거의 나빠집니다. 의견, 문서, 공식적인 빌드 및 소스 코드 제어없이 집에서 자라는 도시 세금 징수 시스템을 유지하십시오.

표준 주문을 직접 위반하지 않고 잘 할 수 있으면 잘하십시오. 권한을 부여받지 않고 직접 명령을 거스르는 것보다 권한을 요청하지 않은 일을 한 것에 대해 사과하는 것이 더 쉽다는 것을 항상 기억하십시오.

학교에서 배운 표준을 잊지 마십시오. 그것들은 쓸모가 없지만, 그 표준보다 미적분학의 한계점 일 가능성이 높습니다. 당신은 항상 그들에게 접근하려고 시도 할 수 있지만, 그들의 가치에 결코 도달하지 못할 수도 있습니다.

행운을 빕니다.