자습 코딩을 계속하거나 전문적으로 코딩하는 방법을 배워야합니까? [닫은]

최근에 나는 직업적인 일을하고, 다른 프로그래머들과 어울리고, 업계에서 친구를 사귀고 있습니다. 유일한 것은 100 % 독학입니다. 내 스타일이 제대로 훈련 된 스타일에서 크게 벗어났습니다. 내 코드의 기술과 구성이 다릅니다.

내가하는 몇 가지 일이 혼합되어 있습니다. 여러 프로그래밍 패러다임을 함께 사용하는 경향이 있습니다. 기능 및 OO처럼. 나는 OO보다 기능적 측면에 의지하지만 추상적 인 엔티티로 뭔가 더 의미가있을 때 OO를 사용하는 것을 봅니다. 게임 오브젝트처럼. 다음으로 나는 무언가를 할 때 간단한 길을 간다. 대조적으로, 때로는 전문 프로그래머가 보는 코드가 복잡해 보입니다! 나는 많은 폐쇄를 사용합니다. 그리고 마지막으로, 나는 최고의 주석가가 아닙니다. 주석을 읽는 것보다 코드를 읽는 것이 더 쉽다는 것을 알았습니다. 그리고 대부분의 경우 주석이 있어도 코드를 읽습니다. 또한 코드를 작성하는 방법 때문에 코드를 읽는 것이 매우 쉽다는 말을 들었습니다.

나는 전문적으로 훈련 된 프로그래머들이 단위 테스트와 같은 것들에 대해 계속한다고 들었습니다. 내가 전에 사용해 본 적이 없기 때문에 나는 그들이 무엇인지 또는 어떻게 작동하는지에 대한 희미한 생각조차하지 못했습니다. 정말 내 취향이 아닌 많은 밑줄 "_". 내가 사용하는 대부분의 기술은 나와 직접 읽거나 읽은 몇 권의 책입니다. MVC에 대해 아무것도 모르지만 backbone.js와 같은 것들에 대해서는 많이 들었습니다. 응용 프로그램을 구성하는 방법이라고 생각합니다. 지금은 나 자신의 조직 구조를 만들었 기 때문에 혼란 스럽습니다.

약간의 고통입니다. Ubuntu 's Quickly와 같은 새로운 것을 배울 때 템플릿 응용 프로그램을 전혀 사용할 수 없습니다. 내가 알 수있는 코드를 이해하는 데 어려움이 있습니다. 완전한 OO 프로그래밍은 실제로 입안에서 나쁜 맛을 남길 수 있지만 다른 사람들이 엄격하게 사용하는 것 같습니다.

내 코드 모양에 대해 확신이 없거나 회사에 합류하거나 오픈 소스 프로젝트에 기여할 때 불이 붙을 지 궁금해졌습니다. 사실 사람들이 결국 내 코드를 확인한다는 사실이 다소 무섭습니다. 이것은 프로그래머가 겪는 정상적인 일입니까, 아니면 실제로 내 기술을 바꿔야합니까?

사실 사람들이 결국 내 코드를 확인한다는 사실이 다소 무섭습니다.

좋은. 사람들이 당신의 코드를 보려고한다는 것을 의식하면 더 열심히 노력할 것입니다.

프로그래밍은 엄청나게 큰 분야가되었습니다. 수십 가지 주제, 도구, 틈새 및 전문 분야가 있으며 그 중 일부는 전체 경력입니다. 배우고 알아야 할 엄청난 양이 있으며, 다른 프로그래머와 함께 일할 때 항상 자신이 모르는 것과 그렇지 않은 것을 알게 될 것입니다. 이것은 좋은 일입니다.

당신의 경험이 불완전한 것이 걱정된다면, 공식적인 교육과 훈련 된 전문가와의 협력을 통해이를 수정할 수있는 많은 단계가 있습니다. 그러나 사람들이 "알았어요. 이제 마스터 했으니 공식적으로 프로그래머입니다."라고 말한 후 수량화 가능한 이정표가 있다는 것을 두려워하는 것 같습니다. 그러한 이정표는 없습니다. 나는 새로운 것을 배운 후에 "예, 지금 어딘가에 있어요"라고 생각한 순간을 확실히 보냈지 만 프로그래머라고 부르기 위해 알아야 할 것들의 마술 목록은 없습니다.

