나는 1 년의 경험을 가진 프로그래머입니다. 최근에 프로젝트를 거의 제대로 시작하지 않는다는 것을 깨달았습니다.

1. 몇 가지 사용 사례로 시작
2. 코딩 시작
3. 내가 잘 처리하지 못하고 현재 코드베이스에 적합하지 않은 몇 가지 사항을 실현하십시오.
4. 코드의 대부분을 다시 작성

그리고 이것은 몇 번 갈 수 있습니다

그래서 내 질문은

1. 그러한 관행은 일반적입니까, 아니면 내가 유능하지 않다는 것을 암시합니까?
2. 이 부분에서 어떻게 나 자신을 향상시킬 수 있습니까?

설명하는주기는 정상입니다. 상황을 개선하는 방법은이주기를 피하는 것이 아니라 간소화하는 것입니다. 첫 번째 단계는 다음을 수락하는 것입니다.

1. 프로젝트의 첫날에 모든 것을 아는 것은 거의 불가능합니다 .
2. 당신이 어떻게 든 모든 것을 알고 있더라도 프로젝트를 마칠 때까지 (고객의 요구 사항, 고객의 시장, 협력하는 기술, 고객의 희망 사항) 무언가 가 바뀌고 만들어 질 것입니다 당신이 잘못했거나 잘못 알고있는 것의 적어도 일부.

따라서 모든 것을 미리 계획하는 것은 불가능하며, 가능하다면 그 계획을 따르면 불완전하거나 쓸모없는 것을 만들게 될 것입니다. 이를 알면 변경 사항을 계획에 통합합니다. 당신의 단계를 보자 :

1. 몇 가지 사용 사례로 시작
2. 코딩 시작
3. 내가 잘 처리하지 못하고 현재 코드베이스에 적합하지 않은 몇 가지 사항을 실현하십시오.
4. 코드의 대부분을 다시 작성

그것은 실제로 좋은 출발점입니다. 내가 접근하는 방법은 다음과 같습니다.

1. 몇 가지 사용 사례로 시작

좋은. "사용 사례"라고하면 소프트웨어가 무엇인지에 집중하고 위해 . "몇 개"라고 말하면 모든 것을 발견하려는 것이 아닙니다. 관리 가능한 양의 작업을 고수하고 있습니다. 여기에 추가 할 것은 우선 순위를 정하는 것입니다. 고객 또는 최종 사용자와 함께이 질문에 대한 답을 찾으십시오.

상황을 개선 할 수있는 가장 작고 간단한 소프트웨어는 무엇입니까?

이 제품 은 최소한의 실행 가능한 제품입니다 . 이보다 작은 것은 사용자에게는 도움이되지 않지만 너무 큰 계획은 너무 빨리 계획됩니다. 이를 구축하기에 충분한 정보를 얻은 다음 계속 진행하십시오. 이 시점에서 모든 것을 알 수는 없습니다.

2. 코딩을 시작하십시오.

큰. 당신은 가능한 빨리 일하게됩니다. 코드를 작성할 때까지 고객은 전혀 혜택을받지 못했습니다. 계획에 더 많은 시간을 투자할수록 고객이 투자금을 지불하지 않고 기다리는 데 더 오랜 시간을 소비했습니다.

여기에 좋은 코드 를 작성하라는 알림을 추가합니다 . SOLID Principles를 기억하고 따르고, 깨지기 쉬운 곳이나 복잡한 곳에서 적절한 단위 테스트를 작성하고, 잊어 버리거나 나중에 문제를 일으킬 수있는 것을 기록하십시오. 변경으로 인해 문제가 발생하지 않도록 코드를 구성하려고합니다. 이렇게하려면 때마다 당신이 뭔가를 구축하기로 결정하게 이 방법 대신 이 가능한 한 적은 코드가 그 결정에 의해 영향을받는 있도록 코드를 구성, 방법. 일반적으로이를 수행하는 좋은 방법은 코드를 분리하는 것입니다.

• 언어와 상황에 따라 단순하고 개별적인 구성 요소를 사용하십시오.이 구성 요소는 함수, 클래스, 어셈블리, 모듈, 서비스 등일 수 있습니다. 함수가 많은 클래스 또는 클래스가 많은 어셈블리)
• 각 구성 요소는 하나의 작업 또는 하나의 작업과 관련된 작업을 수행합니다.
• 한 구성 요소의 내부 작동 방식 변경으로 다른 구성 요소를 변경하지 않아야 함
• 구성 요소는 가져 오거나 작성 하지 않고 사용하거나 의존하는 것을 제공 해야 합니다.
• 구성 요소는 정보를 가져 와서 작업을 직접 수행하는 대신 다른 구성 요소에 정보를 제공 하고 작업을 요청해야 합니다.
• 구성 요소는 다른 구성 요소의 내부 작동에 액세스하거나 사용하거나 의존해서는 안됩니다. 공개적으로 액세스 가능한 기능 만 사용하십시오.

