숙련 된 개발자가 없을 때 실제 프로젝트를 진행하면서 기술을 어떻게 향상시킬 수 있습니까? [닫은]

저는 C # 및 ASP.Net과 함께 일하는 소규모 회사의 수석 개발자입니다. 우리 팀은 개발과 디자인에 많은 경험이없는 작은 2-3 명입니다. 더 많은 선임 개발자로부터 배울 기회가 없습니다. 팀에는 아무도 프로젝트를 직접 관리 할 때 나를 안내하고 최선의 방법을 선택할 수 있도록 도와 줄 사람이 없습니다.

숙련 된 개발자가없는 실제 프로젝트에서 작업하면서 소프트웨어 개발 기술을 향상시킬 수있는 방법은 무엇입니까?

책, 숙련 된 개발자의 블로그, 스택 교환, 강의 / 컨퍼런스 등 경험이 풍부한 동료들로부터 배울 수있는 많은 자료가 있습니다. 코드 검토 또한 중요하며 CodeReview.SE 는 귀중한 자료입니다.

예제에서 어떻게 작동하는지 봅시다.

예

"ETL"이라는 용어가 언급 된 블로그 게시물 을 읽고 있습니다. 그 의미를 모르지만이 기사에서는 데이터가 일부 데이터 지원에서 다른 데이터 지원으로 이동하는 일종의 프로세스 또는 워크 플로우라는 것을 모호하게 이해합니다.

Wikipedia 및 기타 리소스 로 이동하여 더 정확한 비전을 얻습니다. ETL을 사용하는 것이 언제 유용할지는 아직 명확하지 않습니다. 결국 실제 ETL을 작성하는 데 너무 많은 시간을 소비하지 않고 모든 작업을 수행하는 SQL 쿼리를 작성하는 것이 훨씬 쉬워 보입니다.

이러한 질문에 답하기 위해 지역 도서관에서 ETL에 관한 책 을 빌립니다 . 간단한 SQL 쿼리로는 일부 추출-변형-로드 프로세스를 쉽게 수행 할 수 없다고 설명합니다. 데이터 유효성 검사 / 정상화 및 매핑

이제 ETL이 무엇인지, 어떻게 사용하는지, 특히 ETL이 필요한 경우와 적절한 도구가 아닌 경우에 대한 명확한 비전을 갖게되었습니다. 한편, 개인 프로젝트로 작은 ETL을 구현했습니다. 이 프로젝트를 사용하면 명확하지 않고 책으로 다루지 않은 몇 가지 사항을 발견 할 수 있습니다. 그 점은 다소 추상적이며 소스 코드와 관련이 없으므로 Programmers.SE에 질문을 게시하십시오 .

회사에서 구축 할 수있는 기회가 생길 때 시작하십시오. 몇 가지 문제가 있습니다. 일부는 코드와 관련이 있습니다. Stack Overflow에 질문을 게시 합니다. 다른 것은 데이터베이스와 관련이 있습니다. DBA.SE에 대한 질문을 합니다 .

마지막으로, 숙련 된 개발자가 ETL을 최적화하는 방법에 관한 회의 가 있습니다. 이 컨퍼런스에 참석하면 프로젝트의 개선 사항에 대한 유용한 힌트를 얻을 수 있습니다.

또한 몇 년 동안 서로 다른 ETL을 작업 한 개발자 의 블로그 를 팔로우하기 시작합니다. 다른 접근법을 보는 것은 흥미 롭습니다.이 블로그를 통해 ECCD에 대해 배웁니다. 당신이있는 거 관심, 당신은 랄프 킴볼에 의해 데이터웨어 하우스 ETL 도구 키트를 빌릴 수 있도록 책 정보] 상세 회담 "추출물, 깨끗한, 준수 및 제공"프로세스를. 같은 블로그에는 프로그래밍 기술없이 ETL을 만들려는 많은 응용 프로그램도 언급되어 있습니다. 이는 비전문가 인 상사가 자신이 한 일에 대해 약간의 변경을 요청하기 때문에 회사에서 수행 한 ETL에 특히 유용합니다.

물건을 발견

멘토 나 경험이 풍부한 동료가 없을 때 어려운 부분 인 IMHO는 사물 을 발견 하는 것이며, "이것에 대해 들어 본 적이 없다"는 상태에서 "나는 그것에 대해 들었지만 그것이 무엇인지 잘 모릅니다. "