나는 프로그래밍에 대해 많은 것을 알고 있고, 많은 프로젝트에서 12 개 언어를 사용했지만, 내 자신이라고 부를 수있는 프로그래밍 지식의 하위 집합은 작습니다. 그리고 나는 그것을 좋아한다. 솔직히 프로그래머는 당신이 아닙니다. 프로그래머는 끊임없이 배우는 것입니다.

당신의 기술, 강점과 약점을 정직하게 조사하십시오. 당신보다 더 많은 경험을 가진 사람들로부터 피드백을 받으세요. 자신이 생각하는 곳과 잘 어울리는 직책을 찾으십시오. 그러나 현재 숙달 된 직업이 아닌 직업을 찾는 것을 두려워하지 마십시오. 이미 알고있는 직업 만 취하면 직장에서 배우지 않을 것입니다.

다른 개발자와 협력하여 응용 프로그램을 개발하기 시작하면 이러한 개인 스타일의 일부가 방해가 될 것입니다.

밑줄을 사용하는 상점에서 작업을 시작하면 밑줄을 사용하게됩니다. 이전의 배경에 관계없이 누구나 코딩 스타일에 대한 상점 표준을 따릅니다.

코딩 스타일이 매우 명확하지 않으면 코드 작동 방식을 설명하는 명확하고 간결한 설명을 작성하여 다른 개발자가 따라갈 수 있도록하는 것이 좋습니다.

단위 테스트에 대해 모른다면 좋은 책을 구입하십시오. 단위 테스트에 관한 좋은 책들이 많이 있습니다. MVC와 동일합니다.

전문 소프트웨어 개발자는 샌드 박스를 어지럽히 지 않고 다른 사람들과 잘 어울리는 방법을 알고 있습니다. 가장 좋은 것은 스타일에 관계없이 코드를 읽고 쓰는 방법을 알고 있습니다.

프로그래밍에는 예술 구성 요소와 전문 구성 요소가 있습니다. 예술 구성 요소는 최선의 접근법을 생각하고 구현하고있다. 징계는 귀하가 올바르게했는지 확인하고, 다른 사람들이 귀하의 코드를 이해하고 필요할 때 향상시킬 수 있도록하는 것입니다.

예술 요소는 재미 있습니다. 즐기기 때문에하는 것입니다. 당연히, 그것은 당신이 먼저 자신을 가르치는 부분입니다.

전문 분야 구성 요소는 성가신 것입니다. 그것은 팀에서 일하는 데있어 중요한 요소입니다. 최소한 어느 정도는 할 수 없습니다. 코드가 팀원의 코드와 통합되면 "의지에 따라 변경"할 수있는 유연성이 필요합니다. 그러나 변화하는 요구 사항에 대응하여 자신있게 코드를 변경하거나 버그를 해결하는 기능이 필요합니다. 여기에는 다양한 "지루한"테스트가 시작됩니다. 많은 테스트가 준비되어 있으므로 최신 변경 사항이 문제를 일으키는 지 쉽게 확인할 수 있습니다.

공통 스타일을 고수하면 모든 사람이 코드를 쉽게 읽을 수 있기 때문에 코드 스타일도 중요합니다. 대기업에서는 코딩 표준을 자동으로 준수하는지 테스트하는 야간 작업을 찾을 수 있으며, 이탈시 불쾌한 경고를 이메일로 보낼 수 있습니다.

귀하의 질문으로 돌아가서, 아트 구성 요소에 집중하는 것은 프로그래머 개발의 자연스러운 초기 단계입니다. 전문 분야 구성 요소를 이해하기 전에 업계에서 몇 년이 걸릴 수 있습니다. "기술 변경"을 적극적으로 바라 볼 필요는 없습니다. 팀에서 일하는 과정에서 자연스럽게 변형됩니다.

귀하의 질문에, 당신은 항상 독특한 프로젝트와 신흥 기술을 포용하기 위해 기술을 변경하고자합니다.

