대학생과 함께 개발 프로세스를 구현하는 방법


9

소프트웨어 개발자로서의 첫 직장에서, 팀은 애자일 / 스크럼을 사용하여 프로젝트 워크 플로우를 관리했으며 꽤 잘 작동했습니다. 나는 경험이 풍부한 멘토들이 나를 올바른 길로 안내했다 – 나는 그들에게 큰 감사의 빚을졌다. 나는 몇 년 동안 그곳에서 일한 후 몇 달 전에 새로운 기회로 옮겨갔습니다.

내 현재 직업으로 빨리 감기. 저는 교수의 지시에 따라 대학에서 일합니다. 제가 대학에 다니기 때문에 거의 모든 프로그래머가 학생입니다. (싸고 풍부합니다!) 제 상사는 경영 경험이 있지만 소프트웨어 개발이 아니라 소프트웨어 팀이 항상 상사의 마음의 최전방에있는 것은 아닙니다 . 이러한 조건은 품질이 매우 낮은 소프트웨어 를 작성하기위한 완벽한 환경을 만들었습니다 . 소프트웨어 프로젝트는 약간 불량한 것으로 보이며, 디자인 할 생각이없고, 정말 무서운 관행을 채택했습니다. 일이 더 나을 수 있다는 것을 알고 있습니다.

모든 사람을 추적하고 코드 품질을 높이며보다 안정적인 소프트웨어를 배포 할 수 있도록 개발 프로세스를 구현하고 싶습니다. 어디서부터 시작해야할지 모르겠습니다.

아니야 "민첩 한 번 봐!" "집합 간판 보드까지", "사용 스크럼"와 같은 답을 말하자면 당, 찾고, 또는 (아이디어는 높이 평가되지만). 보다 구체적 으로이 작업 환경에 대한 개발 프로세스 를 구현 하는 방법에 대한 통찰력을 얻고 자 합니다. 직원들은 일반적으로 1 년에서 2 년 사이에 일을하고 일반적으로 경험이 없으며, 모든 사람을 포함하는 일일 스탠드 업 회의는 거의 불가능합니다.

그러한 직장에서 품질, 효율성 및 의사 소통을 어떻게 촉진합니까?

업데이트 : 답변과 의견을 읽은 후에 추가 배경을 제공 할 것이라고 생각했습니다.

나 자신 소프트웨어 개발의 예술에서 마스터 고려하지 않을 것입니다,하지만 나는 내가 그것을 볼 때 나쁜 프로그래밍을 인식하기에 충분 경험. 1 ~ 2 분 정도 작업 한 후 개발자가 재능이 있는지 판단 할 수 있습니다. 문제를 해결할 수있는 방법을 찾을 수있는 내 능력에 익숙합니다 현명하게 하지만, 실제로 경험이 부족한 영역은 다른 개발자가 참여하는 프로젝트 관리입니다. 조언).

나는이 사무실에 들어온 모든 학생들이 완전히 어리석은 것처럼 들렸다. 여기에 나쁜 계란이 있었지만 내가 만난 대부분의 학생들은 지능적이고 배우고 싶어하며 일에 열정적입니다. 일부는 막 시작했지만, 자신이 모르는 것을 모른다. 그리고 괜찮습니다. 처음 프로그래밍을 시작했을 때 나는 더 나아지지 않았습니다!


개발자는 자신의 QA를 담당합니까?
svidgen

프로젝트가 시작되면 개발자에게 일련의 요구 사항이 주어지며, 그 시점부터 모든 것이 그들에게 달려 있습니다. 따라서 개발자들이 자신의 Q & A에 책임이 있는지 묻는 것은 아이에게 총을주는 것과 아이가 무기를 안전하게 취급 할 책임이 있는지 묻는 것과 같습니다.
darksinge

그래서 우리가 시간제 학생 개발자 팀에 대해 이야기하고 있다고 생각합니까? 그리고 너? ... 팀의 정규직 또는 선임 개발자 (> = 10 년 경력) ?
svidgen

원격으로 일하는 두 명의 풀 타임 개발자가 있지만 우리는 그것들을 많이 보지 못합니다. 사무실에서는 예, 직원은 모두 아르바이트 학생입니다. 현재 풀 타임으로 일하고 있지만 곧 석사 프로그램을 시작하면 변경 될 수 있습니다.) 5 년의 경험이 있지만 많은 프로젝트 관리 경험이 없습니다.
darksinge