누군가 내 코드를 검토하고 약간의 호기심으로 스타일 규칙을 사용해야한다고 말하면 프로그래밍에 코드 작성 스타일이 다르며 주어진 언어 및 코드베이스에 대한 스타일을 고수해야한다는 것을 알 수 있습니다. 많은 언어에는 스타일을 적용하는 도구 (예 : StyleCop for C #)가 있습니다.

아무도 나에게 스타일에 대해 말하지 않는다면, 그런 것이 존재한다는 것을 어떻게 알 수 있습니까?

블로그 나 스택 교환과 같은 리소스가 유용한 곳입니다. 위키 백과는 도움이되지 않으며 (프로그래밍에 관한 임의의 페이지를 치는 데 며칠을 보내지 않는 한), 책은 그러한 것들에 대해 거의 이야기하지 않습니다.

패턴과 관행 또는 코드와 관련이없는 것들에도 동일하게 적용됩니다. 예를 들어, 아침에 깨어 난 일부 개발자는 ITIL에 대해 배우지 말고 ITIL에 대해 신경 쓰지 않아도된다고 스스로 상상하지는 않습니다.

새로운 용어 를 발견 한 후에 는 배우기가 매우 쉽습니다. 새로운 "코드 계약"이라는 용어를 제공하고 C # 개발자 인 경우 MSDN (또는 Jon Skeet의 책)에서 충분한 정보를 쉽게 찾을 수 있습니다.

호기심이 도움

인턴과 함께 일할 때 항상 가장 좋은 것은 강의 밖에서 호기심이 많은 사람들입니다. 교사가 언급하지 않은 경우에도 기능 프로그래밍이라는 것이 있다는 것을 알고있을 수 있으며, 기능 언어를 알지 못하는 경우에도 여전히 FP 란 무엇이고 다른 용어와 다른 점을 일반적인 용어로 설명 할 수 있습니다 패러다임. 블로그를 읽고 스택 교환을 사용하기 때문에 단순히 강의에 참석하기 때문에 애자일, 유니 코드 또는 부분 신뢰 / 샌드 박스 모델에 대해 알 수 있습니다.

멘토가 없더라도 대학에서 알려지지 않은 모든 것을 여전히 배웁니다.

비슷한 상황에 처해 있습니다. 우리는 소규모 팀이고 핵심 개발 제품 작업은 몇 년 전의 코드 기반에서 주로 점진적으로 변경됩니다.

최신 상태를 유지하고 기술을 향상시키기 위해 사용하고있는 몇 가지 기술.

직장에서:

• 읽기 : 책, 블로그, 홍보 자료. 많은 RSS 피드를 따릅니다. 오늘의 오라일리 거래가 내가 들어 보지 못한 기술에 관한 것이었을 때, 나는 그 책의 설명을 읽었습니다. 이 기술이 내가하고있는 작업과 많은 관련이 있다면, MainMa의 답변과 비슷하게 5 분에서 10 분 정도 조금 더 깊이 연구하고 있습니다. 몇 가지 다른 RSS 피드로 이것을 반복합니다.
• 회사 리소스 (시간 및 / 또는 돈)로 지원 될 수있는 경영진과 함께 교육 계획을 세우십시오.
• 대부분의 프로그래머 경향과는 달리 변화와 새로운 디자인 옵션을 수용하십시오. 변경을위한 변경은 좋지 않지만 개발자가 변경으로 인해 새로운 디자인이나 프레임 워크를 사용하지 않는 경우가 너무 많다고 생각합니다. 이것은 걷기에 좋은 노선이며, 구속력있는 결정을 서두르지 말고 새로운 일을하는 방법을 주시하십시오. DVCS로 전환하면 코드 기반을보다 쉽게 ​​실험하고 새로운 기술을 시험해 볼 수 있습니다.
• 어떤 사람들은 회의를 좋아합니다. 투자 한 시간에 대한 보수가 적다는 것을 알았습니다.

업무 외 :

나는 일상적인 업무 이외의 기술을 사용하는 것이 중요하다는 것을 알았습니다. 실험, 실수, 관심사 추구의 자유로 인해 IT에 계속 참여하게되었습니다. 실무 프로젝트 만 있었으며 학습 내용을 즉시 유용한 것으로 제한해야한다면 금방 소진 될 것입니다.

• 비 작업 프로젝트에 참여하십시오. 나를 위해, 이것은 개인적인 관심사와 관련된 기능적인 웹 사이트를 개발하고 있습니다. 나는 자유롭게 리팩토링하고 적극적으로 다른 기술을 실험하려고합니다. 오픈 소스에 기여하면 다른 사람들의 코드에도 노출 될 수 있습니다. 또한 경험이 풍부한 개발자가있는 회사와의 인터뷰를 위해 공유 할 수있는 좋은 자료를 제공합니다.
• 코드 캠프하십시오있을 경우 코드 캠프 귀하의 지역 참석은. 이들은 근무 시간 중이 아니며 무료이기 때문에 개인적으로 관심있는 주제에 대해 세션에 자유롭게 참석할 수 있습니다. 일반적인 컨퍼런스와 비교할 때, 이들은 일반적으로 로컬이며 광범위한 기술을 다루므로 더 집중된 가치가 있다고 생각합니다.

그리고 SO 또는 Programmers.SE를 자주 방문하는 것을 잊지 마십시오.

여기에있는 답변은 큰 도움이 될 것입니다. 그러나 나는 스트레스를주고 싶습니다. 하루에 8 시간, 일주일에 5 일 동안 당신보다 더 나은 사람 (임의의, 개인적, 더 나은 정의를 위해)을 대신 할 수있는 것은 아무것도 없습니다. 그 정도는 확실합니다.

항상 더 나아지기를 원하고 배우기를 원하는 개발자 유형이라면 결국 다른 회사로 가야합니다. 많은 것이 불가피하며 계획되어야합니다.

자신에게 맞는 회사를 찾으면 회사 내에서 성장하는 것보다 회사 내에서 계속 성장할 수 있습니다.

소프트웨어 개발은 ​​팀 스포츠입니다. 스포츠처럼, 매우 높은 수준에서 플레이하려면 같은 사람들과 경쟁하고 경쟁해야합니다. 이동할 기회를 찾으십시오.

연습은 영구적이되므로 더 나은 기술과 지식을 향해 끊임없이 노력하지 않으면 비평이나 역할 모델없이 격리 된 상태에서 작업 할 경우 기술이 성장하지 않을 수 있습니다.

전 세계적으로 경쟁이 치열 해 지므로 틈새 시장은 일시적 일 것으로 예상하고 업무 만족도에 대한 기준을 충족하는 기회를 준비하는 동시에 안락 지대 밖에서 우수한 팀과 함께 일할 수 있습니다.

어떤 제안을하기 전에, 나는 1 년 전에 아주 비슷한 입장에 있었다고 말해야합니다.

프로젝트를 완료했지만 개선 할 공간이 많다고 생각하면 좋은 것입니다.

한 번은 프로젝트를 완료 할 기술적 능력과 자신감이 없었습니다. 종종 책을 구입하고 상당히 기술적 인 블로그를 읽고 "나의 깊이에서"자신을 발견 할 것입니다. 가장 큰 문제는 대기업 응용 프로그램에 노출되지 않았다는 것입니다. 나는 종종 무언가를 잘 할 것이지만, 내가 한 일을 확인하는 사람은 아무도 없습니다.

이것은 도전적이고 도전적인 일이므로 어디에서 왔는지 알 수 있습니다. 이 문제를 어떻게 해결 했습니까? 회사를 떠나 잘 설립 된 소프트웨어 개발 회사에 합류하여 지난 한 해 동안 많은 경험을 쌓았습니다.

회사를 떠나고 싶지 않다면, 우리 업계의 개척자들이 쓴 책을 권합니다. Andrew Hunt의 Pragmatic Programmer부터 시작하겠습니다. 이 책에는 기억하기 쉬운 유용한 유물이 많이 있습니다. 이 책의 처음 몇 장에서 우리가 직장에서 사용하는 언어와는 매우 다른 프로그래밍 언어를 선택하도록 장려했습니다. 나는 기술이 아닌 문학을 읽기 시작했습니다. 이제 소설과 공상 과학 소설을 읽는 것이 저에게 더 나은 프로그래머가 될 것이라고 믿습니다. 에세이 작성은 깨끗한 코드 작성과 멀지 않습니다. 일부 작가는 좋고 일부는 나쁘다. 이 책은 내가 쓰는 것에 관심을 갖게했다. 비유 중 하나를 "깨진 Windows"라고합니다. 당신은 며칠 동안 거리에 버려진 차를두고 아무 일도 일어나지 않습니다. 하나의 창을 깨면 차는 아마 다음 날에 파괴 될 것입니다. 코드도 다르지 않습니다. 깨지거나 잘못 작성된 코드가 보이면 바로 고치십시오. 조만간 "귀신"으로 돌아올 수 있으므로 코드를 그대로 두지 마십시오. 이 책을 통해 작업을 시작하면 코드에 대해 다른 방식으로 생각할 수있는 유사한 유사점을 수십 가지 선택하게됩니다.

그런 다음 Robert C. Martin의 Clean Code로 넘어가십시오. 이 책은 좋지 않은 (깨끗한) 코드를 읽도록 강요하기 때문에보다 실용적입니다. Author는 오픈 소스 프로젝트 중 하나의 코드 샘플을 사용합니다. 당신은 당신을 안내 할 사람이 없다고 말합니다. 다른 사람의 코드를보고 자신의 코드와 비교하고 개선 할 수있는 방법을 볼 수있는 완벽한 기회가 있습니다. 이 책을 읽는 것은 누군가가 프로젝트에서 일하는 것을 가리는 것과 같습니다. 이 책은 또한 가장 어려운 것, 즉 우려의 분리를 강조합니다. 저자는 우리 업계의 선구자에게 "깨끗한"코드라고 생각하는 것을 물었습니다. 답변을 읽으면 깨끗한 코드가 무엇인지에 대한 자신의 의견과 비교할 수 있습니다.

마지막으로 오픈 소스 프로젝트 작업을 고려 했습니까? 코드를 검토하고 올바른 방향으로 안내 할 수있는보다 숙련 된 다른 개발자와 공동 작업하게됩니다.

원래 답변에서 말했듯이 밤새 일어나지 않습니다. 나는 몇 년 동안 이것을 해왔고 거의 매일 나는 내가 잘못하고 있음을 알게됩니다.

행운을 빕니다!

문제 해결 연습. 다른 코드를 읽고 이해하기 위해 노력하고 (github 은이를위한 훌륭한 리소스입니다) 개선 사항을 제출하십시오. 컨설팅 작업을 수행하면 기술을 넓히는 데 도움이 될 수 있습니다.