@assfallows의 지적은 "프랜차이즈는 프로그래머가 아닙니다. 프로그래머는 끊임없이 배우고있는 것입니다." 실제로 모든 것이되고 모든 코딩을 끝냅니다.

특히 표준이라고 볼 때 다른 것과 다른 것을하는 영역을 알아 차리는 것이 좋습니다. Unit Testing과 MVC를 발견했습니다. 이제 다음 단계에 대해 알아보십시오. 그들이 어떻게 작동하는지, 당신이 그것들을 구현하는 데 필요한 것을보고 그것들을 구현하기에 좋은 디자인인지를 이해하고 시도하십시오.

이것은 새로운 언어와 패턴이 점점 더 커지고 끊임없이 진화하는 분야입니다. 코딩 측면에 익숙한 경우 디자인 부분을 검사하십시오. 무엇이 좋은지 그리고 언제 사용하는지 배우십시오.

확실히 팀에 합류하는 것은 큰 이점입니다. 서두르거나 전체적인 의미를 생각하지 않은 영역을 파악하기 위해 코드를 살펴 보려면 항상 다른 시각이 필요합니다.

더 큰 논평자가 될 필요는 없습니다. 그러나 당신은 훌륭한 커미터가되어야합니다 (예, 일종의 VCS를 사용하십시오-Git을 권장합니다).

스타일은 항상 진화하는 것입니다. 걱정하지 마십시오. 재사용 가능한 코드와 그렇지 않은 코드를 배우게됩니다. 그러나 연습하고 도움을 받아야합니다.

Github의 일부 오픈 소스 프로젝트에서 도움을 받으십시오. 어떤 사람들은 그곳에서 정말 친절하고 당신을 돕기 위해 노력할 것입니다. 이것이 내가 당신에게 줄 수있는 가장 좋은 팁입니다.

사실 사람들이 결국 내 코드를 확인한다는 사실이 다소 무섭습니다. 이것은 프로그래머가 겪는 정상적인 일입니까, 아니면 내 기술을 바꾸려고 노력해야합니까?

더 숙련 된 프로그래머의 의견없이 어떤 내용을 변경해야하는지 어떻게 알 수 있습니까?

다른 사람이 작업을 검토하도록하는 것은 특히 처음 몇 번은 어려울 수 있지만 기술을 향상시키는 데 필요한 건설적인 비판을 얻는 가장 좋은 방법입니다. 도움이 될만한 코드 검토 를 위한 SE 사이트가 있습니다. 똑똑한 친구에게 코드를 보도록 요청하는 것은 피드백을 얻는 또 다른 좋은 방법입니다.

가장 중요한 것은 유연성을 개발하는 것입니다. 기본 개념에 익숙할수록 모든 언어, 프로그래밍 방식, 스타일 또는 환경에보다 신속하게 대응할 수 있습니다.

숙달은 다양한 상황에서 학습해야 할 모든 것 / 학습 /에 대해 배우는 것이 아니라 문제를 해결하는 방법에 대해 배우는 것입니다.

그리고 그것을위한 최고의 처방은 연습입니다. 항상 프로젝트가 있어야합니다. 유료 공연 사이에 있다면, 개인 장난감을 가져 가십시오. 한 주말 여유 시간? 이전에 사용해 본 적이없는 언어 또는 플랫폼에 대해 'hello world'를 통해 작업하십시오. 한 번에 많은 것을 배울 수있는 방법을 찾으십시오. 예를 들어 Google App Engine에서 무언가를 빌드하면 Python, BigTable 및 열 지향 데이터베이스에 대해 한 번에 배울 수 있습니다. "전문적인"Google 스타일도 많이 제공합니다.

좋은 장군은 배운 전술을 적용하고 다양한 지형에서 경험을 수집하는 방법을 알고 있습니다. 전술과 경험이있는 것처럼 들리지만 익숙하지 않은 지형을 만나야합니다. 그것은 당신이 알고있는 것과 다음에 배울 것이 무엇인지 확인하는 가장 좋은 방법 일 것입니다.

