항상 책을 사용하는 것에 대한 선임 프로그래머 조언이 좋은 생각입니까? [닫은]

저는 주니어 개발자이며 5 년 동안 만 업계에있었습니다. 나의 현재 회사에는 선배가 그를 Infestus라고 부릅니다. 때때로 나는 처음부터 완전히 새로운 것을 빛내고 완전히 할 수있는 기회를 얻었습니다.

가장 최근의 예 중 하나는 멀티 스레드 응용 프로그램에서 싱글 톤을 만들어야한다는 것입니다. 이 방법 을 사용하기로 결정했습니다 . Infestus가 그것을 보자 마자 그는 신속하게 나를 바보라고 부르고 나 에게이 접근법 을 사용하라고 말했습니다 . 그에게 왜 이것이 더 낫기 때문에 그것을 닦았는지 물었을 때 이것이 Java에 관한 이것 과이 책이 더 낫다고 말합니다.

그리고 그것은 일반적인 패턴입니다. 새로운 것을 할 기회가 생길 때마다 나는 Infestus에 의해 신속하게 격추되고 그의 방법이 더 좋은 이유는 유명한 프로그래머가 그 책을 썼기 때문입니다. 그는 항상 나에게 읽을 책을 주려고 노력하고있어서 어떤 방법으로 프로그램을“학습”할 수있다.

5 년 동안 돈을 벌기 위해 프로그래밍을 해왔지만 문제를 해결하기위한 최선의 방법에 대해이 책을 맹목적으로 따르는 것이 좋습니까? 아니면 가끔씩 실험 해보아야합니까? Infestus의 불만에 대한 끊임없는 분노는 새로운 것을 시도하지 않고 책의 예를 따르지 않기 시작했습니다.

편집 : 나는 완전히 길을 잃었다. 그렇습니다. 맹목적으로 따르는 것은 나쁜 생각입니다. 그러나 많은 것을 알고있는이 신과 같은 프로그래머 인 Infestus는 제대로 프로그래밍하는 유일한 방법은 책을 읽고 모든 것을 T에 따르는 것입니다. 그가 부과하는 모든 규칙은 책에 쓰여진 규칙이므로 책이 유일한 올바른 길이라면

EDIT2 : Infestus는 내 상사가 아닙니다. 그는 코드 검토를 담당하는 수석 개발자 중 한 명입니다. 그리고 리뷰 후의 그의 의견 대부분은 그와 같은 방법이 잘못된 책 이름으로 구성됩니다.

당신은 당신의 경력 전체와 같은 프로그래머를 만날 것입니다. 실험과 학습에는 아무런 문제가 없습니다. 물론 책은 훌륭합니다. 많은 예가 깨끗한 환경에서 작동하지만 다른 회사의 개발자 인 경우 다른 환경의 간섭없이 깨끗한 환경과 같은 것은 없습니다.

"올바른"방식으로 일을하는 방법을 아는 것은 언제나 좋은 일이지만 의견은 해마다 바뀝니다. 그래서 당신이 할 수있는 것을 배우십시오. 선임 개발자로부터 할 수있는 것을 가져 와서 스스로 배운 지식과 혼합하십시오. 결국, 당신은 선임 개발자가 될 것이며 이러한 경험을 가지고 주니어 개발자들을 가르치게 될 것입니다.

그것에 대해 바보하지 마십시오.

그는 정말로 당신을 바보 라고 부릅 니까, 아니면 코드를 비방 했습니까 ? 바보 같은 것을 부르는 것은 재치가 없지만 제안을 무효화하지는 않습니다. 나는 Infestus가 귀중한 제안을했다고 생각하며, 앞으로는 그의 제안을 진지하게 고려해야합니다. 그는 많은 책을 읽고있는 것 같습니다. 적어도이 경우에 그의 의견은 잘 알고 있습니다. 동기화는 비싸고 까다 롭습니다. 그의 권장 구현은 귀하보다 효율적이고 간단하며 작동합니다.

그는 항상 나에게 읽을 책을 주려고 노력하고있어서 어떤 방법으로 프로그램을“학습”할 수있다.

