사용중인 코드가 오래된 코딩 스타일을 사용하기 때문에 프로그래밍 할 수 없습니다. 프로그래머에게 이것이 정상입니까?

프로그래머로서의 첫 번째 직업이 있지만 사용 된 코딩 스타일로 인해 어떤 문제도 해결할 수 없습니다. 코드는 다음과 같습니다.

• 의견이 없습니다
• 기능이 없습니다 (50, 100, 200, 300 개 이상의 라인이 순서대로 실행 됨)
• if경로가 많은 문장을 많이 사용
• 아무 의미가없는 변수가 (예 : cf_cfop, CF_Natop, lnom, r_procod)
• 이전 언어 (2002의 Visual FoxPro 8)를 사용하지만 2007의 새로운 릴리스가 있습니다.

1970 년으로 돌아가는 느낌이 듭니다. OOP, 클린 코드, 디자인 패턴 등에 익숙한 프로그래머가이 구식 방식으로 코딩하는 데 문제가있는 것은 정상입니까?

편집 : 모든 답변이 매우 좋습니다. 제 희망은 전 세계에 이런 종류의 코드 기반이 많이있는 것 같습니다. 모든 답변에 언급 된 요점은 코드를 리팩터링하는 것입니다. 네, 정말 좋아합니다. 내 개인 프로젝트에서는 항상 이렇게하지만 ... 코드를 리팩터링 할 수 없습니다. 프로그래머는 자신이 디자인 한 작업에서만 파일을 변경할 수 있습니다.

이전 코드의 모든 변경 사항은 코드에 Subversion을 사용하여 코드에 주석을 달고 해당 변경과 관련된 메타 정보 (날짜, 프로그래머, 작업)를 추가해야합니다. 오래된 줄이 주석 처리됨). 코드 문제 일뿐만 아니라 소프트웨어 개발 문제 관리라고 생각합니다.

좋아, 나는 무딘거야. 그것은 일하기에 나쁜 곳입니다 ... 나는 그런 상황에 처해 있었고 보통이 코드로 삼키는 것으로 끝납니다. 1 년 정도 지나면 익숙해지며, 현대적인 대안을 사용하여 동일한 작업을보다 쉽고 유지 보수가 용이 한 방식으로 수행하고 런타임에 더 빠르게 수행 할 수있는 방법에 대한 이해를 잃게됩니다. 대부분의 경우.

한 달 만에 오래된 스쿨 코드로 끌려가는 느낌이 들기 때문에 직장을 그만 두었습니다. 나는 그것을 시도했지만,하지 않기로 결정했다. 나는 깨끗한 코드를 사용할 수 없었고 실습이 없어서 실력을 잃기 시작했다. 모든 현대적인 접근 방식은 3 가지 계층의 개발자에 의해 승인되어야했지만, 결코 발생하지 않았습니다. 현대적인 접근 방식을 사용할 때 문제가 발생할 수 있기 때문입니다. 그리고 현대적인 접근 방식을 사용하지 않을 때 나오는 코드의 취약성은 매우 무섭습니다.

잘못 이해하지 마십시오. 사람들이 솔루션을 과도하게 엔지니어링하는 경우가 있습니다. 그러나 80 년 동안의 코딩 규칙과 스타일로 끌려 가면 진로가 멈추고 경력 기회도 사라질 것입니다.

그런 다음 다시 돈을 벌어야하므로 때로는 마음에 들지 않는 일을해야 할 때가 있습니다. 그런 경우 번 아웃 증상을 주시하고 코딩을 일상적인 작업으로 바꾸십시오.

이 코딩 스타일 ( 어떤 종류의 스타일 이라고하더라도 )은 잘못된 코딩 스타일입니다.

대부분의 현대 언어에서 설명 가능한 변수 이름과 적절한 흐름 제어를 사용하여 짧은 함수를 작성할 수 있습니다 (Visual FoxPro는 현대적입니다).

당신이 겪고있는 문제는 나쁜 코드베이스, 더 이상 아무것도 아닙니다.

그러한 코드베이스는 존재하며 많은 수입니다-당신이 그들에게 문제가 있다는 사실은 그들이 얼마나 나쁜지 증명하고 (그리고 당신은 좋은 훈련을 받고 있음) 증명합니다.

