프로그램을 처음부터 완전히 다시 빌드했을 때 항상 기분이 좋아지지 않게하려면 어떻게해야합니까? [닫은]

나는 상당한 양의 코딩을 배웠지 만, 항상 과학적 환경 (컴퓨터 과학이 아님)에 있었고, 아무도 올바른 방향으로 나를 안내하지 않고 완전히 독학되었습니다. 따라서 코딩 과정이 지저분했습니다. 나는 어떤 유형의 프로그램을 만들 때마다 결국 훨씬 더 우아하고 효율적으로 수행 할 수 있었으며 앞으로 훨씬 더 유연하고 관리하기 쉬운 방법을 알게되었다. 어떤 상황에서는, 나는 실제로 되돌아 가서 물건을 처음부터 다시 쌓았지만, 일반적으로 이것은 실제로 실현 가능하지 않습니다. 지금까지 대부분의 프로그램은 상대적으로 작았지만 무언가를 만들 때마다 큰 프로그램을 완전히 다시 작성하는 것은 쉽지 않습니다.

궁금합니다. 이것이 정상적인 경험입니까? 그렇지 않다면 어떻게 이런 일이 발생하지 않습니까? 미리 계획을 시도했지만 코드를 망치기 전에는 모든 것을 실제로 예측할 수 없습니다.

이 느낌은 완전히 정상이며 예상됩니다. 그것은 당신이 배우고 있음을 의미합니다. 새 프로젝트를 시작할 때마다 거의 한 방향으로 시작하여 결국 다르게 디자인하게됩니다.

실제 작업을 시작하기 전에 먼저 프로토 타입을 개발하는 것이 일반적 입니다. 오래된 코드를 다시 방문하여 리팩토링 하는 것도 일반적 입니다. 설계가 모듈 식인 경우 더 쉽습니다 . 기존 설계를 완전히 폐기하지 않고도 한 번에 비트와 조각을 쉽게 재 설계 할 수 있습니다.

어떤 사람들에게는 의사 코드를 먼저 쓰는 것이 도움이됩니다 . 다른 사람들 은 코드가 무엇을하는지 설명하는 주석 으로 시작한 다음 일반적인 구조가 있으면 코드를 작성 하는 것이 도움이된다고 생각합니다. 이 두 가지 사항은 설계를보다 효과적으로 계획하는 데 도움이되며 다시 작성하지 않아도됩니다.

팀의 일원 인 경우 디자인 프로세스에서 검토 프로세스를 갖는 것이 중요합니다. 설계 개선 방법을 배울 수 있도록 누군가가 코드를 검토하도록하십시오.

이것은 매우 일반적인 경험입니다

내가 상호 작용하는 대부분의 사람들과 나 자신도 이런 느낌입니다. 내가 한 가지 이유를 알 수있는 것은 코드를 작성할 때 사용하는 도메인과 도구에 대해 더 많이 배우기 때문에 이미 프로그램을 작성한 후 많은 개선 기회를 알 수 있기 때문입니다.

또 다른 이유는 이상적인 깨끗한 코드 솔루션에 대한 아이디어를 가지고 있고 실제 세계와 지저분한 한계가 당신을 방해하여 불완전한 해결 방법과 해킹을 작성해야한다는 것입니다.

"모두가 얼굴에 구멍을 뚫을 때까지 모든 사람들은 계획을 가지고 있습니다."

그것에 대해해야 할 일

어느 정도까지는 코드가 완벽하지 않을 것이라는 점을 받아 들여야합니다. 저에게 도움이 된 한 가지 사실은 "내가 한 달 전에 작성한 코드가 싫다면, 내가 배우고 더 나은 프로그래머가되었다는 의미"라는 생각입니다.

이 문제를 완화하는 방법은 지속적으로 작업하고 리팩토링 할 때 잠재적으로 개선 될 수있는 방법을 찾는 것입니다. 리팩토링과 새로운 기능 추가 / 버그 수정간에 균형이 잘 맞아야합니다. 이는 큰 디자인 문제에는 도움이되지 않지만 일반적으로보다 세련된 코드 기반을 자랑스럽게 여길 수 있습니다.