그런 사람입니다. 그는 적극적으로 당신을 돕기 위해 노력하고 있지만 당신은 자아를 방해하게하는 것 같습니다. 코드를 개인적으로 비난하지 마십시오. 코드는 생산 비용이 저렴하고 변경하기 쉽습니다. 누군가가 당신에게 무언가를하는 간단한 방법을 보여 주면, 그들에게 감사하십시오.

그렇습니다. 독서는 훨씬 더 좋은 프로그래머가 될 것입니다. 내가 아는 모든 전문가들은 광범위하게 읽었습니다. 많이 읽지 않으면 평범한 사람이며 5 년 후에는 더 이상 마케팅 할 수 없다는 것을 알게 될 것입니다.

책을 읽는 것은 장님이되어서는 안됩니다. 저자는 자신이 제시 한 접근 방식의 장점을 설득하려고 노력해야합니다. 선임자가 자신에게 설명하지 말고 자신이 선호하는 접근 방식을 설명하는 책을 가리 키도록하는 것이 합리적입니다. 이 책의 저자는 이미 만들었습니다.

따라서 책을 읽고 책의 저자가 말한 내용을보고 혼동하거나 이해를 확인하고 싶거나 동의하지 않는 경우 선배에게 이야기하십시오. 보다 생산적인 토론을 할 수 있습니다.

건전한 관계에는 세 가지 핵심 요소가 있습니다. 의사 소통, 정직 및 신뢰. 그것은 모든 관계, 심지어 일하는 관계까지 포함합니다. 이러한 문제에 대해 상사에게 문의해야합니다.

특정 디자인을 옹호하는 그의 이유를 이해하지 못한다면 그 에게 말해 주십시오. 그에게 책을 읽지 않았으며 왜 그의 책이 더 나은지 이해하고 싶다고 말하십시오. 열쇠는 당신이 있다는 것입니다 해야 일을 자신의 방법을 이해하려고 노력한다.

이 사람도 더 존중해야한다고 생각합니다. 당신의 머리 속에, 당신은 그를 욕설의 이름으로 부르고 당신이 "학습"이라고 생각하는 것에 대한 그의 접근을 비판합니다. 조심하십시오. 반면에, 당신은 그가 당신을 바보 라고 불렀습니다 . 그것은 시원하지 않으며, 누군가를 바보라고 부르는 것이 시원하지 않다고 말해야합니다.

아이디어는 바보가 될 수 있습니다. 우리는 모두 실수를 저지르고 시니어들조차도 그리워합니다. 설계에 결함이있을 때 가장 좋은 질문은 "왜 이런 식으로하고 있습니까? X, Y, Z 상황에서 중단되지 않습니까? B 설계가 더 나아지지 않겠습니까?"입니다.

이 소프트웨어를 다른 사람들과 함께 작업하고 있음을 명심하십시오. 배우기 어려운 기술입니다. 처음부터 아무것도 작성하지 않더라도 코드를 최상의 코드로 만들어 항상 빛을 발할 수 있습니다.

그리고 "최고"자주 의미 읽기 및 이해 . 우리 프로그래머들은 다른 사람들의 코드를 읽는 데 많은 시간을 보냅니다. 해당 코드가 명확하고 읽을 수 있으면 코드가 실제로 가치가 있습니다. 훌륭한 코드를 작성하는 방법 중 하나는 좋은 코드를 많이 읽는 것입니다. 당신은 종종 책에서 아주 좋은 코드를 발견합니다. 따라서 하나 또는 두 개의 좋은 프로그래밍 책을 읽으면 더 나은 프로그래머가 될 것입니다.

당신이 일하는 회사에서는 아마도 그럴 것입니다. 이것이 그들이 당신에게 요구하는 것입니다.

이 엔지니어 Infestus는 주니어 개발자들에게 "이것은이 책에 기록되어 있습니다."라고 말함으로써 매우 열악한 직무를 수행합니다. 그는 설교자도 아니고 엔지니어이기도합니다. 그는 그것을 분해하고 개념을 제시하여 후배들이 자신의 경험에서 배울 수있게해야합니다.