"프로페셔널"스타일이 당신이 추구하는 스타일이라면, "프로페셔널"프로젝트를 수행하십시오. 원하는 오픈 소스 프로젝트를 찾아서 변경 사항을 할당하고 설정하십시오. 멍청한 검토자를 위해 준비하십시오, 그러나이 분야에있는 대다수의 사람들은 매끄러운 사회 기술을위한 곳을 얻지 못했다는 것을 기억하십시오. 요점은 가능한 한 많은 것을 자신에게 노출시키는 것입니다. 그리고 당신은 그것을 스스로 할 수있을만큼 충분히 몸을 쌓아야합니다. 어떤 수업도 실제로 당신을 가르 칠 수 없습니다. 사실, 오늘날 진행중인 수업 학습은 너무 많으며 실제 역량은 충분하지 않습니다.

내 코드 모양에 대해 확신이 없거나 회사에 합류하거나 오픈 소스 프로젝트에 기여할 때 불꽃을 일으킬 지 궁금합니다. 사실 사람들이 결국 내 코드를 확인한다는 사실이 다소 무섭습니다. 이것은 프로그래머가 겪는 정상적인 일입니까, 아니면 내 기술을 바꾸려고 노력해야합니까?

제 생각에는 코드의 품질에 대한 객관적인 측정에 중점을두면 다른 사람들이 귀하의 코드에 대해 어떻게 생각하는지 걱정할 필요가 없습니다. 그렇습니까

• 옳은?
• 이해할 수 있는?
• 유지 보수 가능?
• 실력 있는?

첫 번째 원칙은 항상 다른 사람의 의견보다는 객관적인 자질에 초점을 맞추는 것입니다. 다른 사람들의 의견에 초점을 맞추는 것은 평범한 길이며, 경험하는 것처럼 불안합니다.

다른 사람들의 의견에 관심을 가지는 유일한 이유는 다른 사람들과 사회적으로 (또는 작업 환경에서) 잘 통합 될 수 있기 때문입니다. 작업의 객관적인 특성을 개선하려는 목표를 염두에두고 있다면, 다른 사람들의 반응에 대해 두려워 할 필요가 없습니다. .

자신에게 진실하십시오! 당신이하는 일을 계속 배우고 즐기십시오.

당신은 소프트웨어 엔지니어가되기 위해 대학에 진학한 후 저 자신을 생각 나게합니다. 프로그래머가되고 싶다면 위치를 잡으라고 말하십시오. 코드에 주석을 달고, 단위 테스트를 작성하고, 객체 지향 코드를 완전히 이해해야합니다. 그러나 지금 당장 그렇게 할 이유가 없습니다. 개인 소규모 프로젝트를 수행하는 한. 자신 외에 다른 사람에게 대답 할 필요가없는 곳. 더 이상 개발자로서 성장하지 않을 것입니다.

많은 사람들이 작업하고있는 대규모 프로젝트를 수행하고 "이 릴리스 버그는 무료입니까? 고객에게 릴리스 할 것이므로"과 같은 질문에 답변해야합니다. 프로그래머 / 엔지니어로 성장할 것입니다. 약간의 노크가 발생합니다. 당신이 언급 한 것들이 더 가치있는 것을 발견 할 수 있고, 이전에는 아무도 없었던 새로운 것을 발견 할 수 있습니다. 당신은 성장할 것입니다.

우리 대학조차도 그들이 시도했지만 이런 것들을 가르치지 못했습니다.

단위 테스트의 경우 테스트 주도 개발을 찾으십시오.

코멘트를 위해 당신이 사라진 후에 작성한 코드를 생각하십시오. 그리고 다른 사람들이 그것을 리버스 엔지니어링하는데 쓰는 시간.

객체 지향 언어의 경우. 적어도 이해하십시오. 보다 읽기 쉬운 방식으로 문제를 해결하는 데 사용할 수있는 도구입니다.

행운을 빕니다 : D

즉, 배울 수있는 가장 좋은 방법은 당신이 배울 수있는 사람과 어울리고 일반적 에서 . 당신의 기술이 처음부터 끝나지 않았다고 생각한다면, 당신보다 더 나은 사람들과 어울리는 것이 최선입니다. 확실히 자신을 더 이상 철수하고 고립시키는 것보다 훨씬 낫습니다.

