코드를 작성하는 것에서 훌륭한 개발자가되는 방법은 무엇입니까?


10

스크립트 작성 (bash, awk)에서 간단한 응용 프로그램 (c, php, python)을 작성하는 것에서 더 크고 복잡한 소프트웨어를 설계하고 개발하는 방법에 대한 구체적인 설명이 없기 때문에 좌절합니다. 한쪽에는 프로그래밍 언어 서적이 있고 다른쪽에는 프로그래머 팀을 위해 설계된 소프트웨어 엔지니어링 / 프로젝트 관리 서적이있는 것 같습니다.

둘 다 많이 읽었습니다. XP / Agile 클래식을 읽었 으며 소프트웨어 개발 프로세스에 대한 적절한 이론적 이해가 있습니다. 나는 다른 사람들의 코드를 읽고 그것을 아주 잘 따라갈 수 있습니다. 그러나 프로젝트에 대한 아이디어가 있거나 "여기에 문제가 있습니다."에서 "여기에 해결책이 있습니다"로 가고 싶을 때, 내 마음은 공백이되고 어디서부터 시작해야할지 모르겠습니다.

방금 해킹합니까? 팀에서 일하지 않는 개별 개발자 나 대규모 소프트웨어 하우스를위한 구조화 된 워크 플로우가 있습니까? PMP를 얻거나 소프트웨어 회사에서 일하고 싶지는 않습니다. 나는 효과적이고 효율적이며 실용적인 워크 플로를 찾고 있습니다.


2
경험은 좋은 선생님입니다.
Bernard

더 크고 복잡한 소프트웨어가 더 단순하고 단순한 소프트웨어의 모음 일 뿐입니 까?
Rig

5
"예술에있어 가장 중요한 것은 일하는 것입니다. 매일 앉아서 노력하는 것 외에는 아무 것도 중요하지 않습니다."
-Steven

Carnegie Hall에 도착하는 것과 같은 방법 ...
Michael Brown

1
Carnegie Hall에 도착하는 것과 같은 방법으로 연습하십시오!
Martin Beckett

답변:


11

내 의견으로는, 당신은 경험을 하고 여러 가지 일을하는 방법으로 일 함으로써 좋은 개발자가됩니다 . 당신은 "여기에 내 생각이있다"에서 "여기에 내 해결책이있다"라는 문제가 있다고 언급했다. 이는 소프트웨어 개발 방법론과 숙련 된 개발자가되는 것입니다.

소프트웨어 개발 방법론을 사용하는 것은 "코드를 해킹하는 것"이상의 의미를 가지며, 이러한 방법론은 체계적인 워크 플로를 제공합니다. 애자일 패밀리는 소규모 개발팀 (또는 개인)에게 "아이디어"단계에서 "완제품"단계로 나아가는 데 도움이되는 훌륭한 구조를 제공합니다.

몇 년 동안 다른 사람들로부터 그리고 다음과 같은 다양한 프로젝트를 통해 배운 것들이 몇 가지 있습니다.

  • 모든 것을 시험 할 수있게하십시오. 그러면 인생이 훨씬 쉬워 질 것입니다.
  • 완벽한 디자인을 기대할 수 없으며, 경험이 없어도 엔터프라이즈 응용 프로그램 / 다음으로 큰 게임 타이틀을 추가하거나 여기에 더 많은 것을 삽입 할 수 있습니다.
  • 경험이없고 다른 사람들로부터 배운 경험이 없으면 좋은 소프트웨어를 설계하기가 어렵습니다.
  • 숙련 된 개발자 인 경우에도 처음으로 완벽한 디자인을 만들 수 없습니다. 당신의 디자인도;
  • 적어보기 : 글쓰기 / 그리기 / 화이트 보드 / 페인팅 / 편안함이 무엇이든 적어 놓으면 인생이 더 쉬워집니다. GUI 디자인, 클래스 다이어그램 등. 내 경험상 "함께 무언가를 해킹"하는 것은 치명적으로 실패 할 가능성이 있습니다.
  • 바퀴를 재발 명하지 마십시오. 자신의 HashMap을 구현하려고하면 아마도 뭔가 잘못했을 것입니다. 연구하고 코드를 작성하기 전에 생각하십시오.

그 중 일부가 도움이되기를 바랍니다.


어쩌면 연필과 종이없이 지나가려는 디지털 시대의 증상 일 수도 있습니다. 마인드 맵 등을 만드는 것을 기억합니다. 좋은 조언.

글쓰기에 동의합니다. 나는 아주 작고 게으른 팀에서 일하는 공정한 경험이 있으며, 가장 먼저 할 일은 소프트웨어 / 모듈의 기본 요구 사항을 나열하는 것입니다. 무엇을합니까? 소프트웨어 설계 원칙, 즉 본질적으로 뒤 따르는 것들을 배우십시오. 언어 나 기술에 대한 언급없이 처음에 고도로 구조화 할 필요는 없으며 방향을 집중시키는 데 도움이되는 몇 가지 구성 참고 사항 만 있습니다. 명확한 지시가 있으면 그것을 구현하는 방법을 알아 내십시오.