회사의 지식이 풍부한 개발자와 대화하고 다른 프로그래밍 기술의 장단점에 대해 질문 할 것을 권장합니다. 책과 블로그를 읽는 것과 함께 Joel을 추천합니다 (Google에서는 필수입니다). 더 나은 이해를 제공해야합니다.

IMHO에는 두 가지 측면이 있으며 별도로 처리해야합니다.

• 그 사람이 당신에게 이름을 부르는 바보 같은 사실은 단순히 그가 할 수 있기 때문에 (그는 수석입니다, 당신은 둘 중 하나가 다른 사람에 대해 불평한다면, 그는 의심의 이익을 얻을 것입니다) 깡패 같은 행동, 그리고 단지 나쁘다.

이것으로 그의 레벨에 닿지 않도록하십시오. 그를 괴롭 히거나 상사 나 다른 사람에게 "그에게 말하지 마십시오". 그의 행동의 이러한 측면을 무시하도록 최선을 다하십시오. 그것이 너무 극단적이되면 (즉, 생산성에 영향을 미치는 경우) 무언가를해야한다는 것을 명심하십시오.

• 그가 당신에게 당신의 코드가 잘못되었다고 말하고 있다는 사실 (그리고 그것을 올바르게하는 방법). 솔직히 말해서 그 사람의 말을 무시하고, 그의 행동의 이러한 측면은 그렇게 나쁘지 않습니다. 누군가가 당신을 시정하고 잘못한 것뿐만 아니라 자신이 모든 것을 혼자서 배우는 것과 비교하여 올바른 일을하는 방법을 말해 줄 때 더 빨리 배우고 올바른 맥락에서 볼 수 있습니다. 개인 시험 / 오류 실험 등).

많은 시간에 내가 처음에 "나의 완벽한 코드"라고 생각했던 것을 수정 한 사람이 있었고, 그 사람이 나중에 그가 옳았다는 것을 깨닫기 위해 무엇을해야하는지 말하고 있다는 사실에 화를 냈다. 내 버전은 나빴다. 좋았어요. 감사합니다. :) 그래서 나는 "이봐 요, 당신이해야 할 일을 말해주세요, 미타!" 대신 누군가 누군가 나를 교정 할 때마다 먼저 객관적으로 코드를 다시 확인한 다음 코드를 확인하고 실제로 옳지 않은지 확인하고 실수를 저지르는 사람이 나인지 확인하십시오. 그것이 내 잘못이라면, 나는 그 도움으로 그를 고맙게 생각하고 그의 해결책이 어떻게 작동하는지 이해해야합니다 (복사 / 붙여 넣기보다는).

그리고 때때로, 나는 제공된 수정이 실제로 내가 처음했던 것보다 더 나쁘다는 것을 알았습니다.이 시점에서 나는이 모든 것을 다른 사람과 이야기하려고 시도합니다. 솔직히 말해서, 실수를했을 때 시정을 받아 들일 수 있다는 것을 알았을 때보 다 다른 사람이 당신을 더 빨리 존중하지는 않는다는 것을 알았습니다. 그러나 동시에 당신이 한 사람이라고 두려워하지 않습니다. 자존심이 아닌 실제 연구에 근거한 긍정을 즉시 입증 할 수 있다는 점을 감안할 때 누가 그렇게 옳다고 생각하겠습니까?

이 시점에서 나는 당신이 정말로 그가 제안하는 것과 당신이 제안하는 것에 대해 그 남자와 대화하려고 노력해야한다고 생각합니다. 당신이 어떻게 생각하는지, 어떻게 당신이 특정한 해결책을 얻었는지, 왜 당신이 그것보다 더 낫다고 생각하는지 (정직하고 객관적으로 생각할 때) 보여주십시오. 또는 그의 제안이 당신보다 낫다는 것을 알게되면, 그에게 말하고 도움에 대한 감사를 표하십시오. 이로 인해 일부 다리가 재건 될 수 있습니다.

스스로 실험하고 가능한 모든 것을 배우십시오. 책을 충분히 읽은 후에는 특정 주제에 대해 여러 권의 책이 있으며 서로 모순 될 수 있음을 알게 될 것입니다. 시간이 있거나 비교 / 대비를 원한다면 가장 좋은 방법을 시도해보십시오.