리팩토링 배우기- 점차 코드를 개선 하는 기술 . 우리 모두는 항상 배우므로 자신이 작성한 코드가 더 나은 방식으로 작성 될 수 있다는 것을 인식하는 것이 일반적입니다.

그러나 처음부터 시작할 필요없이 이러한 개선 사항을 적용하기 위해 기존 코드를 변환 할 수 있어야합니다.

정적 요구 사항이 우수하고이를 잘 이해하고 자세한 분석을 수행 할 시간이있는 경우 작업을 마친 후에도 여전히 만족할만한 우수한 디자인을 얻을 수 있습니다.

이 행복한 경우에도 더 나은 디자인을 만드는 데 도움이되는 새로운 언어 기능을 배울 수 있습니다.

그러나 일반적으로 운이 좋을 것입니다. 요구 사항이 별보다 불완전하고 불완전하며 이해한다고 생각했지만 잘못된 가정을 한 부분이 있습니다.

그런 다음 사용자가 초기 결과물을 볼 때 요구 사항이 변경됩니다. 그런 다음 사용자가 제어하지 않는 것이 세금 법과 같이 바뀔 것입니다.

당신이 할 수있는 일은 일이 바뀔 것이라고 가정하고 디자인하는 것입니다. 가능하면 리팩토링하지만 시간과 예산은 종종 최종 결과물이 처음에 현재 알고있는 것을 알았을 때보 다 우아하지 않다는 것을 의미합니다.

시간이 지남에 따라 요구 사항을보다 잘 파악하고 변화를 흡수 할 수있는 유연성을 필요로하는 설계 부분을 파악할 수 있습니다.

결국, 변화가 일정하다는 것을 받아들이고 "나는 더 잘 할 수 있었다"고 말하는 반짝임을 무시하십시오. 솔루션을 제공 한 것에 대해 자랑스럽게 생각하십시오.

프로그램을 처음부터 완전히 다시 빌드했을 때 항상 기분이 좋아지지 않게하려면 어떻게해야합니까?

"실제"프로젝트를 시작하기 전에 버림받은 프로토 타입을 만드는 것이 가능합니다. 빠르고 더러운. 그런 다음 개념을 증명하기 위해 프로토 타입을 얻을 때 시스템과 작업을 올바르게 수행하는 방법을 알게됩니다.

그러나 N 년 후에이 코드로 돌아와서 "이 얼마나 엉망인지"생각한다면 놀라지 마십시오.

이 만트라를 기억하십시오 :

완전은 선의 적입니다 .

완벽한 솔루션은 항상없는 이상적인 솔루션입니다. 이상적인 솔루션은 최소한의 작업으로 "충분히 좋은"상태를 달성 하나입니다.

• 기능 및 성능과 관련된 모든 요구 사항을 충족합니까?
• 현재 아키텍처에서 수정할 수없는 중요한 버그가 없습니까?
• 앞으로이 응용 프로그램을 유지 관리하는 데 얼마나 많은 작업을 투자 할 것인지 추정하십시오. 다시 쓰기의 노력이 장기적인 노력보다 많은가?
• 새로운 디자인이 실제로 상황을 악화시킬 가능성이 있습니까?

이 모든 질문에 "예"라고 대답하면 소프트웨어가 "충분히"적합하며 처음부터 다시 작성할 이유가 없습니다. 배운 디자인 수업을 다음 프로젝트에 적용하십시오.

모든 프로그래머가 과거에 두 개의 지저분한 프로그램을 갖는 것은 완전히 정상입니다. 소프트웨어 개발자로서 몇 번이나 코드를보고 "어떻게 바보가이 엉망을 썼는가?"라고 궁금해하고 버전 기록을 확인한 후 몇 년 전부터 나임을 알았습니다.

미리 계획을 시도했지만 코드를 망치기 전에는 모든 것을 실제로 예측할 수 없습니다.

