응용 프로그램의 일부를 다시 작성하지 않는 방법


13

회사의 영업 부서 프로젝트를 위해 일하고 있습니다. 그것은 첫 번째 전문 프로그래밍 직업이지만, 나 자신이 코딩하고 수년 동안 배우고 있습니다. 프로젝트의 일부는 일부 데이터를 가져 와서 입력과 결합하여 생성하고 그래프로 만드는 것입니다. 그런 다음 데이터 등을 저장하십시오. 그래서 나는 이것에 대한 코드를 하루 만에 작성했습니다. 그 다음날 나는 프로젝트 감독관에게 보여 주었고 그것을 좋아했지만 "만약 우리가 이걸 가지고 있다면"그래프에 무언가를 추가하고 싶었습니다. 이것은 프로그램의 모양이나 기능에 큰 변화는 아니지만 데이터 저장, 처리 등의 방법을 크게 변경했습니다.

다시 한 번 데이터베이스 테이블을 재구성하고 새로운 요청을 지원하기 위해 코드를 처음부터 다시 작성하는 데 하루가 걸렸습니다. 나는 그것을 다시 그에게 가져 갔고, 똑같은 일이 일어났다. 그는 데이터 처리 방법을 크게 바꿔 놓은 다른 것을 요청했습니다. 그래서 다시 작성해야했습니다. 마침내 그는 서명을했고 다시 작성하지 않아도되기를 바랍니다.

관리자 나 그와 비슷한 것을 강타하지는 않습니다. 그는 대단한 사람이며 그가 요청한 것들이이 세상에서 나오지 않았으며, 이전에 한 일과 호환되지 않았습니다.

완전한 재 작성을 피하기 위해 앞으로 할 수있는 일이 있는지 궁금합니다. 나는 유연한 코드를 만드는 것을 이해하고 그것을 시도했지만, 이것을 쉽게하기 위해 다르게 수행 할 수있는 관행이나 일을 알고 싶습니다. 따라서 앞으로 3 일을 소비하지 않습니다. 1을 가져 가야합니다.


2
어떤 프로그래밍 패러다임을 사용하고 있습니까? 절차 적, 객체 지향적, 기능적, 기타?
Tulains Córdova

2
다시 쓰지 않으려면 데이터베이스와 응용 프로그램 계층을 분리하십시오. 코드 작성 방법에 적용하는 것은 단순한 개념이 아닙니다. 코드를 간단하고 적응 가능하게 만드는 복잡한 개념입니다.
StackOverFowl

6
요구 사항이 명확하지 않거나 오해 한 것 같습니다. 구현이 잘못된 가정을 통해 이루어진 경우 원칙이나 모범 사례를 통해 전체 애플리케이션을 다시 실행할 수 있습니다. 단일 LOC를 입력하기 전에 " what if ... " 요구 사항을 물어 보는 것이 좋습니다 . 새로운 what if ...로 관리자가 당신을 놀라게 할 때까지 기다리지 마십시오 . 기능적 차이를 찾는 데 시간을 소비하면 서프라이즈 요소 도 줄어 듭니다 .
Laiv

3
의존성 주입은 당신의 친구입니다. Google에서이를 언어 및 프레임 워크에 적용하는 방법을 확인하십시오. 훨씬 더 모듈화 된 코드를 작성할 수 있으므로 요구 사항이 변경 될 때 다시 작성해야하는 코드의 양이 줄어 듭니다.
Eternal21

2
많은 재기록이 나쁜 것처럼 보이지만 실제로 중요한 것은 최종 사용자의 요청에 얼마나 빨리 응답 할 수 있는지입니다. 프로젝트의 복잡성에 따라 다르지만 하루는 꽤 좋은 리드 타임이라고 말하고 싶습니다. 올바른 일을해야합니다! 실제로 중요한 변화를 보는 소프트웨어는 좋은 징조입니다. 이는 유용하고 개선되고 있음을 의미합니다. 오랫동안 변경되지 않은 소프트웨어는 유지 관리하기가 훨씬 어렵습니다.
Justin

답변:


22

내가 언급했듯이, 나는 처음에 요구 사항이 명확하지 않았거나 중요한 세부 사항을 놓친 것으로 생각합니다.

더 나은 코드, 모범 사례, 디자인 패턴 또는 OOP 원칙으로 모든 것을 해결할 수있는 것은 아닙니다. 구현이 잘못된 가정이나 잘못된 전제에 기반한 경우 전체 애플리케이션을 다시 실행하는 것을 막을 수있는 것은 없습니다.

솔루션 코딩을 서두르지 마십시오. 단일 LOC를 입력하기 전에 요구 사항을 명확하게 설명하는 데 시간을 투자하십시오. 깊은 당신은 요구 사항으로 탐구, 더 어떤 경우 질문이 나타납니다. 다음 what-if로 관리자가 당신을 놀라게 할 때까지 기다리지 마십시오 . 스스로를 예상하십시오. 이 작은 운동은 놀랍게도 크게 줄일 수 있습니다 .

필요한만큼 여러 번 물어 보는 것을 두려워하지 마십시오. 때때로 나무 (세부 사항)가 숲 (전체 그림)을 보지 못하게합니다. 그리고 우리가 가장 먼저보아야 할 숲입니다.

요구 사항이 명확하면 디자인 단계에서 더 나은 결정을 내릴 수 있습니다.

마지막으로 전반적인 그림은 목표라는 것을 기억하십시오. 이 목표로 향하는 길은 단순하거나 간단하지 않습니다. 변경 사항이 계속 발생하므로 민첩해야합니다.


3
이. 이 답변은 가장 좋은 방법입니다. 절대적으로 무엇이든하기 전에 이러한 요구 사항을 충족하십시오.
Rhys Johns

1
이것은 좋은 대답이지만, 이러한 요청을 쉽게 수용 할 수 있도록 응용 프로그램을 구성하는 더 좋은 방법이 있다고 잔소리가 있습니다. 나는 소위 "원칙"이 떠 다니는 것이 도움이 될 것이라고 생각하지 않습니다. 솔루션은 문제와 관련이 있어야합니다. 더 많은 정보가 없다면, 당신의 대답은 말이됩니다.
Frank Hileman

글쎄, 나는 문제가 내가 처음으로 개발자로서 저에게 일어났기 때문에 내가 언급 한 문제라고 강하게 느꼈습니다. 나는 즉시 문구를 LOC 또는 모듈로 번역했으며, 무언가를 바꿔야 할 때 뭔가 극적으로 놀랐습니다. 매일 또는 매주 리팩토링 리팩토링. SoC, SPR, 다형성 등으로 최선을 다하지는 않았지만 ... 변화로 인한 많은 갈등은 전반적인 시력 누출로 인해 발생했습니다.
Laiv

2
이 답변 위에 구축하려면 요구 사항 수집에 대해서도 민첩해야합니다. 때때로 사람들은 새로운 아이디어를 얻거나 제품을 볼 때 잊어 버린 것을 기억합니다. "내가 당신에게 이것을 구축하라고 요청했지만 그것이 내가 의도 한 바가 아니라는 것을 알고 있습니다." 빠르고 더러운 "개념 증명"을 작성하여 이로 인해 좌절과 재 작업이 발생하는 것을 방지 할 수 있습니다. 이것은 가짜 그래프와 같은 모형 일 수도 있습니다. 고객이 생각하는 데 도움이됩니다.
Akhil

1
일부는 "DB 벤더가 거의 변경하지 않기 때문에"코드에서 db를 추상화하는 것이 필수가 아니라고 주장 할 수 있습니다. 나는 당신에게 동의하지만 내 대답의 요점은 요구 사항을 수집하는 동안 개발자임을 잊지 말고 요구 사항 수집에 중점을 둡니다. 관리자처럼 생각하고 관리자처럼 물어보십시오. 개발자처럼 생각하지 마십시오.
Laiv

4