상사를 상대하는 것은 완전히 다른 주제와 접근 방식입니다. 누군가가 책에 나온 것과 똑같은 일을하도록하고 싶다면 그들에게 말할 것입니다. 마음 독자와 관련이 없기 때문에 저뿐입니다. 당신의 상사는 이것을 습관으로 만듭니다. 새로운 프로젝트를받을 때 그가 어떤 책이나 참고 문헌을 추천하는지 물어보십시오.

무엇을하든 새로운 프로젝트 작업을 중단하지 마십시오. 나는 우리 모두가이 상황을 다루는 방법에 대한 팁을주는 것이 쉽다는 것을 알고 있으며, 그것이 작동하거나 작동하지 않을 수도 있지만, 당신은 그 상황에 부딪쳐서 부정을 겪어야하는 사람입니다. 당신은 더 나아질 것입니다. 그러나 그것은 보통 새로운 것에 더 많은 코드를 작성하고, 성공과 실패로부터 배우는 것에서 비롯됩니다.

맹목적으로 책을 따르는 것은 나쁜 생각이지만, 책을 정확하게 따르는 것과 맹목적으로 따르는 것에 는 차이가 있습니다.

당신이 책에서 물건을 이해하려고 할 때, 일반적 입니다 당신이 당신을 가르 칠하려고 무엇에 대한 느낌을 받고있는 동안, 정확히 처음에는 그것을 따라 적절한. 이상한 점은 당신이 끝났을 때 여전히 모든 것을 이해하지 못한다는 것입니다-이것이 이와 같은 것들이 일반적으로 일어나는 방식입니다. 확률은 책에있는 내용에 동의하지 않는 방법을 찾을 수 있다는 점에서 다시 한 번 좋지만 책에서 해결하려는 문제를 이해하게되므로 시간이 지남에 따라 자신의 코드를 작성할 수 있습니다. 나중에 문제를 물기 위해 문제를 남기지 말고 자신의 방식으로 (또는 적어도 부분적으로 그들의 방식으로) 해결하십시오.

본질적으로 Java에만 국한되지는 않지만 해당 커뮤니티에서 특히 일반적입니다. 나는 당신이 어떤 책에 대해 이야기하고 있는지 추측 할 수 있다고 생각하며, Java 커뮤니티의 어휘의 주요 부분을 형성합니다. 그것들과 그것들을 설명하는 방법을 이해하면 찾은 다른 Java 코드를 이해해야 할 때 엄청나게 도움이 될 것입니다. 그것은 그 자체로 귀중한 기술입니다.

책과 블로그 게시물을 읽는 것은 프로그래밍에 매우 도움이됩니다. 모든 개발자가 읽어야 할 책이 ​​있습니다.

그러나 책은 다른 프로그래밍 개념과 기술을 배울 수있는 유일한 출처는 아닙니다. 요즘 주문형 비디오 기반 교육이 인기를 얻고 있습니다. 전문가에게 고품질의 교육을 제공하는 Pluralsight 를 확인할 수 있습니다 .

사실, 당신도 도움이되지 않는 책만 읽는다면. 읽는 것 외에도 우리가해야 할 또 다른 일이 있습니다. 자세한 내용은 여기를 참조 하십시오 .

특히 당신의 방법에 어떤 문제가 있는지 물어봐야합니다. 그가 그것을 명확하게 대답 할 수 없다면, 당신은 그것이 우월하다고 느끼는 평범한 사람 일 것입니다.

책에 관한 것은 대부분 개정판을 통과하여 나쁜 관행과 오해를 발견 할 수있는 더 좋은 기회를 제공한다는 것입니다. 또한 "큰 이름"은 책을 파는 여분의 돈을 벌기 위해 좋은 경험을 가진 사람들이며, 따라서 그들이 말하는 것에 대한 최소한의 품질 보증이 있습니다.

즉, 책, 논문 및 기타 출처를 읽는 것은 물론 실제로 확인했을 때 전문가로 성장하는 좋은 방법입니다. 따라서 Infestus가 추천 한 책을 읽는 것이 좋습니다. 그러나 같은 문제를 해결하는 다른 방법이 거의 항상 있기 때문에 책은 주로 주제에 대한 이해를 넓혀야합니다.