변수 이름 바꾸기, 공통점 추출 및 큰 함수를 더 작은 함수로 나누는 등의 작업을 수행하는 것이 좋습니다 .

나는 당신이 묘사 한 것에서 멀지 않은 매우 나쁜 구조의 C # 프로젝트에 있습니다. 12 개의 개별 기능 (명확한 복사-붙여 넣기)을 단일 매개 변수를 사용 하는 기능으로 결합했습니다 .

(현재) 훌륭한 디자인 관행이 항상 인기있는 것은 아니라는 점을 제외하면 실제로는 "구식"이 아닙니다. 그건 나쁜 코드입니다. 잘못된 코드는 모든 사람을 느리게합니다. 결국 익숙해 지지만 이는 특정 시스템의 특정 문제에 익숙해 져 있기 때문입니다. 새로운 프로젝트가 주어지면 잘못된 코드를 작성하는 완전히 새로운 방법을 찾을 수 있습니다 . 좋은 점은 이러한 코드 냄새를 식별하는 방법을 이미 알고 있다는 것입니다.

당신이 할 수있는 가장 큰 일은 문제를 전파하지 않는 것입니다 . 팀이 아닌 한 이러한 나쁜 관행을 컨벤션으로 사용하지 마십시오. 리팩터링을 강요하지 않는 방식으로 새 코드를 깨끗하게 유지하십시오. 그것이 나쁘고 시간이 있다면 주요 리 팩터를 고려하십시오 ... 그러나 실제로 그 사치가 거의 없습니다.

사물을 파악할 때 주석을 추가하고 약간의 비트와 조각을 실용적으로 변경하십시오. 혼자서 코딩하지 않는 한, 팀과 함께이 문제를 해결해야합니다. 규칙이 없다면 규칙을 마련하는 데 약간의 시간이 걸리고 정기적으로 코드베이스를 유지 관리하는 경우 천천히 코드베이스를 개선하기 위해 노력해야합니다.

변수 이름이 잘못된 완전히 고립 된 함수를 발견하고 고치면 변수 이름을 유용한 것으로 만들면 if를 리팩터링 할 수 있습니다. 많은 부분을 리팩토링하지 않는 한 일반적인 기능을 변경하지 마십시오.

• 의견이 없습니다- 배우면서 수정하십시오
• 기능이없는 경우 (50, 100, 200, 300 개 이상의 라인이 순서대로 실행 됨)

이것은 아마도 이전 코드 반복에서 나온 것입니다. 이 시점에서 필자는 "기능"이 된 유사한 코드 블록 간의 미묘한 차이점에주의해야합니다. 그러나이 유형의 구조가 얼마나 나쁜 아이디어인지에 관계없이 이해하는 것은 매우 간단합니다 ... 그래서 어디서 문제가 생길지 잘 모르겠습니다.

• 경로가 많은 if 문을 많이 사용합니다. 여기서 당신이 의미하는 바가 확실하지 않습니다.
• 의미가없는 변수가있는 경우 (예 : cf_cfop, CF_Natop, lnom, r_procod)-

나는 '이름 바꾸기 변수'비트에주의를 강조합니다. 아직 링고를 이해하지 못할 가능성이 상당히 높으며, 변수 이름은 잠시 동안 방문한 후에 훨씬 더 의미가 있습니다. 말할 것도없이 문제가있는 변수 이름도있을 수는 없지만, 사이트의 일반적인 약어가 무엇인지 알고 있다면 예제에 논리가있는 것처럼 보입니다. 당신이 1의 팀이라면 이것은 중요하지 않습니다.

• 익숙하지 않은 언어를 사용합니다 (2002 년의 Visual FoxPro 8). 이것은 코드가 아닌 문제입니다.

이것은 기회 처럼 들린다 .

일이 수행되고 관리되는 방식에 많은 문제가 이미 있음을 분명히 알 수 있습니다. 당신은 그것이 모두 쓰레기이고 당신이 아무것도 할 수 없다고 불평하거나, 또는 이것을 고용주에게 당신의 가치를 보여줄 수있는 황금의 기회로 사용할 수 있습니다.