아직 정식 답변을 할 시간이 없었습니다. 그러나 고려할 사항은 약 20 년 동안 코드를 작성해 온 것입니다. 다른 고위급 직원들 사이에서 전문적인 환경에서 최소 10 년. 숙련 된 소프트웨어 개발자들이 "좋은"코드와 "나쁜"코드라고 부르는 다양성은 방대 합니다. 좋은 첫 번째 단계는 실험이 장려되는 경계를 제공 할 수있는 방법으로 코드 "좋은"또는 "나쁜"무엇이 분명히 말하는 수 있습니다, 창의성과 혁신을 보상하고, 당신의 경험과 의견을 가치로 인정하지만, 궁극적으로되어 제한 .
svidgen

답변:


4

사전 검사보다 실수를 정리하는 데 시간이 더 걸립니다.숙련되지 않았거나 실무를 잘 모르는 개발자를 다루는 경우 경험이있는 사람이 코드를 볼 때까지 (마스터) 코드베이스를 변경할 수 없어야합니다.

방법론에 대한 설명을 원하지 않았으므로 그 부분에 대해 살펴 보자. 민첩한 작업을 사용하여 독립적으로 개발할 수있는 다양한 기능을 설정하십시오.

모든 사람이 별도의 지점에서 작업 할 수 있도록 기능 지점을 사용하십시오. 작업이 완료되면 개발자는 코드를 마스터 분기에 병합 할 수 없습니다. Git을 사용하는 경우에도 풀 요청을 시작할 수 있습니다. 그렇지 않으면 멋진 작업을 완료하는 작업 (/ 지점)을 추적하는 방법을 사용하십시오.

그런 다음 검토 프로세스를 수행 합니다. 당신이 의문의 여지가 조금 모호한 것은 학생들보다 판단을 신뢰할 수있는 경험있는 개발자가 있는지 여부입니다. 따라서 어느 쪽이든 자세하게 설명하겠습니다.

숙련 된 개발자가있는 경우 완료된 작업 코드를 검토하여 작업을 수행하십시오. 좋은 경우 마스터 분기에 병합 할 수 있습니다. 그렇지 않은 경우 스스로 리팩터링하거나 개선해야 할 사항에 대한 피드백을 개발자에게 제공 할 수 있습니다.

숙련 된 개발자가없는 경우 항상 문제가 발생합니다. 잘못된 코드에서 좋은 코드를 발견 할 사람이 없으면 코드 품질을 유지할 수 없습니다.
할 수있는 최선의 방법은 개발자 들이 다른 개발자들 앞에서 자신의 구현을 발표하고 설명 하는 검토 회의 입니다. 모든 문제를 예방한다고 보장 할 수는 없지만 (예 : 모든 개발자가 모범 사례에 대해 동일한 오해를 가지고있는 경우에도) 대부분의 문제를 방지합니다 (예 : 적어도 한 명의 개발자가 올바른 아이디어를 가지고 설명 할 수있는 경우 또는 문제가 발생한 경우) 서로 다르게 문제를 이해하는 개발자로부터)

그러한 직장에서 품질, 효율성 및 의사 소통을 어떻게 촉진합니까?

  • 품질 -숙련 된 개발자가 작성한 코드를 검토하십시오. 숙련 된 개발자가없는 경우 최소한 가능한 한 최선의 기반을 다룰 수 있도록 그룹 리뷰를 작성하십시오.
  • 효율성 -독립적 인 작업을 올바르게 설정하면 서로 기다리는 사람들을 최소화 할 수 있습니다. 모든 사람을 동시에 사용할 수없는 환경에서는 많은 "사람 A를 기다리는"지연을 처리한다고 가정합니다. 진전이없는 개발자에 대한 후속 조치만으로도 도움이 필요한지 확인하거나 좌절감을 방치 할 수 있습니다 (이 좌절은 피할 수있는 문제에 대한 오해를 나타낼 수 있음).
  • 의사 소통 -개발자가 도움, 피드백 또는 영감을 요청할 수 있도록 개방형 정책을 설정하십시오. 자격을 갖춘 멘토가없는 경우 팀 상호 작용을 촉진하십시오 (물론 멘토가있는 경우에도이 작업을 수행 할 수 있지만 멘토가 없으면 그렇게하는 것이 중요합니다). 특히 사람들이 원격으로 일정이 다른 상황에서 작업하는 상황에서 개발자는 종종 동료와 가깝지 않고 의사 소통을하지 않는 경향이 있습니다. 소수의 사교 모임조차도 다른 시간에 업무 관련 의사 소통을 향상시키는 데 놀라운 일을 할 수 있습니다.