이렇게하면 대부분의 경우 한 곳에서 문제를 해결할 수 있고 나머지 코드는 눈에 띄지 않도록 변경의 영향을 격리하게됩니다.

3. 디자인에 문제가 있거나 단점이 있습니다.

일어날 것입니다. 불가피하다. 이것을 받아들이십시오. 이러한 문제 중 하나에 부딪 치면 어떤 종류의 문제인지 결정하십시오.

일부 문제는 소프트웨어의 기능을 수행하기 어려운 코드 또는 디자인의 문제입니다. 이러한 문제의 경우 문제를 해결하려면 돌아가서 디자인을 변경해야합니다.

일부 문제는 충분한 정보가 없거나 이전에 생각하지 못한 것을 가지고 있기 때문에 발생합니다. 이러한 문제의 경우 사용자 또는 클라이언트로 돌아가서 문제 해결 방법을 물어보십시오. 답을 찾으면 디자인을 업데이트하여 처리하십시오.

두 경우 모두 코드의 어떤 부분을 변경해야하는지주의를 기울여야하며, 더 많은 코드를 작성할수록 향후 어떤 부분을 변경해야하는지 생각해야합니다. 이렇게하면 어떤 부품이 서로 연결되어 있는지, 어떤 부품을 더 격리해야하는지 쉽게 파악할 수 있습니다.

4. 코드의 일부를 다시 작성하십시오

코드를 변경하는 방법을 확인한 후에는 변경할 수 있습니다. 코드를 잘 구성했다면 일반적으로 하나의 구성 요소 만 변경해야하지만 경우에 따라 일부 구성 요소를 추가해야 할 수도 있습니다. 많은 곳에서 많은 것을 바꿔야한다는 것을 알게되면 왜 그런지 생각해보십시오. 이 코드를 모두 내부에 유지하는 구성 요소를 추가 한 다음 모든 장소에서 해당 구성 요소를 사용하도록 할 수 있습니까? 가능하면 다음에이 기능을 변경해야 할 경우 한 곳에서 수행 할 수 있습니다.

5. 테스트

소프트웨어 문제의 일반적인 원인은 요구 사항을 충분히 알지 못하기 때문입니다. 이것은 종종 개발자의 잘못이 아닙니다. 종종 사용자는 자신에게 필요한 것이 무엇인지 모릅니다. 이 문제를 해결하는 가장 쉬운 방법은 질문을 뒤집는 것입니다. 이 단계를 수행 할 때마다 "소프트웨어가 무엇을해야합니까?"라고 묻는 대신 지금까지 구축 한 내용을 사용자에게 제공하고 "내가 이것을 구축했습니다. 필요한 작업을 수행합니까?" 그들이 예라고 대답하면, 당신은 그들의 문제를 해결하는 것을 만들었고, 당신은 일을 멈출 수 있습니다! 그들이 '아니오'라고 대답하면 소프트웨어에 어떤 문제가 있는지 좀 더 구체적인 용어로 알려줄 수 있으며, 특정 사항을 개선하고 더 많은 피드백을 얻기 위해 다시 올 수 있습니다.

6. 배우다

이주기를 진행하면서 찾고있는 문제와 변경 사항에주의를 기울이십시오. 패턴이 있습니까? 향상시킬 수 있습니까?

몇 가지 예 :

• 특정 사용자의 관점을 간과 한 것을 계속 발견하면 해당 사용자가 디자인 단계에 더 관여하게 할 수 있습니까?
• 기술과 호환되도록 항목을 계속 변경해야하는 경우 코드와 해당 기술 사이의 인터페이스를 구현하여 인터페이스 만 변경하면됩니까?
• 사용자가 UI의 단어, 색상, 그림 또는 기타 사항에 대해 계속 마음을 바꾸는 경우 나머지 응용 프로그램에 모두 한곳에 있도록 구성 요소를 제공하는 구성 요소를 만들 수 있습니까?
• 많은 변경 사항이 동일한 구성 요소에있는 경우 구성 요소가 하나의 작업에만 집중되어 있습니까? 몇 개의 작은 조각으로 나눌 수 있습니까? 다른 부품을 건드리지 않고이 구성 요소를 변경할 수 있습니까?

민첩하게