당신이 준 것에 근거하여 그것을 알 수있는 방법은 없습니다. 그 순간에 필요한 것이 더 빠르고 더럽습니다. 그러나 누군가가 그것을 좋아하고 복잡해지면서 이제는 많은 문제가 복잡성이 시작될 때까지 스스로 나타나지 않는다는 것을 알기 시작했습니다. 할 수있는 많은 다른 것들이 단순히 압도적입니다.

오래된 "No Silver Bullet"이 있는데 사실입니다. 다시 말하지만 전체 사양 (또는 애자일에 대한 개선 된 사양)을 사용하여 수행 할 작업과 우수한 프로그래밍 원칙 및 우수한 디자인을 사용할 수있는 기능을 알 수있는 방법이 없습니다. 프로그래머는 반복해서 다시 쓰는 것을 좋아합니다 . 나는 당신이 이것에 반드시 빠졌다고 말하는 것은 아닙니다. 지금이 순간에는 작기 때문입니다.

이 기회를 이용하여 몇 가지 기본 원칙을 적용하십시오. 당신은 그들이 효과가 있다는 것을 알지만 누군가“아냐, 안돼.”라고 말하거나 다른 것을 좋아할 것입니다. 회사의 돈으로 모든 것을 할 수는 없지만 그들이 탐험 할 시간이 있다면 기회로 사용하십시오. "최고의"방법 또는 "새로운"방법으로 일을하는 사람, 기초, 사람 이 항상 있습니다 .


당신이 연결 한 좋은 기사.
SH7890

1
실로 좋은 기사! 나는 OP 사례가 아니라고 생각하지만 저자와 더 동의 할 수는 없습니다.
Laiv

1
나는 그것이 하나에 대한 것이라고 생각하지 않았지만 그것은 하루가 될 수있는 것처럼 읽었습니다. 잘하면 이것이 OP에 도움이 될 것입니다.
johnny

2

귀하의 관리자는 귀하가 겪은 각 단계에서 가장 적절했을 것입니다. 그가 관리자이기 때문이 아니라 결과와 유용성을 고려하고 있기 때문에 고객이나 고객의 요청에 대한 이전 처리 횟수를 고려하고 있기 때문입니다.

UI는 어려운 일입니다. 일반적으로 5 명은 15 개의 다른보기를 갖습니다. 그리고 데이터 및 데이터 구조화 및 데이터 분석은 요소 10을 곱하여 변경하는 경향이 있습니다.) UI는 패션과 같으며 일부 조합은 멋지고 일부는 상식이 끔찍하거나 누락되었습니다.

말할 것도없이, 예를 들어 LEAN 공정 중에는 석재에 아무것도 설정되지 않습니다. 반복적 인 평가와 같은 문제가 발생하며 각 단계에서 약간 나아지거나 잘못된 경로를 피할 수 있습니다.

그래서 간단한 대답은 전혀 다시 쓰지 않는 것과 같은 것이 없다는 것입니다.


2

반복적 개발 (하루 반복 되더라도 기본적으로 수행 한 작업)은 종종 이와 같습니다. 솔루션에 대한 초기 시도는 종종 실패하고 피드백을 수집함으로써 시스템은 솔루션으로 수렴됩니다. Craig Larman의 강사 자료에서 UML 적용 및 디자인 패턴 책에 대한 그림 2.2를 빌려 보겠습니다 .

여기에 이미지 설명을 입력하십시오

프로젝트를 시작할 때 불안정한 버전으로 사는 법을 배웁니다. 폭포 생각이기 때문에 "조기 더 많은 요구 사항을 충족해야합니다"라는 답변에 동의하지 않습니다. 요구 사항 측면에서 최대한 많은 것을 얻으려고 노력하는 것이 사실이지만, 여러 가지 이유로 완전하고 정확한 요구 사항을 가질 수는 없습니다.

피드백을받은 후에 다시 작성해야하는 금액을 줄일 수는 없습니다. 종종 사실이었던 한 가지는 소프트웨어의 인간-컴퓨터 상호 작용이 변경 될 가능성이 높다는 것입니다. 왜냐하면 처음부터 제대로 이해하기가 어렵 기 때문입니다.