좋은 답변이 있었지만 이것은 가장 철저하고 직접적인 감사였습니다!
darksinge

1
이것은 가깝지만 꽤 있지는 않습니다. 나는 코드 검토에 동의하지만 숙련 된 개발자가 수정을 수행하는 것에 열정적으로 동의하지 않습니다. 리뷰를 원래 코더로 다시 보내서 작업을 수행하는 것이 훨씬 좋습니다. 이는 더 나은 코딩 방법을 가르치는 목표를 달성하지만 소프트웨어를 수용 가능한 표준으로 생산할 때까지 재 작업 과정에서 느슨해 진 코더를 느리게하는 이점도 있습니다.
mcottle

@mcottle 당신은 내가 한 적이없는 요점을 반대합니다. 리팩토링은 고정과 다릅니다. 코드가 작동하지 않으면 말한대로 다시 보내야합니다. 문제가 사소한 문체 론적 주장 인 경우에도 개발자에게 다시 전달하는 것이 중요하지만, 자세히 설명하지 않고 수정하기가 더 쉬운 경우가 있습니다. 그것은 당신이 deceloper에게 개선 된 코드를 보여 주어 그들이 무엇을 의미하는지 볼 수 있다는 이점이 있습니다.
Flater

8

사람들이 새롭고 떠날 가능성이있는 환경에서 가장 큰 것은 필수 코드 검토입니다.

그들은해야 할 일에 대한 지식을 전파하는 데 도움이됩니다. 최악의 코드가 코드베이스에 들어가는 것을 방지합니다. 그들은 구현의 일관성을 촉진합니다.

많은 이직률과 경험이 없기 때문에 의사 소통 이 평소보다 더 중요합니다.


2
나는 실제로 이것에 대해 약간 회의적입니다. 나는 코드 검토가 필요하다는 것에 동의하지 않습니다 ... 그러나 당신은 OP가 모든 것을 검토하고 의견을 남길 시간이 있다고 생각하지 않는 한 다른 단서가없는 개발자들 로부터 피드백을 요청하는 많은 단서가없는 개발자에 대해 이야기하고 있습니다 . .. 내말은. 어쩌면 그렇게 많이 가져 오지 않았을 수도 있습니다. 유입에 따라 다릅니다. 그러나 "코드 리뷰"는 솔루션의 4 분의 1 이상인 것처럼 보이지 않습니다. 내 말은, 최고의.
svidgen

@ svidgen : 다른 단서가없는 개발자의 리뷰를 옹호하지 않았다고 생각합니다. 그는 명시 적으로 명시하지 않았으므로 어느 쪽이든 갈 수는 있지만 경험에 따르면 경험이 풍부한 동료 또는 체인에있는 사람들 (리드 개발자), 특히 개발자의 적성 중 일부가 드물거나 입증되지 않은.
Flater

1
@ svidgen-처음에는 리드가 수행해야 할 수도 있지만 보트로드 또는 단서가없는 개발자가 문제입니다. 당신은 단서가 아닌 것을 만들지 않으면 그것을 해결할 수 없습니다. 이상적으로는 그것을 얻는 몇 명의 개발자가있을 것이고 덜 중요한 것들에 대해 코드 검토를 수행하는 데 도움을 줄 수 있습니다.
Telastyn

2

솔루션보다는 아이디어가 많지만 학생 개발자가 수행 할 수있는 프로젝트와 유사한 기능과 요소를 포함하는 코드베이스의 중요한 섹션을 찾아서 잘 정리하십시오. 새로운 개발자의 큰 문제 중 하나는 코드베이스의 규범과 규칙을 알지 못한다는 것입니다. 또한 다른 코드를 조사하여 자체 설정 방법에 대한 아이디어를 얻습니다. 지저분한 코드베이스에서 일하는 많은 새로운 개발자가 있다는 것은 그들이 혼란을보고 그것이 수용 가능하거나 최선의 방법이라고 생각할 것임을 의미합니다. 그런 다음 나쁜 관행은 고 이동 환경에서도 영속됩니다.