완벽한 계획은 완벽한 소프트웨어 디자인 / 아키텍처를 제공 할 것이라고 생각하고 있지만, 이는 사실상 잘못된 것입니다. 이것에는 두 가지 큰 문제가 있습니다. 첫째, "종이에"와 "코드"가 거의 일치하지 않으며, 그 이유는 실제로 수행하는 것과 반대로 수행되어야하는 방법 을 말하기 가 쉽기 때문 입니다. 둘째, 예상치 못한 요구 사항의 변화는 개발 프로세스 후반에 명백 해져서 처음부터 추론 할 수 없었습니다.

애자일 운동에 대해 들어 보셨습니까? 그것은 "계획을 따르는 것"(다른 것들 중에서)과 달리 "변화에 반응하는 것"을 중요하게 생각하는 방법입니다. 다음은 선언문입니다 (빠른 읽기입니다). BDUF (Big Design Up Front)와 함정에 대해 읽을 수도 있습니다.

불행하게도, "Agile"회사 버전은 가짜 (인증 된 스크럼 마스터, "Agile"이라는 이름의 무거운 프로세스, 스크럼 강제, 100 % 코드 적용 강제 등)의 무리이며, 일반적으로 관리자 때문에 비정형 프로세스 변경을 초래합니다 애자일은 프로세스이자 은총 알이라고 생각합니다. 민첩한 선언문을 읽고 밥 삼촌과 마틴 파울러처럼이 운동 을 시작한 사람들의 말을 듣고 넌센스 버전의 "기업 민첩성"에 빠지지 마십시오.

특히 과학 코드 에서 TDD (Test Driven Development)를 수행하면 일반적으로 벗어날 수 있으며 , 소프트웨어 프로젝트가 상당히 훌륭하게 진행될 가능성이 높습니다. 성공적인 과학 코드는 주로 2 차적인 (때로는 경쟁적인) 관심사 인 성능을 가진 매우 사용 가능한 인터페이스를 가지고 있기 때문에 더 "욕심 많은"디자인으로 벗어날 수 있기 때문입니다. 소프트웨어 세력의 TDD 종류가되게합니다 울트라 사용할 수있는 당신이 어떻게 쓰기 때문에, 원하는 일이 (이상적)라고 당신이 실제로 구현하기 전에 할 수 있습니다. 또한 간단한 "입력"/ "출력"방식으로 신속하게 호출 할 수 있는 작은 인터페이스로 작은 기능 을 강제 실행 하며 리팩토링하기에 적합한 위치에 있습니다. 요구 사항이 변경되는 경우

나는 우리 모두 numpy가 성공적인 과학 컴퓨팅 소프트웨어 라는 것에 동의 할 수 있다고 생각 합니다. 그들의 인터페이스는 작고 매우 유용하며 모든 것이 잘 어울립니다. 참고 numpy: S 참조 가이드는 명시 적으로 TDD 권장 ' https://docs.scipy.org/doc/numpy-1.15.1/reference/testing.html을 . 나는 과거에 SAR (Synthetic Aperature Radar) 이미징 소프트웨어를 위해 TDD를 사용해 왔으며, 특정 도메인에서 매우 잘 작동한다고 주장 할 수도 있습니다.

주의 사항 : TDD의 디자인 부분은 분산 시스템과 같이 기본적인 리팩토링 (소프트웨어의 동시성이 필요하다고 결정하는 것과 같은)이 어려운 시스템에서는 잘 작동하지 않습니다. 당신은 동시 사용자의 수백만, TDD를하고있는 페이스 북과 같은 무언가를 설계했다 예를 들어, 만약 것 사용하는 것이 여전히 좋아 실수 ((디자인을 구동하기 위해) 후 당신은이 예비 설계를하고, 그냥 "테스트 첫번째 개발을 "). 코드로 들어가기 전에 응용 프로그램의 리소스와 구조에 대해 생각하는 것이 중요합니다 . TDD는 고 가용성, 분산 시스템으로 이어지지 않습니다.

프로그램을 처음부터 완전히 다시 빌드했을 때 항상 기분이 좋아지지 않게하려면 어떻게해야합니까?

