유지 보수성과 관련하여 학생들의 교육을 향상시키는 방법은 무엇입니까? [닫은]

유지 관리 성은 전문 소프트웨어 개발의 주요 지분입니다. 실제로, 유지 보수는 거의 항상 소프트웨어 수명주기의 가장 긴 부분입니다. 프로젝트 릴리스부터 기본적으로 끝까지 지속됩니다.

또한 유지 보수중인 프로젝트는 전체 프로젝트 수의 대부분을 차지합니다. http://www.vlegaci.com/298/interesting-statistics-%E2%80%93-numbers-of-programmers-in-maintenance-vs-development/ 에 따르면 유지 관리중인 프로젝트의 비율은 약 2입니다. /삼.

나는 최근 에이 질문 을 보았습니다. 그 사람은 그의 직업이 주로 유지 보수에 관한 것임을 알게되어 놀랐습니다. 그런 다음 프랑스 소프트웨어 개발 전문가 커뮤니티 ( http://www.developpez.com/ ) 의 기본 사이트에서 토론 (프랑스어) 을 열기로 결정했습니다 . 토론은 "학생들이 전문 소프트웨어 개발의 현실에 대해 충분한 훈련을 받았습니까?" 주로 유지 관리 에 관한 것 입니다. 적어도 프랑스에서는 사람들이 두 가지 측면에서 유지 보수에 직면하기에 충분히 준비가되어 있지 않다는 것이 지적되었습니다.

• 기존 코드 유지
• 유지 보수 가능한 코드를 만들다

여기에서의 나의 질문은이 논의를 반영하고 유지 보수성을 가르치는 좋은 방법을 찾는 것을 목표로합니다.

• 유지 관리 성을 어떻게 가르 칠 수 있습니까?
• 어떤 종류의 운동을 제안 하시겠습니까?
• 유지 보수성에 대해 잘 훈련 된 경우 어떤 종류의 과정을 수강 했습니까?

[편집] 약간의 오해 후에, 나는 나의 질문을 명확히해야한다고 생각합니다. 프로젝트 리더이자 소프트웨어 개발자 인 저는 연수생이나 신입생과 함께 일하는 경우가 많습니다. 나는 한 번 새로 졸업했다. 문제는 학생들이 일반적으로 프로젝트의 유지 관리 성을 향상시키는 SOLID와 같은 원칙에 익숙하지 않다는 것입니다. 우리는 종종 프로젝트를 발전시키는 데 어려움을 겪습니다 (유지 보수성이 낮음). 여기서 찾고있는 것은 유지 관리의 중요성과이 특정 요점에 대해 더 나은 코드를 만드는 방법에 대한 성공적인 교육의 구체적인 학문적 예입니다. 또는 학생들의 훈련 방법을 향상시키기위한 가능한 제안.

유지 관리 성을 어떻게 가르 칠 수 있습니까?

그것은 연습 문제입니다.

내가 생각할 수 있는 통제 된 방식으로 연습하는 가장 간단한 방법은 다음과 같이 일반적인 유지 보수 프로젝트 를 시뮬레이션하는 것입니다 .

잘 수행 된 프로젝트 ( Project A )를 가져 와서 몇 가지 문제를 소개하십시오 : 버그 삽입, 복제 및 죽은 코드의 좋은 도즈, 일부 기능 삭제, 단위 테스트 및 문서 등 여기저기서 Project A- 손상 버전 과 같은 이름 .

수립 이슈 트래커를 하고 당신이 만든 특정 손해에 해당 요청을 입력합니다. VCS 커밋, 코드 검토, QA 등 개발 프로세스에 대한 기본 규칙 및 실습을 설정 합니다. Joel 테스트에 제공된 점검 목록에서 수행 할 수있는 작업을 고려하십시오 .

• 과정 1.
  버그를 수정하고 누락 된 단위 테스트, 문서 및 기능을 추가합니다.
• 코스워크 2.
  리팩터링.
• 교과 과정 3.
  내년 학생들이 사용할 원래 프로젝트의 유지 보수 / 개선
  -각각 프로젝트 A 버전 2.0 및 프로젝트 A-손상된 버전 2.0 . _{손상된 버전
  을 개선함으로써 교육적 손상을 개선 할 수 있습니다. :)}

위에서 언급 한 관행 중 코드 검토 관행에 특별한주의를 기울이십시오 . 예를 들어 관련 질문 에 대한 최상위 답변에서 알 수 있듯이 코드를 쉽게 유지 관리 할 수있는 가장 효과적인 방법 일 것 입니다.