최소한 하나의 깔끔하고 잘 작성된 코드 섹션 (또는 하나의 파일) 만 있으면 학생 개발자에게이를 모범 사례의 예로 사용하도록 지시 할 수 있습니다. 그들과 비슷한 코드를 작성할 수 있다면 매우 기뻐할 것이며 다른 코드의 대부분은 올바른 방법으로 수행 할 수있는 좋은 예가 아닐 수도 있습니다.

특정 방식으로 수행 된 이유에 대한 설명과 함께 주석 또는 기타 문서를 추가하면 새로운 개발자가 더 나은 코드를 통해 더 빠르게 속도를 높일 수 있습니다.


2

지속적인 통합 -

팀 도구, 기술 및 프로세스의 점진적이고 유연한 구현을위한 실용적이고 개념적 프레임 워크입니다.

CI는 코드 작성에서 배포까지의 작업 흐름에 대한 아이디어입니다. 이러한 작업은 개념적으로 실제로 독립적입니다.

CI는 특히 자동화입니다. 이것은 화면에 코드가 입력되는 시점부터 품질과 생산성에 중대한 영향을 미칩니다.

  • CI 작업 구현은 독립적으로, 상세하고 동시에 해결 될 수 있습니다. 필요에 따라 초점이 바뀔 수 있습니다.
  • 수프-너트 CI 도구를 도입하지 마십시오
    • 모두 프로세스에 의해 산만 해지며 캡슐화 된 작업 기술을 희게하는 경향이 있습니다.
  • 벅으로 물건을 소개합니다.
  • 풀 타임 변경 에이전트가 될 것으로 예상됩니다. 지도자가 되십시오. 관리자뿐만 아니라 선임 코더 만이 아닙니다.

  • 전략적

    • CI의 성배는 배포 자동화를위한 실습입니다. 그들은 그것을 만질 수 없다면 그것을 맛볼 수 없습니다.
    • 교육 및 훈련 자료.
      • 문서 프로세스.
      • 프로그래머 매뉴얼 작성 유기적으로 발전 시키십시오.
      • 필수.
      • 탐색은 특정 기술과 코드 기반 자체를 대상으로합니다.
    • 다음과 같은 전문 프로그래머 가치를 주입하십시오.
      • TDD는 절대적으로 품질을 만듭니다
      • 코드 검토에는 주석, 주석 처리 된 코드, 단위 테스트 등 모든 아티팩트가 포함됩니다.
      • "얼마나 많은 버그가 발견 되었는가에 부끄럽다"
      • 객관성은 개인 코드 소유권의 의미와 소유자를 "불쾌하게"한다는 두려움에 의해 방해받지 않습니다.
  • 전술적이다

    • 이산 CI 작업 자체는 자동화 될 수 있습니다 (예 : 컴파일 및 단위 테스트를 트리거하는 버전 제어 커밋).
    • 코드 형식과 같은 자동화 적용 규칙.
      • 너무 많은 농작물을 조심하십시오. 도구가 무시되기 시작합니다. 압도적이지 않도록 규칙 적용을 조정하십시오.
    • 즉시 테스트 주도 개발 구현
    • 각 변경의 우선 순위를 정하고 강조
      • 주요 지식과 기술 도약이 단순히 발생한다고 가정하지 마십시오.
    • 긴급 성이 적절한 이행을 방해하는 것을 허용하지 마십시오
    • 변화를 주도하고
      • 새로운 남자 오리엔테이션과 약간의 훈련이 필요합니다.
      • 새로운 것들에 대한 명백한 훈련과 명확한 안내
      • 최소한 최소한의 명목상의 표준까지 훈련하십시오. 공식적인 형식 일 필요는 없지만 YouTube를 무작위로 걸어 보는 것은 훈련이 아닙니다. 개인적으로 확인하십시오-다시 공식 성을 피하십시오.
    • 코드 검토자가되어 모든 코드를 검토하십시오.
      • 어려운 버그 수정을 명시 적으로 안내하고 주목할만한 학습 경험을 공유하십시오.
    • 견고한 유연성. 죄송합니다. 그러나 사실이다.
  • 문화 만들기
    • 전문적인 기대를 가지고
    • 도구 표준화
    • 생산 지표에 대한 학습 강조
    • 멘토되기
    • 변화를 도입 할 때, 단순히 개인의 이니셔티브에 따라 "그렇게 만들기"는 팀 개발을 미묘하게 파괴합니다. 응집력있는 팀의 정체성에는 도구, 지식 및 기술 수준이라는 공통점이 포함됩니다. 상호 존중은 각 구성원이 이러한 가치를 가치있는 가치로 받아들이는 정도로 커집니다. 팀 리더는 모델이며 피할 수 없습니다. "무엇이든"태도와 기대를 모델링하지 마십시오.