위의 사항을 감안할 때 완벽한 디자인은 실제로 달성하기가 불가능하므로 완벽한 디자인을 추구하는 것은 바보 게임입니다. 당신은 정말로 가까워 질 수 있습니다. 처음부터 다시 디자인 할 수 있다고 생각 하더라도 아직 보이지 않는 숨겨진 요구 사항이있을 수 있습니다. 또한 재 작성 은 원래 코드를 개발하는 데 걸리는 시간보다 오래 걸립니다 . 새로운 디자인에는 예상치 못한 문제가있을 가능성이 높기 때문에 기존 시스템의 모든 기능을 다시 구현해야 할 가능성이 거의 없기 때문에 거의 확실하지는 않습니다 .

고려해야 할 또 다른 사항은 요구 사항이 변경 될 때 설계가 실제로 중요하다는 것 입니다.아무것도 변경되지 않으면 디자인이 얼마나 나쁘 든 중요하지 않습니다 (현재 사용 사례에서 완전히 작동한다고 가정). 22,000 줄 스위치 문이있는 기준선에서 작업했습니다 (기능이 더 길었습니다). 끔찍한 디자인 이었습니까? 그래, 끔찍했다. 우리가 고쳤나요? 아니요. 정상적으로 작동했으며 시스템의 일부에서는 실제로 충돌이나 버그가 발생하지 않았습니다. 프로젝트에 참여한 2 년 만에 한 번만 연락을 받았으며, 누군가는 그것을 추측하여 스위치에 다른 케이스를 삽입했습니다. 그러나 가끔 만지는 것을 고치기 위해 시간을내는 것은 가치가 없습니다. 불완전한 디자인을 그대로 유지하고 고장이 나거나 끊어지면 고치지 마십시오. 그래서 어쩌면 당신은 할 수 더 잘 할 ... 그러나 다시 쓸 가치가 있습니까? 무엇을 얻을 수 있습니까?

HTH.

Andreas Kammerloher가 제공 한 답변에 전적으로 동의하지만 아직 코딩 모범 사례를 배우고 적용하는 사람이 아무도 없다는 것에 놀랐습니다. 물론 이것은 은색 총알이 아니지만 개방형 접근 방식, 디자인 패턴, 코드 냄새가 나는 시간 등을 사용하면 더 나은 프로그래머가 될 수 있습니다. 라이브러리, 프레임 워크 등을 가장 잘 사용하는 것이 무엇인지 조사하십시오. 더 많은 정보가 있습니다. 표면을 긁는 것입니다.

그렇다고해서 기존 코드를 전체 쓰레기로 보지 않는다는 의미는 아닙니다 (실제로이 지식이없는 것보다 가장 오래된 프로그램을 훨씬 더 쓰레기로 볼 수 있습니다). 당신은 향상시킵니다. 또한 코딩 모범 사례의 수는 시간이 지남에 따라 증가하고 일부는 단순히 변경되므로 실제로는 완벽하지 않습니다. 이것 또는 꽤 길을 받아들이십시오.

한 가지 더 좋은 점은 코드 개정입니다. 혼자 일할 때 모서리를 쉽게자를 수 있습니다. 코드를 검토하는 다른 사람이 있다면 모범 사례를 따르지 않는 위치를 알려줄 수 있습니다. 이렇게하면 더 나은 코드를 생성하고 무언가를 배울 수 있습니다.

여기에 다른 훌륭한 답변을 추가하기 위해 내가 도움이되는 한 가지는 어디로 가고 싶은지 아는 것입니다 .

자체적으로 리팩토링을하는 경우는 거의 없습니다. 그러나 코드베이스의 각 영역에서 작업하면서 '레이더 아래'를 따라 가면서 더 작은 비트 리팩토링을 수행 할 수 있습니다. 목표를 염두에두면 이러한 기회를 통해 올바른 방향으로 단계별로 이동할 수 있습니다.

시간이 오래 걸릴 수 있지만 대부분의 단계는 코드를 개선하고 최종 결과는 가치가 있습니다.