당신이 여기로 나아가고있는 것은 애자일 (Agile)로 알려진 작업 스타일입니다. 애자일은 방법론이 아니며, 많은 것들 (Scrum, XP, Kanban 등)을 통합 한 방법론의 모음입니다. 변경을 피하거나 무시하지 않고 변경에 적응하도록 계획해야합니다. 핵심 원칙 중 일부, 특히 상황과 관련된 원칙은 다음과 같습니다.

• 자신있게 예측할 수있는 것보다 더 앞선 계획을 세우지 마십시오
• 갈 때 변할 수있는 여유를 두십시오
• 한 번에 큰 것을 구축하는 대신 작은 것을 구축하고 점진적으로 개선하십시오.
• 최종 사용자가 프로세스에 관여하도록하고 신속하고 정기적 인 피드백을받습니다.
• 자신의 작업과 진행 상황을 검사하고 실수로부터 배우십시오

이것은 정상입니다.

다음 두 가지 방법 중 하나를 수행 할 수 있습니다.

1. 환영합니다 변경

잘못 될 것이라고 생각되면 변경할 수있는 코드 기반을 구축해야합니다. 대부분 리팩토링에 대한 책 끝에서 코드를 가져 와서 처음부터 그런 방식으로 코드를 작성하는 것 (분해성, 테스트 범위 등)이 포함됩니다.

2. 변화를 피하십시오

이 경우 BDUF (큰 디자인 선결제)를 수행해야합니다. 많은 종이 프로토 타이핑을 수행하고, 고무 덕킹을 통해 잠재적 인 사용자 또는 자신과 아이디어를 논의하고, 프로토 타입 또는 모형의 다양한 것을 시도하고, 완전한 사양을 작성하고, 일단 솔루션을 중단했다고 생각하면 마지막으로 코딩을 시작할 수 있습니다. 실제로 예기치 않은 변경을 제거하지 않는 모든 작업을 수행하면 첫해 정도가 약간 줄어 듭니다. 따라서 변경하기 쉽도록 코드를 작성해야합니다.

기본적으로 변화는 주어진 것입니다. 일어날 것이라고 가정하십시오. 이에 따라 코드를 작성하십시오. 실제로, 분석 마비에 얽매이지 않고 무질서한 변화를 피할 수있는 디자인-업-프론트와 방금 시작-코딩 방식 사이의 중간 지점을 찾을 수 있습니다. 약간의 경험이 필요합니다.

소프트웨어 개발은 ​​본질적으로 "사악한"일련의 문제로 묘사되었습니다 .

Horst Rittel과 Melvin Webber는 "악한"문제를 해결하거나 문제의 일부를 해결하여 명확하게 정의 할 수있는 문제로 정의했습니다. 이 역설은 본질적으로 문제를 명확하게 정의하기 위해 문제를 한 번 "해결"한 다음 다시 해결하여 작동하는 솔루션을 만들어야 함을 의미합니다. 이 과정은 수십 년 동안 소프트웨어 개발에서 모성과 사과 파이였습니다.

이것은 당신이 직면하고있는 문제를 완벽하게 설명합니다. 기본적으로 우리가하는 일은 어렵습니다 . "루틴"이라고 설명 할 수있는 부품이 있으면 시간이 지남에 따라 부품을 분리하고 자동화합니다. 남은 것은 새로운 것이거나 어려운 것입니다.

이와 같은 문제를 극복 할 수있는 다른 방법이 있습니다. 어떤 사람들은 문제를 미리 고려하고 디자인에 익숙해 질 때까지 코드를 작성하지 않는 데 많은 시간을 보냅니다. 다른 사람들은 페어 프로그래밍이나 이와 같은 사이트를 통해 이미 이와 같은 문제를 처리 한 사람들의지도를 구합니다.

그러나 확실히 당신의 접근 방식이 무능함을 암시하지는 않습니다. 유일한 문제는 다시 돌아갈 때 처음부터 이런 식으로 물건을 선택하기로 한 이유와 " 고쳐 쓰기.

많은 경우에있어 다음에이를 설계 프로세스에 통합 할 수 있습니다. 경우에 따라 비용이 없었거나 (또는 ​​다른 접근 방식의 비용보다 높거나 높을 수도 있음) 걱정할 필요가 없습니다.