품질로가는 길

  • 단위 테스트

    • 주도적 개발 테스트의 열쇠
      • 그것에 관한 전체 책을 읽을 필요는 없습니다
      • 이것은이되어야 코딩 패러다임
      • 리더로서 당신은 모두가 "단위 테스트가 믿음의 도약"을 만들 때까지 지켜야합니다. 그 패러다임 전환은 "코드를 두 번 쓰고 있어요!" 뛰어난 생산성을 수용합니다.
    • 당점에서는 단위 테스트가 필수적이었습니다. 그러나 많은 사람들은 원하지 않기 때문에 그렇게하지 않았습니다. 경영진의 신념 부족은 단위 테스트가 실제로 작동하지 않는다는 메시지를 보냈습니다.
  • 버전 관리

    • 나는 이것을 먼저 넣었지만 단위 테스트는 시작하기가 더 쉽다.
    • 버전 관리가 쉽지 않기 때문에 다른 이니셔티브를 지연시키지 마십시오
    • 버전 관리 계획을 세우십시오.
      • 적어 두어야합니다.
      • "간선에 모든 것을 뿌리고 가지를 뿌리지 않는 것"처럼 간단하더라도이를 수행하십시오.
  • 코드 리뷰

    • 이것은 코드 품질을 자세히 향상시킬 수있는 가장 큰 잠재력을 가지고 있습니다.
    • 2 개의 검토 프로세스를 사용하십시오.
      • 나는 2 차 리뷰가 얼마나 많은 버그를 발견했는지 매우 놀랐습니다.
      • 신뢰하지만 확인하십시오. 코드를 실행하십시오. 왜 이런 말을해야합니까? 바로 위를 참조하십시오.
      • 처음에 당신은 유일한 검토자가 될 것입니다. "라이브"를 검토하도록 팀에 요청하십시오. 그들은 다르게 생각하는 법을 결코 배우지 못할 것입니다.
      • 곧 당신은 두 번째 검토자가 될 것입니다. 개별 기술 영장에 따라 검토를 받아야합니다. 결국 두 검토 자. 물론 예외없이 항상 코드를 살펴볼 것입니다.
  • 리팩토링

    • 이것은 분명하고 공식적인 훈련입니다.
    • 리팩토링 : 기존 코드의 디자인 개선 Martin Fowler
      • 버그 프리 코드 변경을 보장하는 체계화 된 리팩토링 레시피.
      • 이 책으로 전문 도서관을 시작하십시오.
    • 형식은 제쳐두고 코드 검토를 통해 임시로 소개합니다.
  • 환경을 포착하십시오

    • 기본 도구 구성 : 버전 제어, IDE, CI 도구, OS 등
    • 소스 코드, 문서, 구성은 버전 관리에서 동기화되어야합니다.

프로세스에 관한 단어

애자일 (및 스크럼과 같은 하위 장르) : 잊어 버리십시오. "당신은 민첩하고 민첩하지 않습니다." Agile Manifesto 의 최초 서명자 중 한 명인 Dave Thomas의 이것들을보십시오 .

작고 경험이 부족한 팀이 주어지면 Visual Studio Team Services와 같은 팀 통합 도구를 볼 때 내 욕심이 사라집니다. 내 경험은 여기에 제한되어 있지만 성 가시고, 불필요한, 엄격한 프로세스 부과를 느낍니다. 많은 사람들이 이러한 것들을 효과적으로 사용하지만 문제를 찾고있는 솔루션을 구매할 가능성이 있음을 알고 있습니다.


도구에 관한 한마디

나만. 클릭 미끼 허니팟은 "지금 최고의 소프트웨어 툴 ..."이 아닙니다.

젠킨스

CI 통합 도구. 웹 기반으로 널리 사용됩니다. 기본적으로 웹 GUI를 통해 컴파일, 단위 테스트 실행, 버전 제어 업데이트와 같은 다양한 작업 및 실행 순서를 사용자 지정 구성 및 자동화 할 수 있습니다. 매우 A-La Carte이므로 초기 CI 환경에 적합합니다.