그러나 나는 당신이 매우 간단하고 오도하는 그림을 그리는 것 같습니다. "전문적으로 가르치는"모든 프로그래머와는 거리가 멀다. 그들이 무언가를한다고해서 반드시 옳은 일을 의미하는 것은 아닙니다.

그리고 당신이 말하고있는 것의 많은 것 (그러나 전부는 아님)은 그들 에게 트릭을 가르 칠 수 있는 사람인 것처럼 들립니다 .

나는 OO보다 기능적 측면에 의지하지만 추상적 인 엔티티로 뭔가 더 의미가있을 때 OO를 사용하는 것을 봅니다.

그것은 나에게 큰 소리로 들린다. 최고의 코더는 작업에 적합한 도구를 사용하는 코더입니다. 나는 항상 두 패러다임을 모두 아는 사람을 선택하고 종교적으로 하나의 패러다임을 사용하는 사람보다 의미가있는 곳에서 각각을 사용합니다.

다음으로 나는 무언가를 할 때 간단한 길을 간다. 대조적으로, 때로는 전문 프로그래머가 보는 코드가 복잡해 보입니다!

다시 한번, 단순성이 좋습니다 . 이 때까지 코드가 복잡하지 마십시오 필요가 복잡 할 수 있습니다. 어떤 사람들 은 잘못 인도 된 우아함이나 "나중에이 추가 기능이 필요할 것"때문에 복잡하게 만드는 경향이 있습니다. 일반적으로 문제를 해결하는 가장 간단한 방법을 사용하는 것이 좋습니다.

나는 많은 폐쇄를 사용합니다. 좋은. 그래서 그들이 거기에 있습니다. 그들은 1990 년대와 자바의 낡은 quasi-OOP 모델에 갇힌 일부 사람들을 두려워하지만 실제로는 이것이 그들의 문제입니다.

그리고 마지막으로, 나는 최고의 주석가가 아닙니다.

의견이 무엇이며 어떻게 주관적인가. 실제 "올바른"또는 "틀린"것은 없지만 팀에서 작업 할 때는 코드 작성자뿐만 아니라 팀 전체가 이해할 수있는 코드를 작성하는 것이 중요합니다. 때로는 팀의 코딩 스타일에 맞게 타협해야합니다. 그렇다고해서 반드시 더 많은 의견을 써야한다는 의미는 아닙니다. 그것은 단순히 귀하와 귀하의 팀이 동의해야 할 내용임을 의미합니다.

나는 전문적으로 훈련 된 프로그래머들이 단위 테스트와 같은 것들에 대해 계속한다고 들었습니다. 내가 전에 사용해 본 적이 없어서 그들이 무엇인지 또는 어떻게 작동하는지에 대한 아주 희박한 아이디어조차도 없었습니다.

물어봐 :) 코드 테스트는 필수적이며 단위 테스트는 널리 사용되는 유용한 도구입니다.

정말 내 취향이 아닌 많은 밑줄 "_".

주석과 마찬가지로 주관적이며 언어에 따라 다릅니다. C 및 C ++에서는 lowercase_with_underscores상당히 일반적인 명명 규칙입니다. 다른 많은 언어에서는 사실상 밑줄이 표시되지 않습니다. 그러나 하루가 끝나면 실제로 중요하지 않습니다. 함수가 호출되는지 write_to_log또는 WriteToLog실제로 차이를 만들지 않을지 여부 누군가는 단지 그것을 빨아 들이고 팀이 동의 한 것에 따라야합니다.

MVC에 대해 아무것도 모르지만 backbone.js와 같은 것들에 대해서는 많이 들었습니다. 응용 프로그램을 구성하는 방법이라고 생각합니다. 지금은 나 자신의 조직 구조를 만들었 기 때문에 혼란 스럽습니다.