1. 예, " 대부분 의 코드 재 작성 "부분을 제외하고는 일반적 입니다. 처음부터 모든 요구 사항을 충족 할 수는 없으므로 변경을 잘 처리하는 것이 중요합니다. 이것이 바로 "코드 유지 관리 성"의 개념입니다. 물론 요구 사항과 디자인을 올바르게 작성하는 데 더 많은 시간을 할애 할 수 있습니다.
2. 먼저, 과거 프로젝트에서 어떤 변경이 필요한지, 어떻게 미리 예측했거나 더 잘 준비 할 수 있었는지 생각해보십시오. 프로젝트를 시작할 때 사용 사례에 대한 자세한 내용을 생각해보십시오. 구현을 시작하기 전에 추상적 인 디자인 (코드의 주요 구성 요소 및 통신 방법, API)을 수행하십시오. 가장 중요한 것은 코드를 가능한 한 간단하고 쉽게 변경하고 SOLID, DRY, KISS 및 YAGNI와 같은 개념을 읽으십시오.

그러한 관행은 일반적입니까, 아니면 내가 유능하지 않다는 것을 암시합니까?

그것들은 상호 배타적이지 않습니다. 패턴이 일반적 일 수 있으며 여전히 무능 할 수 있습니다. 목표에 대한 성과를 측정하여 역량을 결정할 수 있습니다. 목표를 달성하고 있습니까?

이 패턴이 일반적입니까? 불행히도, 그렇습니다. 많은 사람들이 어떤 문제를 해결하고 있는지, 올바른 솔루션을 어떻게 설계 할 것인지, 어떤 메트릭이 성공을 구성 할 것인지에 대한 명확한 아이디어없이 프로젝트에 참여합니다.

이 부분에서 어떻게 나 자신을 향상시킬 수 있습니까?

만약 당신이 어딘가에 가기로 결정하고 걷기 시작한 후, 정말로해야 할 일이 케이프 타운에서 뉴욕으로 코끼리를 옮기는 일이라는 것을 발견했다면, 걷는 데 소비 한 모든 시간이 낭비되었습니다. 시작하기 전에 수행중인 작업을 파악하십시오.

다시 시작하면 다시 작성할 필요 가없는 코드는 어떻게 생깁니 까? 그 코드 :

• 하나의 유용한 일을합니다.
• 올바르게합니까?
• 충분한 성능으로 수행합니까?

따라서 : 코드의 성능이 좋은 곳에서 코드가 유용한 기능을 제대로 수행할수록 더 많은 코드를 작성할수록 더 적은 코드를 다시 작성해야합니다.

나는 당신이 더 나은 작업 방법에서 멀지 않다고 말하는 것이 안전하다고 생각하며, 당신은이 보트에서 유일한 사람이 아닙니다.

내가 놓쳤다 고 생각하는 것은 원하는 것을 결정하더라도 어떻게 할 것인지에 대해 동일한 프로세스를 중단하지 않는다는 것입니다.

전체적인 문제를 해결하는 방법에 대해 멈추고 생각하는이 단계를 디자인이라고합니다. 시스템의 구조 나 아키텍처를 개발하는 데 시간을 소비하여 시스템에서 수행하는 모든 작업이 최종 솔루션에 기여하는 단계입니다. 일단 당신이 가장자리를 해결하면 직소 퍼즐에 조각을 맞추기.

많은 사람들 이이 단계를 수행하지 않지만 코딩을 시작했을 때 필수 단계였습니다. 차이점은 개발 도구에 있다고 생각합니다. 텍스트 편집기로 시작했지만 이제는 모든 종류의 기능을 사용하여 뛰어 넘을 수 있습니다.

따라서 약간의 시간이 걸리므로 넓은 영역, 구성 요소 및 이들 간의 상호 운용성을 파악하고 코딩을 시작하기 전에 솔루션을 구성 할 개체를 정의하십시오. 엄청나게 자세하게 설명 할 필요는 없으며 처음부터 완벽하게 구현할 수 없으므로 시간이 지남에 따라 진화 할 것입니다. 그러나 이것이해야 할 일은 다시해야 할 일에 대한 노력을 낭비하지 않도록하는 것입니다. t 많이 변경해야합니다.

당신은 이미 훌륭한 답변을 가지고 있지만 귀하의 질문은 내가 만질려고 생각한 몇 가지 사항을 염두에 둡니다.

1. 변경 사항이 적용되는 것을 언급했듯이 프로젝트가 프로젝트에 미치는 영향과 디자인 / 코딩 선택의 영향을 최소화하는 동시에 사람들이 종종 늦게 변경하는 위치에 대한 정신지도를 생성하는 방법에 대해 생각하는 것이 좋습니다. 경험이 있다면 중요하다고 생각되는 것들에 대해 약간의 유연성을 예상하고 코딩 할 수 있습니다. 그러나 일부는 특별히 요청하지 않은 영역에 투자하려는 노력을 반대 할 것이기 때문에 업계에서는이 개념에 대해 의견이 맞지 않습니다 .