나는 당신이 어떤 종류의 스크래치 패드없이 연필이나 종이 또는 화이트 보드와 같은 것을 실제로 디자인 할 수 있다고 생각하지 않습니다. 또한 프로젝트 디자인의 모든 반복을 유지합니다. 스크랩해야 할 위대한 아이디어가 언제 실현 될 수 있는지 알 수 없기 때문입니다.
TMN

저는 매우 시각적 인 사람이므로 사진은 항상 이해하고 해결하는 데 도움이됩니다. :-)
Deco

5

글쎄요, 다른 직업과 마찬가지로 이론적으로도 형성하는 것 외에도 모든 것이 잘되는 전문가가되는 것은 경험 입니다.

의사가 의과 대학에서 수강하는 수업만으로는 충분하지 못하거나 변호사는 학위만으로도 출국자의 정치적인 측면을 모두 알 수 없기 때문에 좋은 개발자가되기 위해서는 경험과 시간이 필요합니다.

타사 코드를 읽음으로써 경험이 오지 않습니다. 의대생을 받으면 많은 절차, 병, 의약품 등을 지적 할 수는 있지만 이러한 절차의 실제 적용 (하나의 절차를 적용 할 때, 진단 할 질병 등) 감독과 경험으로.

대기업 (또는 그 문제에 대한 회사)에서 일하고 싶지 않기 때문에 한 번에 한 단계 씩 작은 응용 프로그램을 개발하는 것이 좋습니다. 혼자서 소프트웨어를 개발하는 데 많은 시간이 걸립니다.

좋은 소프트웨어 개발자 / 엔지니어가 되라고 제안하는 또 다른 것은 오픈 소스 소프트웨어에 기여하는 것입니다. 많은 사람들이 오픈 소스 소프트웨어 개발을 돕고 나중에 상담을함으로써 많은 돈을 벌었습니다. 그들은 오픈 소스에 대한 공헌으로 자신의 이름을 만들었습니다.

어쨌든, 나는 경험을 얻는 데 지름길이 없다고 생각하며, 훈련인내심을 가지고 추구해야합니다 .


좋은 비유입니다. 다른 사람들의 코드를 읽으면 내 스타일에 도움 이되었지만, 맞습니다. 실제 경험은 아닙니다. 다른 누군가가 OSS 경로를 제안했습니다. 내가 살펴볼 것 같아요.

4

다른 사람들의 코드를 향상 시켜서 시작할 수 있습니다. 가지고있는 프로젝트를 가져 와서 기능을 추가하십시오. 기능이 수행 할 작업과 수행 방법을 결정해야합니다. 기존 코드의 프레임 워크 내에서 작업하여 솔루션을 설계하십시오.

그리고 물건을 해킹하는 것을 두려워하지 마십시오. 빠르고 새로운 프로토 타입을 수정 (또는 바람직하게 다시 작성)하여 많은 새로운 개발이 이루어집니다. 계속해서 책에서 최악의 연습과 반 패턴을 모두 사용하고 원하는 것을 수행하십시오. 그런 다음 돌아가서 올바르게 디자인하십시오. 일반적으로 800 줄의 3 단계 절차로 일부 구성 매개 변수를 하드 코딩하는 동안 "알고 싶습니다.

나는 그것이 유행에 맞지 않는다는 것을 알고 있지만, 구조적 분석 기술은 실제로 소프트웨어 디자인을 다루는 데 도움이되었습니다. 몇 가지 버블 차트와 DFD를 만들어 문제를 분해하고 시스템의 다른 부분이 함께 작동하도록 디자인하십시오.


2

다른 사람들이 말했듯이 경험은 코드 작성에서 비롯됩니다. 그러나 가능한 경우 다른 사람이 코드를 검토하도록해야합니다. 숙련 된 프로그래머는 코드의 문제를 지적하고 더 나은 방법을 보여줄 수 있습니다. 오픈 소스 프로젝트에 참여하면 두 가지 모두를 수행 할 수 있습니다.


1

저에게는 더 큰 소프트웨어를 작은 덩어리로 나누는 데 도움이됩니다. 그런 다음 청크를 더 작은 부분으로 나눕니다. 모든 소프트웨어 프로그램은 작은 논리 조각 모음입니다.