면책 조항 : 방금 CS 학위를 받았습니다. 저는 선생님이 아닙니다.

이것은 분명히 들릴지 모르지만 코드 유지 관리를 가르치는 가장 좋은 방법은 학생들이 코드 유지 관리를 수행하는 것입니다. 내가 할 일은 다음과 같습니다.

1. 약간 복잡한 문제와 의미 적으로 동일한 두 가지 구현을 사용하지만 하나는 다른 것보다 유지 관리가 훨씬 쉽습니다.
2. 더 나은 코드 기반에서 구현하기가 훨씬 쉬운 여러 가지 변경 / 기능 추가를 요청하십시오. 학생들의 절반이 유지 관리가 용이 ​​한 코드 기반으로 구현하고 나머지 절반은 유지 관리가 쉽지 않은 코드 기반으로 구현해야합니다.
3. 공정성을 위해 역할을 반대로하여이 연습을 반복 할 수 있습니다.
4. 좋은 코드베이스와 나쁜 코드베이스 사이에 성공적으로 구현 된 평균 변경 횟수와이를 구현하는 데 소요 된 시간을 비교하십시오. 학생들에게 자신의 경험을 나누고 불만을 표현하며 일반적으로 자신이 한 일에 대해 이야기하게하십시오.

아이디어는 학생들이 다른 사람의 코드로 작업하게 할뿐만 아니라 설계 기술을 향상시킬 수있는 유지 관리 가능한 코드에 대한 감사를 개발하도록하는 것입니다.

유지 보수는 기술이 아닌 미덕입니다. 유지 관리 가능한 프로젝트를 만드는 데는 여러 가지 방법이 있지만 그 중 하나를 보장 할 수있는 공식은 없습니다.

친절과 관대함과 같은 미덕을 소중히 여긴다면, 일상 생활에서 똑같이 실천할 수있는 방법을 찾으십시오. 유지 관리 기능과 동일합니다. 유지 관리 효율성을 높이 평가하는 경우 프로젝트를 설계 및 구현하는 동안이를 유지 관리해야합니다. 유지 관리가 중요하다는 것을 알고 있기 때문에 약간의 추가 시간을 투자하여 합법적 인 이유가 될 것입니다. 반대로, 가치가없는 조직에서 유지 관리를 위해 추가 시간을 소비하는 것은 권장되지 않습니다.

사람들에게 유지 관리 할 수 ​​있도록 지시하려면 조직에서 유지 관리 성을 중요하게 생각해야합니다. 프로젝트 요구 사항에 지정하십시오. 성공적인 코드 검토의 기준 중 하나로 만드십시오. 요컨대, 유지 관리 성을 문화의 일부로 만드십시오 .

다음으로 기존 프로젝트의 유지 관리 성을 개선하기 위해 몇 가지 리소스를 기꺼이 바칩니다. 버그가 계속 발생하거나 버그를 수정하거나 변경하기가 매우 어렵고 시간이 오래 걸리는 프로젝트 부분을 파악하고 유지 보수를 용이하게하기 위해 재 설계 또는 리팩토링하십시오.

마지막으로, 새로운 개발자를 매일 매일 연습하는 팀에 할당하여 유지 관리 문화에 익숙해 지십시오 . 좋은 예와 지침을 충분히 제공하는 것보다 누군가가 가치를 채택하도록 돕는 더 좋은 방법은 없습니다.

소프트웨어 개발과 관련하여 유지 관리 가능 이라는 용어를 싫어합니다 . 실제로 모든 소프트웨어는 유지 관리 작업을 수행 할 수 있다는 점에서 유지 관리가 가능하므로 실제 문제는 소프트웨어의 유지 관리 비용이 비싸거나 상대적으로 비싸지 않은지 여부입니다. 나는 이것이 대답의 시작 부분에 매우 간단한 진술처럼 들리지만 내 요점은 곧 명확해질 것입니다.