Microsoft Word와 그 데이터 형식 (.doc)이 지난 몇 년 동안 실제로 어떻게 발전하지 않았는지 생각해보십시오. 그의는 때문에 텍스트 문서 문제 도메인으로 정말 (단락 여전히 단락 등이며, 페이지가 여전히 페이지입니다) 많이 진화하지 않았다. 그러나 Word의 사용자 인터페이스는 많은 발전을 거듭했으며 계속 발전하고 있습니다. 프리젠 테이션 또는 입력 용 코드는 버전간에 불안정한 경향이 있으므로 시스템의 다른 부분을 직접 연결하여 다시 작성하지 않도록하는 것이 가장 좋습니다.

기본 논리 및 문제에 대한 데이터와 프레젠테이션을 분리 할 수있는 소프트웨어 아키텍처를 사용하면 재 작성이 줄어 듭니다. Model-View 분리 와 같은 많은 소프트웨어 패턴 은 여러 번의 재 작성으로 어려움을 겪고 더 나은 방법을 찾는 사람들 때문에 발생했습니다.

이것은 매우 불교 적으로 들릴지 모르지만,이 재 작문을 겪게되어 다행입니다. 많은 사람들이 패턴을 피해야하는 악몽을 다시 쓰지 않고 MVC 패턴이나 다른 디자인 패턴에 대해 배웁니다.


나는이 대답이 받아 들여지는 것을 선호한다. 모든 요구 사항을 미리 설정하는 것보다 솔루션을 반복하는 것이 좋습니다. 특히 전체 응용 프로그램을 하루 안에 다시 작성할 수있는 경우.
Euphoric

보스는 첫 번째가 완료 될 때까지 두 번째 반복에서 그들이 원하는 것을 알지 못했다고 확신합니다. “사전 요구 사항을 더 모으는 것은 불가능했을 것입니다.
gnasher729

1

나는 운동에 대한 답을 얻지 못합니다. 조직에 따라 근무 시간 동안 운동을 할 수는 있지만 자신의 시간에해야 할 운동입니다.

첫 번째 솔루션을 재 설계하여 정확히 수행 한 작업을 수행하지만 2 단계 또는 2 단계 및 3 단계를 더 쉽게 추가 할 수 있습니다. 해당 단계를 추가하지 말고 스텁하지 마십시오. 모든 원래 요구 사항을 충족하지만 새로운 기능을 포함하도록 쉽게 업그레이드 할 수있는 솔루션을 만드십시오. 두 번째 솔루션에 대해서도 동일하게 수행하십시오.


1

요구 사항 변경, 그것은 인생의 사실입니다. 가늠자 : 첫 번째 솔루션이 다를 수있어 총 프로그래밍 시간이 줄었 을까요? 그것이 당신이 경험을하는 방법을 배우는 것입니다.

이것이 첫 번째 가파른 학습 곡선입니다. 이를 관리 할 때 두 번째 과제는 다음과 같습니다. 사용자가 폐기하고 싶지 않은 1 년 분량의 데이터를 저장 한 경우 변경된 요구 사항을 어떻게 처리합니까?


-1

당신의 이야기에서 요구 사항과 선호하는 건축 결정이 충분히 전달되지 않았다는 것이 명백합니다. 그러므로 여러분 중 하나 또는 둘다는 나쁜 의사 소통 자입니다.

일부 건축가는 혼자 프로그래밍하거나 훌륭한 교육 (자주 혼자 공부하는 경우가 많음)이거나 회사의 첫 개발자 (분명히 혼자) 일 때 좋은 업적을 달성하여 높은 지위를 얻음으로써 건축가 일 수도 있습니다. 팀과 의사 소통하는 데 필요하지 않습니다. 디자인을 문서화하고 팀을 지원하는 것이 아니라 프로그래밍에 계속 집중하는 것은 드문 일이 아닙니다.

그러나이 경우에도 더 오래 이야기하고 질문하고 메모를하여 보상을 시도 할 수 있습니다. 작은 사양을 직접 작성하여 건축가에게 승인하도록 요청할 수도 있습니다.

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