단위 테스트와 마찬가지로 학습을 중단하지 마십시오. 당신은 당신이 모르는 것을 알고 있고 당신과 다른 배경에서 온 사람들과 함께 일합니다. 서로에게서 배우십시오. 당신이 그들에게 가르 칠 수있는 것들이 분명히 있지만, 당신이 알지 못하거나 들어 본 적이없는 것들도 있습니다. 그렇다고해서 당신이 나쁜 프로그래머라는 의미는 아닙니다. 좋은 프로그래머는 개선하고 다른 사람들로부터 배우려고 노력하는 사람입니다.

완전한 OO 프로그래밍은 실제로 입안에 나쁜 맛을 남깁니다.

여기에서도 마찬가지입니다. 저는 "전문 교육"(CS 학위)이라고 부르는 것입니다. 프로그래밍을 배운 사람들은 스스로 가르치는 사람들만큼 다릅니다. 실제로 몇 가지 새로운 트릭을 배워야하는 사람들과 함께 일하는 것처럼 들립니다.

사실 사람들이 결국 내 코드를 확인한다는 사실이 다소 무섭습니다. 이것은 프로그래머가 겪는 정상적인 일입니까, 아니면 내 기술을 바꾸려고 노력해야합니까?

양자 모두. 물론 다른 사람들이 당신이 한 것을 보거나 판단하게하는 것은 무섭습니다. 그러나 그것은 또한 매우 교육적입니다. 그들은 다른 방법으로 무엇을 했는지 또는 왜 다른 방법으로했는지 말할 수 있습니다 . 그들은 당신이 향상하도록 도울 수 있으며, 또한 스스로 무언가를 배울 수도 있습니다. 그들에게 "선호하는"솔루션보다 더 나은 문제를 해결하는 코드를 보여 주면 좋겠다. "아, 그래도 깔끔하다. 어떻게 알았 니? 이것을 어떻게 부르는가?이 기술을 직접 사용해야한다" "

이것은 완전한 대답이 아닙니다. 이미 몇 가지 좋은 답변이 있습니다. 그러나 약간 혼란스럽고 해결되지 않은 몇 가지 사항이 있습니다.

내가하는 몇 가지 일이 혼합되어 있습니다. 여러 프로그래밍 패러다임을 함께 사용하는 경향이 있습니다. 기능 및 OO처럼. 나는 OO보다 기능적 측면에 의지하지만 추상적 인 엔티티로 뭔가 더 의미가있을 때 OO를 사용하는 것을 봅니다. 게임 오브젝트처럼.

나에게 당신은 Functional Vs Object Oriented 프로그래밍보다는 선언적 프로그래밍 과 명령 적 프로그래밍을 혼동하는 것처럼 보입니다 . 선언적 프로그래밍에 의존하고 명령형에서 멀어 졌다는 것이 좋은 일입니다. 선언적은 부작용을 제거하여 코드를 이해하기 쉽게 만듭니다.

현대 프로그래밍 언어는 종종 선언적 프로그래밍 모델을 지원합니다. 예를 들어 C #에서 Linq를 사용하면 원하는 스타일을 얻는 방법을 말하지 않기 때문에 선언적인 스타일이됩니다. 당신은 당신이 원하는 것을 말하고 있습니다.

완전한 OO 프로그래밍은 실제로 입안에서 나쁜 맛을 남길 수 있지만 다른 사람들이 엄격하게 사용하는 것 같습니다.

현대 언어는 종종 다중 패러다임 언어입니다. "순수한"언어를 사용하는 사람은 거의 없습니다. 많은 기능적 언어가 객체와 부작용을 지원합니다. 객체 지향으로 간주되는 언어는 종종 모든 것이 객체라는 제약을 부과하지 않습니다.

완전한 OO는 무엇을 의미합니까? 나는 "순수한"OO 코드를 작업 한 적이 없다. 아마도 당신이 싫어하는 것에 대해 좀 더 구체적으로 설명해 줄 수있을 것입니다. 오픈 소스 프로젝트의 일러스트레이션이 도움이 될 수 있습니다.

OO 프로그래밍은 데이터 추상화, 캡슐화, 메시징, 모듈화, 다형성 및 상속과 같은 기능을 지원하는 많은 기능을 제공합니다. 그것을 활용하지 않은 코드베이스를 살펴보면 입안에 나쁜 맛이 남을 것입니다.

짧은 대답 : 예.