또한, 당신이 더 잘할 수 있다고 느끼는 것은 좋은 징조입니다 ! 그것은 작업의 질에 관심이 있고 그것을 비판적으로 평가하고 있음을 보여줍니다. 아마 당신은 배우고 개선하고있을 것입니다. 이러한 것들이 당신을 걱정하게하지 마십시오 – 그러나 멈추지 마십시오!

당신은 실수로 인간과 기계의 다리 인 인류의 가장 큰 도전 (어드벤처) 중 하나를 우연히 발견했습니다. 예를 들어, 토목 공학과 같은 인간과 물리적 구조 사이의 다리는 약 200 년 이상 진행되어 왔습니다.

소프트웨어 개발은 ​​실제로 90 년대에만 주류가 되었기 때문에 약 30 년이되었습니다. 우리는 그것이 사회 과학만큼 공학 분야가 아니라는 것을 배웠으며 이제 막 시작했습니다.

예, TDD, 리팩토링, 함수형 프로그래밍, 리포지토리 패턴, 이벤트 소싱, MV 무언가, Java 스크립트 (<-이 작업, 미친 짓입니다), 모델 바인딩, No Sql, 컨테이너, 민첩한, SQL (<-이 작업을 수행하십시오) 강력합니다).

수정 사항이 없습니다. 전문가조차도 여전히 빨대를 잡고 있습니다.

환영하고 경고하십시오. 이곳은 외로운 곳입니다. 그러나 절대적으로 매혹적인.

나는 곡물에 대해 조금 갈 것입니다. 이것은 매우 일반적 이지만 허용 되지 않습니다 . 이것이 나타내는 것은 코드를 작성할 때 코드를 구성하는 좋은 방법을 인식하지 못하고 있다는 것입니다. 느낌은 코드 가 간단하지 않다는 것에서 비롯됩니다 .

당신의 경험은 오랫동안 내 것이었지만 최근 (지난 몇 년 동안), 나는 모든 것을 버려야한다고 생각 하지 않는 더 많은 코드를 만들고 있습니다. 대략 내가 한 일은 다음과 같습니다.

1. 특정 코드 블록이 어떤 가정을하고 있는지 명확하게 설명하십시오. 충족되지 않으면 오류를 던집니다. 이것에 대해 생각 분리의 소프트웨어의 나머지가 무엇을하고 있는지에 대한 세부 정보에 의존하지 않고,. 소프트웨어의 나머지 부분은 수행하는 가정 및 지원하는 사용 사례에 영향을 주지만 가정을 위반할 때 오류를 발생시키는 지 여부에는 영향을 미치지 않습니다.
2. 규칙과 패턴과 관행을 따르는 것이 좋은 코드를 낳을 것이라고 믿지 마십시오. 명확하지 않은 사고 방식과 관행을 버립니다. 이것은 거대했다. OO와 TDD는 일반적으로 코드를 작성할 때 따라야하는 추상적 인 원칙의 집합으로 실제 고려 사항에 근거하지 않은 방식으로 진행됩니다. 그러나 이것은 실제로 좋은 코드를 개발하는 데 전혀 도움이되지 않습니다. OO 또는 TDD를 전혀 사용하지 않는다면 이해해야하는 문제에 대한 해결책으로 사용해야합니다 . 다시 말해, 문제를보고 생각할 때만 사용해야합니다. "완전히 이해가되고 좋은 해결책으로 매우 분명합니다." 전에는 아니었다.
3. 코드를 작성할 때 다음 두 가지 질문에 중점을 두십시오.
   • 기능과 라이브러리 를 사용하도록 설계된 방식으로 사용하고 있습니까? 여기에는 해결하려는 문제 또는 최소한 매우 유사한 문제에 사용하는 것이 포함됩니다.
   • 그것은이다 간단 ? 동료와 본인도 나중에 쉽게 논리를 따를 수 있습니까? 코드에서 즉시 명확하지 않은 것이 있습니까?