예를 들어 블로그를 생각해보십시오. 다른 사람이 읽을 수있는 게시물을 작성하고 편집 할 수 있기를 원합니다. 즉시 프로젝트를 관리자 및 공개 섹션으로 나눌 수 있습니다. 최소한 관리자에게는 관리자, 로그인 페이지 및 블로그 관리 섹션이 필요합니다. 블로그 관리 섹션은 CRUD (만들기, 읽기, 업데이트, 삭제) 인터페이스로 나눌 수 있습니다. 새 블로그 게시물을 만들려면 관리자에게 올바른 권한, 양식, 양식 유효성 검사 및 데이터베이스에 저장할 수있는 기능이 있는지 확인해야합니다. 등등.

문제 나 기능을 세분화할수록 관리하기 쉬워집니다. 나누고 정복합니다. 이와 같이 소프트웨어를 매핑 한 후에는 서로 다른 부분이 어떻게 상호 작용하는지 살펴볼 수 있습니다. 코드를 어디에서 반복 할 수 있습니까? 무엇을 추상화 할 수 있습니까? 이것은 계획하고 코드 자체를 작성할 때 반복적 인 프로세스 여야합니다.

다른 기능을 추가하기 전에 최소 기능 세트가 무엇인지 파악하고 구현하는 것이 좋습니다. 향후 변경이 너무 어려워지지 않도록 방어 적으로 코드를 작성하고 싶지만 동시에 완료되지 않는 반 기능을 구현하고 싶지는 않습니다. 융통성을 유지하고 자기의 사랑을 무자비하게 죽이고, 문학적 참고 자료를 빌리려는 사이를 걷는 것은 어려운 일입니다. 그 특정한 균형을 잘 잡는 것은 경험에서 비롯됩니다.

그리고 그것은 다른 답변에서 언급했듯이 경험입니다. 그것을 얻는 유일한 방법은 바로 시작하는 것입니다. 처음부터 완벽하게 만드는 것에 대해 너무 걱정하지 마십시오. 먼저 코드를 작동시킨 다음 아름답게 만들고 빠르게 만듭니다.

또한,이 단락과 달리, 마지막에 보안을 나중에 생각하지 마십시오. 소프트웨어가 손상 될 수있는 방법에 대한 아이디어가 있어야하지만 처음에는 사용자 입력을 신뢰하지 마십시오.


0

나는 당신이 소프트웨어 회사에서 일하고 싶지 않다고 말하지만, 다른 많은 답변이 이야기하는 경험을 얻을 수있는 좋은 곳입니다. 그리고 큰 프로젝트에서 일하고 싶든 아니든 다른 사람들의 작업과 작업 스타일에 대한 노출은 좋은 것입니다.

예를 들어, 혼자서 페어링 프로그래밍을 시도 할 수는 없습니다. 그리고 당신보다 똑똑한 사람과 짝을 이룬다면, 그 방법론에 대한 경험을 쌓으면서 더 좋은 방법을 얻을 수 있다는 추가적인 이점이 있습니다.

BTW, 나는 경험, 기술 등의 평균보다 낮은 느낌을 가진 그룹과 함께 일하는 것을 연습하게 만들었습니다. 내 게임이 엄청나게 올라갑니다. 그것은이다 훨씬 혼자 있음을하거나하고있는 "경험"사람이 할 어렵습니다.


0

당신이 찾고있는 것은 문제 해결 능력 입니다. 개발자가 이미이 작업을 수행 할 수 있다고 가정합니다. 운 좋게도 문제 해결은 수학, 연구, 일상 생활 등에 사용되는 일반적인 기술입니다.

기본적으로 과학적인 방법을 따라야하며 약간의 주름이 생깁니다.

  1. 문제가 있습니다 (도구 및 기술을 사용하여이를 정의하는 데 도움이 됨)
  2. 솔루션을 가정합니다 (패턴 및 경험 도움말).
  3. 가설 검정 (여기에는 코드가 없을 수도 있음)
  4. 가설이 유지 될 때까지 2 단계와 3 단계를 반복하십시오. 이제 이론이 있습니다 (문제를 해결하기위한 작업 프로그램)
  5. 이론을 강조하고 구멍을 찾는 실험을 개발하십시오 (테스트 사례!)
  6. 테스트 케이스가 유지되면 해결책이 있습니다! 그렇지 않으면 헹구고 반복하십시오

이것은 다소 높은 수준입니다. 각 단계에는 일반적으로 문제가 실제로 무엇인지 확인하는 등 몇 가지 하위 단계가 포함됩니다. 예를 들어 수학에서 단어 문제 해결을 살펴보십시오. 사실 (도구)을 수집하고 실제로 원하는 것을 결정합니다. 그런 다음 사실을 조사하여 솔루션에 맵핑하려고합니다.

결국 1 차 문제의 하위 문제가됩니다. 따라서 단계를 다시 수행하십시오. 최종 결과를 얻으려면 중간 항목이 필요하므로 새로운 문제가됩니다. 이것은 문제를 작고 이해하기 쉬운 섹션으로 분해 합니다. 각 조각이 해결되면 솔루션이 함께 조각됩니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.