"나 혼자서"접근 방식에 대한 요점은 다음과 같습니다. 관점을 유지할 수 있습니까? 솔루션이 다른 솔루션보다 우수하다는 것을 어떻게 증명합니까? 때로는 자체적으로 밝은 솔루션을 고안 할 수 있지만 다른 알려진 솔루션과 비교할 때 다른 사용자가 적어도 유스 케이스를 선호하기 때문에 더 나은 이유를 논쟁 할 수 있어야합니다. 그런 다음 창의적이고 사려 깊지 만 가장 중요한 것은 효과적입니다.

내가 있다면, 당신은 그 책들을 읽었을 것입니다. 그것은 당신에게 더 많은 주장을함으로써 당신을 도울 것입니다. 그리고 동시에, 당신은 아마도 Infestus가 아마도 그 책들을 논증으로 잘못 생각하고 있다는 것을 알 수있을 것입니다. 아니면 당신은 그가 실제로 k를 찾을 수 있습니다

저의 경험은 주제를 프로그래밍 할 때 인터넷에서 동일한 주제 정보를 검색 할 때 책의 적절한 설명과 함께 정보의 질과 표현이 훨씬 더 우수하다는 것입니다. 인터넷에는 종종 적절한 설명, 맥락 및 품질이 부족합니다.

인터넷상의 상기 정보의 양이 더 많다.

그래서 나의 일반적인 전략은 책에서 배우고 더 깊이 이해하고 인터넷에서 배우면서 다른 영향에 노출되어 내 경험을 넓히는 것입니다.

나는 각 접근법의 장점을 연구하고 자신의 판단에 올 것입니다. 당신의 접근 방식이 더 좋다고 생각되면, 누군가가 다른 사람을 설득 할 때까지 Infestus와상의하십시오. 합의에 도달 할 수없는 경우 의견에 대한 의견에 따라 두 번째 의견을 요청하거나 Infestus의 접근 방식을 수락 할 수 있습니다.

싱글 톤의 경우 열거 형 접근 방식에 반할 수있는 한 가지 주장은 열거 형이 클래스를 확장 할 수 없다는 것입니다. 나는 종종 다음과 같은 코드를 작성합니다.

public class DateSerializer extends AbstractSerializer<Date> {
  public static final DateSerializer SINGLETON = new DateSerializer();

  private DateSerializer() {}

  public byte[] serialize(Date date) { ... }
}

열거 형으로는 수행 할 수 없습니다. 열거 형 접근 방식이 모든 경우에 작동하지는 않으므로 일관성을 위해 extends절이 필요하지 않은 경우에도 피해야한다고 주장 할 수 있습니다 .

열거 형을 사용하여 반대 할 수있는 다른 주장들 :

• 그것은 해킹입니다-의도하지 않은 것에 열거 형을 사용하고 있습니다.
• 전에 보지 못한 독자에게는 혼란스러워합니다.

나는 지식의 원천으로 책에 크게 의존합니다. 이것들은 훌륭한 기초이며, Infestus는 당신의 여가 시간에 많은 양의 책을 실제로 사용하여 실력을 향상시켜야한다는 점에서 옳습니다. 책이 유일한 정보 출처는 아니지만 로컬 사용자 그룹에 참여하고 관련 기술 뉴스 레터를받은 편지함에 전달하고 블로그를 읽습니다.

그러나 나는 그것이 책에 어떤 방식으로 쓰여졌 기 때문에 그것이 반드시 이루어져야 한다는 주장에 동의하지 않는다 . 그렇습니다. 책은 훌륭한 조언을 제공하며 전문가가 작성하고 전문가가 동료를 검토하지만 비교적 간단한 책에 참여한 적이 있습니다. . 기술의 변화 속도는 빠르며 2 년 전의 조언은 더 이상 올바른 조언이 아닐 수 있습니다. 일반 보안 주체는 종종 시간을 테스트하지만 특정 활동 최적화는 새로운 하드웨어 또는 소프트웨어 릴리스로 무효화 될 수 있습니다.