자신을 가르치는 것은 거의 모두 좋다.
좋은 의미, 좋은 조언으로 필터링하십시오.

WRT 학습 전문 프로그래밍, 예.
당신은 무엇을 생각하고 있습니까?
회의, 세미나, 인증, 학위?
각각 비용 / 혜택이 있습니다.
투자 수익 (ROI)이 좋으면 리소스가 있으면 활용하십시오.

출처를 고려하여 학위에 대한 조언을하세요. 관심이 있거나없는 사람들은 관심을 보였습니다.
각각 6 개씩 이야기하십시오.

학계는 산업과 분리되어 있습니까? 자주.
학위 가치가 없습니까? 달러로, 논쟁하기 어렵다.
대학원은 항상 더 많은 돈을 벌지 만 대학 대출을 조심하십시오.

지식이 현명한가? 아마도.
당신이 학교를 싫어한다면, 당신은 당신이 넣은 것보다 더 많은 것을 얻을 수 없습니다.

학위가 당신에게 가치있는 목표라고 생각한다면 아마 그럴 것입니다.

더 깊이 파고 연구 프로그램, 비용, 환경에 대해 알아보십시오. 관심, 헌신, 시간 및 자원이 있는지 확인하십시오. 아마도 13 년 동안 학교에 갔을 것입니다. 그러면 또 다른 4 개는 무엇입니까? 그것들은 가장 비쌀 것이며, 가장 가치있게 만드는 데 당신이 의지 할 주요 인물은 당신입니다.

비용은 꽤 무서울 수 있지만 장점, 필요 및 기타 100 가지 이유에 대한 많은 보조금과 장학금이 있기 때문에 이야기의 일부만을 알려줍니다.

당신이 가면 똑똑한 교수와 싹을 선택하십시오.

두 번째 질문-나만의 스타일을 사용할 수 있습니까?

두 가지 질문이 있습니다.

첫 번째는 제목에 있습니다. 내 이전 답변을 참조하십시오.

두 번째는 약 5 개의 단락에 자세히 설명되어 있으며, 여기에 나와있는 요점을 통해 스타일이 전문 스타일과 어떻게 다른지 특징을 나타냅니다.

• 100 % 자기 교육.
• 기술과 조직이 다릅니다.
• 기능과 객체 지향의 조화.
• 덜 복잡합니다.
• 많은 폐쇄.
• 의견이 거의 없습니다.
• 단위 테스트가 없습니다.
• 밑줄이 거의 없습니다.
• MVC가 없습니다.
• backbone.js가 없습니다.
• 템플릿 애플리케이션이 없습니다.

요약하자면, 프랭크 시나트라 (Frank Sinatra) 접근 방식을 사용하는 것이 좋을지 묻습니다. 나는 다른 사람들의 코드 전문가에게 전화를 걸면서 애매 모호함을 느낀다. 스타일은 끈끈한 개인적인 문제이며 좋은 코드가 무엇인지에 대한 논쟁은 끝이없고 종종 시간 낭비입니다. 그룹에서 서면 코딩 규칙을 사용하면 일부 문제가 더 쉬울 수 있습니다. 확인하시기 바랍니다 :

http://en.wikipedia.org/wiki/Coding_conventions

다른 사람의 코드를 죽이는 데 에티켓이 있으며 이는 팀과 함께해야 할 또 다른 일입니다. 당신의 두꺼운 피부를 입히고 그들이 너무 잔인하지 않기를 바랍니다. 그러나 당신이 무엇을 하든지 전쟁에 가지 마십시오.

다른 사람이 내 코드를보고있는 것에 대한 불안에 대해 언급했습니다. 그들이 볼 수있을뿐 아니라 다시 작성하여 자신의 스타일에 어떤 문제가 있는지 알려주므로 준비하십시오. 동료는 유연하거나 엄격 할 수 있습니다. 어느 쪽이든 스타일에 대한 코드를 다시 작성하거나 각 스타일을 협상하지 않는 것이 좋습니다.