소프트웨어 개발을 전공하는 IT 학위의 문제점은 학생들이 소프트웨어 작성에 대해 알아야 할 최소한의 학생들에게만 가르치는 것입니다. 전문 기술과 지식은 학습 후 첫 몇 년 동안 이루어진 학습을 통해 습득됩니다학위 자격. 졸업생은 실제로 수행해야 할 압력이 큰 환경에서 실제로 고객에게 중요한 프로젝트를 수행하기 시작하고 전문가 표준에 따라 제품을 만드는 것이 기대됩니다. 안타깝게도 많은 회사는 소프트웨어의 전문 표준이 유지되는 문화를 장려하지 않으며 결과적으로 개발 및 유지 관리 비용이 많이 드는 프로젝트로 끝납니다. 불행히도 우리 졸업생에게는 경력 초기에 그러한 환경에서 많은 나쁜 습관을 습득하며, 이러한 습관을 극복하는 방법을 배우기까지는 오랜 시간이 걸릴 수 있습니다.

깨끗한 코드를 작성하는 방법과 일반적으로 기술 부채가 발생하는 소프트웨어의 문제를 식별하는 방법을 학생들에게 가르치는 것이 좋습니다 . Clean Code , Refactoring , Lean Software Development 에 대한 책 을 시작하기위한 출발점으로보고, 학생들에게 높은 수준의 테스트 범위를 보장하기 위해 구현 코드 전에 단위 테스트를 작성하도록 가르치십시오. 학생들에게 코드 내에서 반복적이고 반복적 인 패턴을 인식하고 그러한 중복을 제거하기 위해 코드를 리팩토링하는 방법을 가르치십시오. 학생들이 SOLID 및 DRY 와 같은 원리를 이해하고 적용하도록 지원. 가장 중요한 것은 코드를 유지하는 능력은 코드의 설계 및 구현에 기초하여 수행되는 것이 아니라 처음부터 소프트웨어를 제작할 때 장인 정신과 품질에 대한 감각을 심어주는 것입니다. 기술 부채의 영향을 최소화하고 시간이 지남에 따라 소프트웨어 유지 관리 비용을 최소로 유지하기 위해 코드가 구현 될 때 코드를 수정하십시오.

이러한 종류의 기술을 배우는 가장 좋은 방법은 코드 검토 및 페어 프로그래밍을 수행하는 것입니다. 코드를 검토하는 동안 숙련 된 직원은 코드를보다 쉽게 ​​유지 관리하는 방법 (일반적으로 코드를 더 읽기 쉽게 만드는 방법)을 지적하고 특정 선택 사항이 유지 관리하기 쉬운 코드를 생성 할 수있는 이유를 정당화 할 수 있습니다.

페어 프로그래밍은 이런 종류의 것을 가르치는 더 좋은 방법입니다. 경험이 적은 직원이 코드를 잘 알고있는 사람과 코드를 유지하는 데 직접적인 경험을 제공하기 때문입니다.

깨끗하고 유지 관리 가능한 코드 작성에 관해 읽을 수있는 훌륭한 책들도 있습니다. 클린 코드 가 떠 오릅니다.

학생들이 큰 코드 기반을 거의 수정하지 않기 때문에 학계를 통해 이러한 경험을 얻는 것은 어렵습니다. 이러한 기술의 대부분은 직업 학습에서 비롯되며 코드 검토 및 페어 프로그래밍은 실제로 이러한 학습을 ​​촉진 할 수 있습니다.

좋은 코드 = 유지 보수가 적고 기능을 강화 / 추가하기 쉽습니다.

잘못된 코드 = 유지 보수 악몽

기본적으로 우리는 학생들에게 "프로젝트에 엉터리 코드가있을 때마다 코드의 원래 작성자가 어려움을 겪고 소프트웨어에 미치는 영향으로 인해 회사에 합류 할 새로운 개발자라는 점을 지적해야합니다. "

따라서 소프트웨어 유지 관리에 대해 학생에게 가르치는 가장 좋은 방법 중 하나는 좋은 코드와 잘못된 코드의 예를 보여주고 기능을 추가하도록 요청한 다음 좋은 코드를 작성하는 것은 자기 만족을 위해서만하는 것이 아니라 만드는 것입니다 코드를 유지하려는 사람들에게는 쉽습니다.

운동:

1) 사전 작성된 불량 코드 (예 : 중복 코드)가있는 경우 "모기지 상환 계산"이라는 방법 이 프로젝트의 9 개 장소 에 작성 됩니다 .

학생에게 "모든 모기지 지불금에 1.2 % 추가 요금을 부과"하는 기능을 향상 시키도록 요청하십시오.

이제 학생은 9 개 위치 모두에서 코드를 찾아서 고치는 것이 어려울 것입니다. 그가 "모기지 지불"이 계산 된 9 개 장소를 모두 찾을 수 없었을 가능성이 많습니다.