Infestus가 귀하와 함께 제안을하도록 요청하는 것은 훌륭한 제안입니다. 멀리 나가서 모든 것을 읽고, 이미 답변 / 해결을 위해 시도한 많은 신중한 질문과 함께 방법.

5 년 후 왜 아직 주니어 였는지에 대한 질문이있었습니다. 나를 위해, 누군가가 주니어인지 여부의 주요 척도는 수년간의 경험이 아니라 숟가락 수유가 얼마나 필요한지입니다. 나는 중급 개발자가 상대적으로 자급 자족하고 사려 깊은 지식 소스 소비자가 행동하고이를 자신의 상황으로 확장 할 수 있기를 기대합니다. 또한 학생들은 주제를 확실하게 이해하여 사물을 명확하게 설명 할 수 있기 때문에 후배를 시작할 수있는 단계에 있어야합니다. 다른 핵심 역량은 자신감입니다. 작업을 완료하고 내용을 읽고 알맞은 것을 제작 한 경우, 주니어가 검증을 요구할 때 개발자가 합의를 요구할 때 토론의 법정에서이를지지하는 것을 두려워하지 마십시오.

직장 매너를 제쳐두고, 선임 개발자가 가지고있는 멘토 역할의 현실을 제쳐두고, 탐구하려는 당신 자신의 욕구를 제쳐두고, 모욕적 인 행동을 제쳐두고, 책에 대한 페티쉬를 따로 둡니다 ...

팀에서 코드 검토의 목적은 1) 코드를 검증하고 2) 코드를 작성하는 사람이 코드 개선의 의미를 이해하도록하는 것입니다. "마틴 파울러가 GoF 책에서 그렇게 말했기 때문에 이것을 바꾸십시오"라고 말할 곳이 아닙니다. 그러나, "[간단한 설명] 때문에 이것을 바꾸십시오; GoF 책에서 이것에 대해 더 자세히 설명하고 있습니다"라고 말할 곳입니다.

수석 개발자가 최소한 간단하고 미묘하게 변화에 대한 설명을 제공하지 않고 "[책] 때문에"라는 말을 사용한다고 주장하는 경우 그는 약간 현명하고 바보입니다. 어떻게 처리합니까? 팀 회의에서 구두로 언급하고, 팀원들에게 유용한 도서 참조 서와 함께 변경의 장점 또는 필요성을 설명하는 성명을 제공하도록 요청하십시오. 그 책을 참조 해 주셔서 감사합니다.

직면하자면, 당신의 목표는 변경 제안을 고맙게 생각하고 당신의 작업이나 직업에 대해 동기를 부여하지 않는 것입니다. 그에게 말해 "내 코드를 검토 할 때 변경의 장점 또는 필요성을 간략하게 설명 할 수 있다면 변경 제안을 더욱 감사하겠습니다. 책 참조만으로도 약간의 동기 부여가 될 수 있습니다."

그가 자신의 서적 참조에 대한 간단한 설명을 계속 거부하는 경우, 업계에서 다른 의견이나 다른 평판을 가진 다른 서적이나 자료를 다른 의견으로 제공 할 수 있고 시나리오와 일치하면 자신의 서적을 추가 할 수 있습니다 원래 코드를 유지하기 위해 검토 주석에서 참조하십시오. 충분한 시간을 내면 그는 물러 설 수 있습니다. 반론이 옳고 훨씬 더 중요하다는 점에 매우주의하십시오. 선임 개발자가 잘못하고 여전히 자신의 길을 가지게하는 것은 괜찮습니다. 이것은 제가 배우고 계속 배워야하는 것입니다.

책에서 프로그래밍을 배우는 것은 불가능하지만 좋은 책은 큰 도움이 될 것입니다. 그것은 가라테와 같습니다-당신은 그것에 대해 읽는 검은 벨트를 얻지 못할 것입니다;) 나는이 특별한 경우에 Infestus 씨가 Joshua Bloch의 "Effective Java"를 언급하고 있다고 생각합니다. 실제로 Java 개발에 대한 훌륭한 책이며 아직 읽지 않은 경우 반드시 읽어야합니다.