이제 고용주에게 행진하고 모든 것이 바뀌어야한다고 말하면 도움이되지 않습니다. 따라서 트릭은 잠시 동안 놀고, 많은 질문을하고, 코드를 작성해야 할 때 다른 개발자를 유지해야하므로 모든 주석 등의 규칙으로 재생해야합니다. 현재 선호하는 시스템을 사용하여 정보를 제공하는 동시에 위험을 감수하지 않는 합리적인 리팩토링을 도입 할 수 있습니다. 몇 가지 방법을 추출 할 수 있으며, 언어가 지원하는 경우 몇 가지 단위 테스트를 도입하십시오. 왜 이런 식으로했는지 물어 보거나 "잘못 된"무언가를하고 있다고 말하면 선호하는 코딩 스타일에 대한 입장을 건전하게 표현하면서 방어 적이거나 논쟁적인 태도를 취하지 마십시오. 예를 들어 Bob Martin의 Clean Code와 같은 책을 참조하거나 Programmers.SE에서 접한 다른 책, 기사 또는 질문과 답변을 참조 할 수 있습니다. 함께 일하는 사람들의 눈에는 경험을 넘어서는 사실을 통해 자신의 입장을 뒷받침하는 데 도움이 될 수있는 모든 것.

과도한 주석 처리와 관련하여 변수 및 메소드에 대한 설명적인 이름을 몇 개 추가하면이 중 일부를 정리할 수 있지만, 버전 관리 시스템이 좋은 경우에도이를 사용할 수 있습니다. 변경 사항 및 날짜 등을 기록하고 선택한 VCS와 함께 제공되지 않은 소스 파일의 다른 버전을 비교하는 도구를 사용합니다.

내가 말했듯이, 이것은 개발 팀의 개선에 기여할 수있는 기회입니다. 당신은 숙련되고 지식이 풍부하고 모범을 보여줄 수있는 사람으로 눈에 띄는 기회를 갖습니다. 이것들은 모두 경력이 발전함에 따라 나중에 당신을 도울 좋은 것입니다.

정글에 오신 걸 환영합니다 !

불행히도 종종 회사에서 일하기 시작한다는 것은 구조화되고 잘 조직 된 회사에서 일하지 않는 한 이러한 상황에 직면하기 시작한다는 것을 의미합니다.이 상황은 매우 일반적입니다 ...

내 조언은 :

1. 학습 시작 및 익숙해지기 : 사용되는 프로그래밍 언어 (Clipper / dBase) 및 환경 (Visual FoxPro)

2. 코드베이스를 읽고 분석 한 후 주석을 달기 시작

3. 코드 구성 / 리팩토링 (순서대로 실행 된 너무 많은 행의 문제 해결)

비슷한 코드베이스에 직면하는 데 문제가있는 것은 정상이지만 코드 품질을 개선하고 프로그램에 "터치"를 제공하여 코드베이스를 개선하고 더 나은 프로그램을 만드는 데 큰 어려움이 될 수 있습니다 ...

귀하의 질문에 대답하기 위해 : 그렇습니다. 모든 사람 / 회사는 엉터리 코드를 기반으로 구축 된 인프라를 사용합니다. 그런 상황에 처하게되면 다루기가 매우 어려울 수 있습니다.

지난 여름, 특정 부서에 연결된 QA 팀이 사용할 응용 프로그램을 개발하는 인턴으로 일했습니다. QA 팀은 많은 독립형 스크립트 (VBScript, Perl, Bash)를 사용하여 데이터베이스 등에서 테스트를 실행했으며이를 하나의 애플리케이션으로 통합하려고했습니다. 그러나 문제는 스크립트가 회사의 다른 곳에서 사용 되었기 때문에 (핵심 기능 / 변수 이름을 변경할 수 없음) 코드는 거의 10 년 동안 "추가되었습니다". 많은 쓰레기가 쌓였습니다.

그래도 당신이 할 수있는 일은 다음과 같습니다.