내 코드는 이제 더 "절차 적"이며, 이는 데이터 구조 가 아니라 어떤 조치를 취 하느냐에 따라 구성됨을 의미합니다. 독립형 함수를 즉시 대체 할 수없는 언어로 객체를 사용합니다 (C # 및 Java는 즉시 함수를 대체 할 수 없으며 Python은 가능합니다). 나는 더 많은 유틸리티 함수 를 만드는 경향이 있는데 , 실제로 코드의 논리를 읽을 수 있도록 성가신 상용구를 밀어 넣는 경향이있다 . (예를 들어, 목록의 모든 항목 조합을 처리해야 할 때 색인을 반환하는 확장 메소드로 반복합니다.Tuple원래의 함수가 구현 세부 사항으로 복잡해지지 않도록하십시오.) 함수를 가져 오기 위해 함수가 다른 객체에 도달하는 대신 매개 변수로 훨씬 더 많은 것을 함수에 전달합니다. (호출자가 대신 가져 오거나 생성하여 전달합니다.) 이제 코드를 보는 것만으로는 명확하지 않은 것을 설명하는 더 많은 주석을 남기 므로 메소드의 논리를 쉽게 따를 수 있습니다. 방금 만든 것의 논리가 걱정되는 제한된 경우에만 테스트를 작성하고 모의 사용을 피합니다. (나는 고립 된 논리 조각에 대해 더 많은 입출력 테스트를 수행합니다.) 결과는 완벽 하지는 않지만 실제로는 괜찮은 코드입니다.심지어 2-3 년 후에. 변화에 상당히 잘 반응하는 코드입니다. 전체 시스템이 무너지지 않고 사소한 것들을 추가하거나 제거하거나 변경할 수 있습니다.

어느 정도, 당신 은 일이 엉망인 기간을 거쳐서 떠나야 할 경험이 있어야합니다. 그러나 일이 여전히 엉망이되어 모든 것을 버리고 다시 시작하기를 원한다면 뭔가 잘못되었습니다. 당신은 배우고 있지 않습니다.

시간이 제한되어 있음을 기억하십시오. 그리고 미래의 시간도 제한적입니다. 직장이나 학교 또는 개인 프로젝트에 관계없이 작업 코드와 관련하여 "제한적이고 소중한 시간을 최대한 활용 하는가?"라고 스스로에게 자문해야합니다. 아니면 " 제한된 시간을 가장 책임감있게 사용합니까?"

때때로 대답은 명백하게 그렇습니다 . 보통은 아닙니다. 때때로 그것은 울타리에있을 것이고, 당신은 당신의 재량을 사용해야합니다. 때로는 시간을 통해 배우는 것들 때문에 시간을 잘 활용하기도합니다.

포트 / 다시 쓰기의 이점이있는 많은 프로젝트 (직장과 개인 모두)가 있습니다. 나도 할 다른 일이 있습니다.

학습의 완전히 정상적인 부분입니다. 당신은가는대로 실수를 깨닫습니다.

그것이 당신이 나아지는 방법이며 피해야 할 것이 아닙니다.

재 작성하려는 매혹적인 충동이 일반적으로 비생산적이라는 것을 알 수있는 경험을 스스로에게 줄 수 있습니다. 중간 정도의 복잡하고 오래된 털이 많고 우아한 오픈 소스 프로젝트를 찾으십시오. 처음부터 다시 작성하고 어떻게하는지보십시오.

• 스크래치에서 시작한 디자인이 원하는만큼 우아 해졌습니까?
• 솔루션이 실제로 동일한 정확한 문제입니까? 어떤 기능을 사용하지 않았습니까? 어떤 최신 사례를 놓치셨습니까?
• 우아함을 추구하면서 원래 프로젝트에서 얻은 어려운 교훈은 무엇입니까?
• 누락 된 부분을 디자인에 다시 추가 한 후없는 부분만큼 깨끗합니까?

결국, 당신의 본능은 "이 시스템을 훨씬 더 잘 재구성 할 수 있습니다"라는 생각에서 "이 시스템의 부패 함은 즉각적으로 명백하지 않은 약간의 복잡성을 나타낼 수 있습니다"라는 생각으로 바뀔 것입니다.