2) 이제 한 곳에서만 모기지 지불을 계산하는이 방법을 가진 좋은 코드를 보여줍니다 . 학생에게 잘 작성된 코드를 얼마나 쉽게 향상시킬 수 있는지 보여주고 코드 / 프로젝트의 유지 관리 성을 향상시키는 방법을 설명하십시오.

BTW, 저는 학생들에게 소프트웨어의 유지 관리 성을 노출시키는 접근 방식을 좋아했습니다.

@ mattmattj : 많은 답변이 있고 내가 게시 한 링크 에는 좋은 포인터가 있기 때문에 이미 게시 된 답변의 반복이 아닌 것을 추가 할 것입니다.

먼저, "유지 보수성"을 정의해야합니다. 소프트웨어 아키텍처의 정의와 유사하게 모두가 받아 들일 수있는 단일 정의는 없습니다. 따라서 가장 중요하다고 생각되는 것을 선택하고 최대 3-4 줄로 표시하십시오. 그런 다음 자신의 코드 (또는 다른 사람의 코드)를 수집 / 이해하는 시간, 분 / 시간당 WTF 수 등과 같은 몇 가지 메트릭에 대해 이야기 할 수 있습니다. 그 후에 말하십시오.

일부 운동 (일부 응답과 약간 겹치는 소리가 들릴 수 있으므로 용서하십시오)

수업을 두 부분으로 나눕니다. 한 섹션에 1-2 일 안에 수행해야하는 간단한 코딩 과제를 지정하십시오. 최대 어려운 마감일. 그들은 모든 상황에서 작업을 수행해야합니다. 다른 학생 그룹의 경우 동일한 과제이지만 (이름 지정) 규칙 목록과 디자인에 대한 지침 및 따르지 않을 경우 포인트가 차감되는 방법에 대한 지침이 있습니다. 마치 소리처럼 들리더라도 속임수는 아닙니다.) 이제 코드 1을 바꾸십시오. 즉, 그룹 1은 이제 그룹 2가 수행 한 작업을 수행하고 그 반대도 마찬가지입니다. 이제 원래 코딩 할당에 대한 수정을 제안하고 동일한 시간 프레임에서 수행하도록 요청하십시오. 그들에게 재 수립하고 얼마나 쉬운 지 물어보고 토론 / 의견에 대한 바닥을 열어 라. 수업의 50 %가 행복하고 쉬울 것이며 50 %가 어려움을 겪을 가능성이 높습니다. 3 주 후에 그들 자신의 일을하도록 요청하고 그들이 하루에 그것을 할 수 있는지 볼 수도 있습니다.)

(비틀기 좋은 방법은 동일한 코드를 복잡한 방식으로 작성하고 클래스와 함께 수정하도록합니다.)

여기에서 유지 관리의 토대를 마련 할 수 있습니다. 수정 / 업데이트 된 모든 코드는 회사 비용입니다. 코드를 읽고 다시 수집하는 것이 쉬울수록 시장 출시 시간을 줄이는 데 도움이되는 수정이 더 빠르거나 빠릅니다. 오늘날의 빠른 기술 공간에서 매우 중요합니다. 시스템의 효율적인 발전을 위해서는 유지 관리가 중요합니다.

그린 필드와 브라운 필드 개발의 차이점을 이해하는 것이 중요합니다. 모든 프로젝트 나 시스템이 처음부터 만들어지는 것은 아닙니다 ( "처음부터"프로젝트를 찾기 어렵거나 일부는 어렵습니다). 필드가 "내재적으로"갈색이며 "손이 닿지"않을 때 결과적으로 단계적으로 진행함에 따라 필드를 형성하는 데 시간을 소비해야한다고 설명합니다 (드리프트가 너무 많고 '유지 불가능한'경우에만 가능). 빨리 받아들 일수록 좋습니다. 프로그래밍은 본질적으로 창의적이지만 다른 사람의 코드를 향상시키는 것으로 인식되지 않기 때문에 어렵습니다. 창의성 코드를 이해하고 "귀하의"창의성을 적용하여 코드를 향상시키는 기능이 있습니다. 더 잘 유지 관리하면 나중에 더 창의적으로 코드를 향상시킬 수 있습니다.

위의 링크에서 스파게티 비유를 자유롭게 참조하십시오. 다른 답변은 격차를 메우는 데 도움이되고 가르치는 데 도움이됩니다! 행운을 빌어 요!