1. 도움을 요청하십시오.이 코드를 살펴보아야했던 동료 동료들은 아마도 그 특질에 익숙 할 것입니다. 당신에게 둔하고 혼란스러운 것은 그들에게 완벽합니다. 도움을 요청하십시오!
2. 가능할 때마다 리팩토링 :이 코드를 장기간 보거나 유지해야하는 경우 가능하면 리팩토링하십시오. 변수 이름에서 찾기 및 바꾸기를 실행하더라도 약간의 도움이됩니다. 지난 여름에 제가 인턴 한 회사는 crappy 변수 이름을 사용하는 것과 비슷한 문제가있었습니다. 기회를 가질 때마다 미세한 빗, 변수 이름 변경, 논리 최적화 (예 : 다양한 기능을 1로 그룹화) 등을 통해 코드를 실행할 수있었습니다. 기회가있을 때마다 똑같이하십시오!

어디에서나 코드의 외부 기능이 제대로 작동하는 한 내부의 작동 방식은 중요하지 않습니다.

나는 여기에 많은 응답자들과 다른 몇 가지 의견을 제시 할 것입니다. 내 의견 중 많은 부분이 당신에게 명백 할 수도 있지만 어쨌든 말해야합니다.

• 이해하기 전까지는 이해하지 못하는 코드 변경에주의하십시오.
• 팀 환경에서 팀원이 작업하는 코드를 사용하여 작업중인 경우 변경하기 전에 변경 사항에 대해 논의하십시오. 아무도 "고독한 총잡이"를 좋아하고 다른 사람들이 익숙한 코드를 변경하는 것을 좋아하지 않습니다. 이것은 귀하의 변경이 보증되지 않거나 "올바른"행동을 의미하지는 않습니다.
• 아이디어를 채택하십시오. 모든 사람이 당신의 아이디어로 승선하면 팀 전체의 업무량에 부담을주지 않고 팀의 기술을 리팩토링 할 수 있습니다.
• 경영진 인수를 확보하십시오. 그들은 당신이 가서 코드를 리팩터링하기 위해 자금을 할당 할 수 있습니다.
• 코드베이스 리팩토링의 이점에 대해 이해하는 관점에서 경영진과 대화하십시오. 유지 관리가 쉬운 코드는 버그를 해결하고 기능을 추가하는 데 소요되는 시간이 줄어든다는 것을 의미합니다. 이는 비용 효율적인 개발을 의미합니다. 빠른 처리 시간 등

환경의 정치를 이해하지 않고 순수 코딩, 모범 사례 제안을 쉽게 추가 할 수 있습니다. 함께 일하는 사람들은 코드베이스를 변경하거나 변경하려는 시간을 할당하고 싶지 않을 수 있지만 모든 것을 뛰어 넘기고 변경하기 전에 모든 사람에게 아이디어를 판매하려고 시도 할 수 있습니다.

이것이 도움이되기를 바랍니다.

눈에 띄는 것 중 하나는 편집 한 댓글입니다.

이전 코드의 모든 변경 사항은 코드에 주석을 달고 해당 변경과 관련된 메타 정보 (날짜, 프로그래머, 작업)를 주석 처리해야합니다 (이것은 혼란스러워졌으며 3 개의 중고 라인과 50 개의 오래된 라인이 주석 처리되었습니다). 코드 문제 일뿐만 아니라 소프트웨어 개발 문제 관리라고 생각합니다.

또한 설명하는 많은 문제가있는 레거시 FoxPro 코드 기반을 상속받은 프로젝트도 있습니다. 내가 프로젝트에 처음 소개 한 것 중 하나는 좋은 소스 코드 저장소였습니다. FoxPro는 SourceSafe와 통합 할 수 있지만 그 제품은 사용하기가 어렵습니다.