통일 된 코드 (및 통일 된 훈련)를 갖는 이유는 개발 속도와 생산성을 높이고 어쨌든 모범 사례 학습을 제도화하기 위함입니다. camelCase 또는 use_underbars와 같은 문제는 사소하고 사소한 것처럼 보일 수 있지만 일관성에 이점이 있습니다.

단위 테스트 및 테스트 중심 개발에 개방하십시오. 당신이 혼자서, 유료로 프로젝트를 수행하는 일이 아니라면, 그것은 더 취미와 같습니다. 당신의 물건은 다른 사람들의 행동과 맞 물릴 필요가 없습니다. 코드가 충돌해도 큰 문제는 없습니다. 그러나 팀에 참여할 때 작성하는 코드는 팀 전체에 영향을 줄 수 있습니다 (특히 고객에게 도달하는 경우).

마찬가지로 팀에서 MVC를 사용하는 경우 참조하는 것과 동일한 소스에서 MVC에 대해 알아보십시오. 프로그램을 구조화하는 방법은 실험에 의해 나타난 바와 같이 큰 차이를 만들 수 있습니다. 다시 한 번, 팀의 모범과 리더십을 생각해보십시오.

팀에서 backbone.js를 사용하는 경우에도 사용합니다. 당신의 팀은 대형으로 날아 다니는 오리와 같습니다. 함께 줄을 서면 에너지 소비가 줄어들고 더 안전 해지며 더 효과적으로가는 데 도움이됩니다. 당신이 그것을 많이 밀면 비유가 무너지지 만 일반적인 도구, 기술을 사용하고 팀 결정 뒤에 정렬하는 데 큰 이점이 있습니다.

주어진 조언은 매우 유용하지만, 나의 주된 목표는 사용자에게 유용한 '작동하는 소프트웨어'를 만드는 것입니다. 내 청중은 일반적으로 프로그래머 그룹이 아닙니다. 자동 솔루션에 돈을 지불하려는 사업가입니다 (사용자는 OO 방법론, 프레임 워크, 단위 테스트, 코드 주석 등에 신경 쓰지 않으므로 너무 신경 쓰지 마십시오) 전화를 끊었습니다.)

Agile Manifesto의 이상이 내 경력에 유용하다는 것을 알았습니다 (www.agilemanifesto.org).

• 프로세스 및 도구에 대한 개인 및 상호 작용
• 포괄적 인 문서에 대한 작업 소프트웨어
• 계약 협상을 통한 고객 협업
• 계획에 따라 변경에 응답

나는이 질문과 완전히 관련이있다. 나는 똑같은 감정과 매우 비슷한 배경을 가지고 있습니다 (그러나 똑같지는 않습니다). 나는 전문적으로 (또는 오히려 학문적으로) 훈련을 받아야하므로 OO 프로그래밍 등에 대해 알아야합니다. 프로그래밍은 주요 주제가 아니었지만 그 일을했습니다. 나는 일부 코스에서 OO를 배웠고 이유가 무엇인지 전혀 이해하지 못했습니다. 사실, 내가 OO를 이해 한 유일한 시간은 상업 작업을했을 때였으며 두 명의 위대한 멘토들에 의해 강제되었습니다.

교수님도 똑같이 훌륭하다고 생각하지만 상업 환경과 기능 프로그래밍의 실제 이점은 실제로 보지만 몇 개월 내에 실행하고 가르치고 끝내도록 설계된 과정에서 볼 수는 없습니다 . 나는 MVC 기반 구조에서 작업 할 기회를 얻지 못했지만 그것이 똑같을 것이라고 확신합니다. 즉, 책에서 작동하는 개념을 선택할 수는 있지만 그것을 사용하는 것을 볼 때 그 이점을 이해할 것입니다 상업 환경. 더 간단한 방법으로 문제를 해결할 수 있다면 OO와 MVC 및 기타 복잡한 구조를 사용하는 이유에 전적으로 동의합니다. 나의 충고는 일이 부끄러워하지 말아야한다는 것입니다. 그것이 당신을 다른 상황에 노출시키고 다른 일에서 같은 것을 이해할 수있게하기 때문입니다.

물론 나는 학문적 배경에서 구문과 개념을 배웠지 만 프로그램을 배우기 시작한 것은 상업계에 있습니다.