버전 관리

나는 Git보다 Mercurial을 선호한다. 이 블로그 게시물은 내가 원래 Mercurial을 선택한 이유입니다. Git은 MacGyver이고 Mercurial은 James Bond입니다.

Subversion이 좋습니다. Mercurial & Git은 Subversion보다 뛰어난 아키텍처를 가지고 있습니다.

통합 개발 환경

모든 사람이 다른 코딩 도구를 사용하는 경우 고려해야 할 사항은 다음과 같습니다. 일반 텍스트와 같은 것은 없습니다


전문 도서관에 관한 말씀

인터넷은 넓고 얕으며 조직이 불안정합니다.

  • Steve McConnell의 코드 완성
    • 모두가 중간 3 분의 1을 읽게하십시오.
    • 제안 된 전문 도서의 부록이 있습니다.
  • 리팩토링 : 기존 코드의 디자인 개선
    • 버그 프리 코드 변경을 보장하는 체계화 된 리팩토링 레시피.
  • 소프트웨어 오류. 구체적인 권장 사항은 없지만 논문에 대한 이야기 ​​여야합니다.

0

회의 일정을 잡는 것이 불가능하기 때문에 다른 방법론을 사용하여 프로세스를 관리하는 것이 좋습니다 (스크럼에 절대적으로 중요합니다!). 좋은 개념을 만드는 것은 여전히 ​​나쁘지 않습니다. 그래서 모두가 진행중인 일을 알고있을 것입니다 (아마도 vert 프로토 타입을 사용하고 있음). 폭포 모델을 사용하십시오. 어느 쪽이든, 커뮤니케이션은 작업의 가장 큰 부분입니다.


1
vert 프로토 타입은 무엇입니까; 대답을 확장하는 것이 더 간결합니다.
esoterik

죄송합니다. 오늘 아침에 시간이 거의 없었습니다. 첫째, [수직 프로토 타입] (tutorialspoint.com/sdlc/sdlc_software_prototyping.htm)은 프로토 타입의 한 유형이므로 기능을 구현하지 않고도 소프트웨어를 완벽하게 구축 할 수 있습니다. 장점은 가정 된 고객이 제품의 모습을 볼 수 있다는 것입니다. 둘째, 개발자에게 기능에 "필요한"/ 제공해야하는 데이터에 대한 좋은 느낌을줍니다.
gkhaos

"더 간결하다"는 무슨 뜻입니까? 프로젝트 관리 유형은 프로젝트의 내용과 같은 다양한 요소에 의존하기 때문에 결정하기가 어렵습니다. 당신의 팀은 얼마나 큽니까? 또한 예를 들어 스크럼에서는 스크럼에 대해 깊이 알고 있어야하는 스크럼 마스터가 필요합니다. 방금 스크럼이 프로젝트 관리에 대한 유일한 대답은 아니라고 생각했습니다.
gkhaos

0

아직 소스 컨트롤을 사용하지 않는 것이 좋습니다. 이를 통해 각 개발자가 체크인 한 내용을보고 버그가 발생한 위치를 회귀 할 수 있습니다.

일종의 테스트 스위트를 설정했습니다. 커밋하는 각 함수에 대한 테스트를 작성하는 테스트 중심 개발이거나 애플리케이션을 실행하고 원하는 결과와 비교할 수있는 파일로 결과를 출력하는 자동화 된 방법 일 수 있습니다 산출. 매 커밋 후에 실행되거나 적어도 하루에 한 번 실행되면 회귀를 빠르게 찾을 수 있습니다.

마지막으로 2 가지 정책을 구현해야합니다 .1) 모든 빌드에는 경고가 오류로 설정되어 있고 모든 오류가 켜져 있어야합니다 .2) 모든 코드는 커밋되기 전에 오류 또는 경고를 생성하지 않고 정적 분석기를 거쳐야합니다. 나는 이것을 사전 커밋 행동으로 만들 것입니다. 이 두 가지로 인해 코드가 여러 가지 일반적인 방식으로 빠르게 끔찍 해지는 것을 막을 수 있습니다. (그들은 모든 것을 잡는 것은 아니지만 많이 잡습니다.)

이것은 학생들이 "실제 세계"에서 어떤 일이 될지 준비하고 그들에게 합당한 좋은 습관을 심어줄 것입니다.

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