Paul McNett의 scx 도구 ( http://paulmcnett.com/scX.php) 의 사본을 잡고이를 개발주기에 통합했습니다. 바이너리 FoxPro 코드를 텍스트 형식으로 추출한 다음 Subversion, Mercurial 또는 git과 같은 소스 리포지토리에 넣을 수 있습니다. (SubFox 프로젝트는 http://vfpx.codeplex.com 에서 찾을 수 있습니다. 유용 할 수 있습니다.

이 도구는 히스토리를 제공하며 프로그래머가 코드 유지 보수 작업을 수행 할 수 있도록합니다. 이러한 도구를 사용하는 방법을 배우려면 시간이 다소 걸리지 만 모두 무료이기 때문에 시간을 투자하지 않는 것이 합리적입니다. (Job 프로젝트를 그런 식으로 이동할 수없는 경우에도).

나는 funkymushroom의 대답에 강력하게 동의 할 것입니다. 팀 환경 인 경우 미래의 좋은 과제를 계획 할 계획이라면 다른 사람들이 자신이 코드를 리팩터링하거나 재구성하고 있음을 알도록하십시오.

개인 내가 알고 경험하는 동안 회원님이 다른도 수정 및 유지 보수 코드를 유지하는 경우, 코딩 스타일에서 숙박을 기존 코드의 스타일로. 주석과 설명을 추가하는 것은 좋지만 기본 레이아웃과 규칙은 그대로 유지해야합니다. 프로젝트의 오래된 전문가 / 총은 코드가 수년 동안 본 것과 유사 할 것으로 예상합니다.

고객이 버그에 대해 비명을 지르면 경영진은 가능한 빨리 문제를 해결하기 위해 오래된 총으로갑니다. 이 오래된 총기들이 압력을 받고있을 때“코드 정리”를 발견하여 조정해야하는 변수 하나를 이동하거나 이름을 바꾸는 데 걸리는 시간을 소비해야한다면 회사의 이름이 " 진흙".

위기가 끝나면 먼저 오래된 총이 중요 업데이트를 천천히 비난합니다. 다음으로 회사에있는 동안 정리 된 코드를 유지 관리해야합니다. 마지막으로, 새롭고 흥미로운 프로젝트를 사용할 수있게되면 관리자는 누가 프로젝트를 수행해야하는지 전문가에게 물어보고, 일단 한 번 망쳐 놓았다면, 마지막에 사료가 던져 질 때까지 새 프로젝트로 만들지 않을 것입니다. 마감일을 맞추기 위해.

대학에서“올바른”코딩 방법을 배웠고 지금은 노동력을 사용하고 있다면“올바른”방법을 잊어 버리십시오. 이들은 대학 배정이 아니며,이 프로젝트는 한 학기 동안 지속되지 않으며, 몇 년 동안 살 수 있으며, 최신 CS 트렌드에 대해 다른 수준의 전문 지식과 다른 수준의 관심을 가진 사람들 그룹에 의해 유지되어야합니다. 팀 플레이어 여야합니다.

당신은 학교에서 가장 큰 핫 샷 프로그래밍이 될 수 있지만, 직장에서, 첫 직장에서는 거리 신념이 전혀없는 초보자입니다. 몇 년 동안 프로그래밍을해온 사람들은 학교 나 성적에 대해 후회하지 않습니다. 그것은 다른 사람들과 얼마나 잘 어울리 며 삶에 얼마나 많은 방해가되는지입니다.

20 년 동안 여러 에이스 프로그래머들이 해고 된 것 같습니다. 주로 그들이“올바른”방식으로 일을해야하기 때문입니다. 업무에 매우 독특하고 특별한 것을 가져 오지 않는 한 교체 할 수 있습니다. 당신은 당신의 수업의 최고 였을지도 모르지만 내년에는 다른 누군가가 그들의 수업의 최고가 될 것이며 일자리를 찾을 것입니다.

나는 당신이 일을 바꾸기로 결정할 때까지, 당신의 일을 유지하는 것입니다. 직업을 유지한다는 것은 다른 사람이 건설하고 지불 한 놀이터에서 즐겁게 놀아야한다는 것을 의미합니다.

나는 부정적으로 들린다는 것을 알고 있지만 항상 희망이 있습니다. 경험을 쌓고 성공을 거두면 영향력을 행사하고 더 나은 방식으로 변화시킬 수 있습니다. 새 코드를 작성하거나 새 프로젝트를 작성할 때 원하는 변경 사항을 적용하십시오. 그것이 새로운 코드라면, 오래된 총은 그것이 그것을 남긴 방식으로 기대하지 않으며, 이점을 볼 때 새로운 방식을 배우고 적응시킬 수 있습니다.

오래된 시스템은 변경 될 수 있지만 시간이 걸립니다. 무언가를 바꾸는 것은 위험을 초래하고, 비즈니스는 위험을 미워하며, 회사가 변화에 익숙해 지려면 시간과 노력이 필요합니다.