2. 테스트 이해 관계자 중 하나는 프로젝트 이해 관계자를 위해 프로토 타입을 던지는 것이 요구 사항을 개선하는 좋은 방법이 될 수 있습니다. 그러나 개발 중에 많은 혼란이나 복잡성을 유발하지 않으면 서 코드에서 발생하는 상황을 "볼"수있는 방법을 찾을 수 있습니다. 확실히 도움이되는 도구가 있지만 원한다면 도구 없이도 많은 것을 할 수 있습니다. 어느 쪽이든, 비판적인 눈으로 일어나는 일을 살펴보기 위해 코드에서 나오면 다양한 유형의 통찰력을 제공 할 수 있습니다.

3. 일반적인 활동을 찾으십시오. 동일한 문제를 반복해서 처리하는 것을 알게 될 것입니다. 잠시 후 다양한 선택의 단점이나 단점을 발견하고이를 피할 수있는 방법론을 찾아야합니다. 물론 프레임 워크에서 작업하는 경우 이러한 문제 중 일부는 이미 사용중인 도구에 포함되어있을 수 있습니다.

4. 프레임 워크 내에서 작업하는 경우 시간을 할애하고 여유가 있다면 처음부터 작업을 수행하는 방법을 고려하십시오. 예를 들어, 요청 메시지를 쉽게 조립하고 소켓을 열고 GET 또는 POST 요청을 수동으로 발행 할 수 있습니다. 원하는 경우 XML 메시지를 수동으로 구문 분석 할 수 있습니다. 당신이 무엇을하든, 당신이 생성하는 질문과 당신이 찾은 답변은 당신의 기술을 키울 것입니다. 물론 어떤 유형의 근본적인 문제가 중요하거나 관심이 있는지 선택할 수 있습니다. 나는이 개인적인 발전을 고려하고 여기에 24 시간 많은 시간을 할애하지 않을 것입니다.

5. 실버 총알, 방법론 및 높은 버즈 팩터 문제는 어디에나 있습니다. 기본적으로 정보 작업의 기본 현실은 그렇게 빨리 변하지 않습니다. 프레임 워크, 툴셋 또는 방법론이 다양한 상황에서 도움이되는지 방해가되는지 확인하십시오. 대기업에서는 회사가 효과적으로 실행할 수 없었지만 많은 방법론이 시도 된 것을 보았습니다. 프레임 워크와 마찬가지로 방법론은 기능이 뛰어난 일부 팀의 사례를 기반으로하더라도 높은 수준에서 작동하는 안전한 방법이 아닙니다.

경험을 정리하고 접근하기가 어렵습니다. 이 모든 것을 넣을 수있는 짧은 방법은 눈을 뜨고보고있는 것에 대해 생각하며 배우는 것을 멈추지 않는 것입니다.

몇 가지 포인터를 추가하고 싶습니다

1) 개인적으로 시각화 로 시작하는 것이 매우 유용하다는 것을 알았습니다. 물건 . 상자, 화살표, 선 그리기 ... 사용하는 모델링 언어를 신경 쓰지 마십시오. 우선 당신은 당신 자신을 위해하고 있습니다. 생각의 흐름에 도움이됩니다.

2) 스파링 파트너 찾기 -커피와 플립 차트 / 다이어그램 등을 잡고 마을로 가십시오. IMHO 당신이 일치하는 기술 능력이 없다면 더 좋습니다. 유스 케이스 구현 아이디어를 앞뒤로 바운스합니다. 당신은 막 다른 길을 찾거나 해결책을 찾습니다. 민첩한 마음으로이 단계에서 코드를 작성하는 것보다 시간이 덜 걸리며, 작동하지 않으며 작업 덩어리를 죽이거나 다시 실행해야합니다.

3) 필기 소프트웨어를 개선 하지 않았 음을 이해할 수있는 상사를 찾으십시오 . 항상 책상에 버려지고 신경 쓰지 않는 새로운 기능 / 요구 사항을 연결하는 경우 소프트웨어를 하면 버그, 유지 보수 친숙 함 및 머리카락이 몇 년 동안 줄어드는 데 많은 도움이됩니다. 이 소프트웨어 유지 보수 시간 / 예산을 할당하십시오! 나는 좋은 둥근 마법의 숫자는 소프트웨어를 개발하는 데 필요한 시간의 약 20 %가 일생 동안 모양을 유지하기 위해 매년 필요합니다.

4)이 점진적 학습 과정은 결코 멈추지 않아야합니다. 당신은 10 년 후에 되돌아보고 미소를 지을 것입니다.

희망이 작은 행운과 행운을 빕니다!