제안 된 디자인은 일반적으로 동료보다 나쁩니다. 어떻게하면 더 나아질까요? [닫은]

나는 몇 년 동안 프로그래밍을 해왔으며 일반적으로 문제를 해결하고 중소 규모의 스크립트를 만드는 데 능숙하지만 일반적으로 객체 지향 방식으로 대규모 프로그램을 설계하는 데 능숙하지 않습니다. 몇 가지 질문

1. 최근에 나와 같은 경험을 가진 동료 가 문제를 해결하고있었습니다. 나는 그보다 더 긴 문제에 대해 연구하고 있었지만 더 나은 해결책을 찾았고 결국 우리는 그의 디자인을 사용할 것입니다. 이것은 정말로 나에게 영향을 미쳤다. 나는 그의 디자인이 더 낫다는 것을 인정하지만, 그의 것만 큼 좋은 디자인을 만들고 싶었다. 나는 직장을 그만 둘 생각하고있다. 왜 그런지 모르지만 갑자기 압력이 가해진 것 같은 느낌이 들었습니다. 예를 들어 주니어가 저를 어떻게 생각할까요? 정상입니까? 아니면 이것에 대해 너무 많이 생각하고 있습니까?

2. 내 직업은 파이썬 프로그래밍과 관련이 있습니다. 소스 코드를 읽으려고하는데 어떻게하면 디자인 기술을 향상시킬 수 있다고 생각합니까? 공부해야 할 좋은 책이나 소프트웨어가 있습니까?

제발 깨달아 줘 도와 주셔서 감사합니다.

나는 이것이 당신의 기술의 매우 긍정적 인 신호라고 생각합니다. 팀에서 '더 나은'디자인을 찾는 데 어려움을 겪는 사람들이 다른 디자인이 더 나은 이유를 완전히 인식 할 수없는 경우가 훨씬 흔합니다.

당신에게는 두 가지 위대한 (그리고 놀랍게도 드문) 강점이 있습니다 :

• 당신은 객관적으로 다른 사람에 대한 디자인을 평가할 수 있습니다
• 당신은 당신의 디자인을 최적으로 만들기위한 열망과 노력을 기울입니다.

당신은 불과 몇 년 만에 갈 길이 멀지 만, 이런 태도로 당신은 분명히 거기에 갈 것입니다. 포기하지 마십시오. 우리는 모두 이와 같은 정신적 장애를 처리합니다. 디자인 원칙 과 동일하지는 않지만 디자인 원칙 을 연결 하는 것이 좋을 때마다 이것이 유용한 방법의 완벽한 예라고 생각합니다. 그것들을 연구하고 당신의 디자인에 적용하는 것을 연습하십시오.

하루가 끝나면 디자인이 어렵다는 것을 기억하십시오. 우리는 매일 복잡한 높은 수준의 추상화를 처리하고 있으며, 얇은 공기에서 생성하고, 잘 작동하며, 동료가 사용하기 쉬운 것은 매우 어려운 작업입니다. 몇 년 동안 연습이 필요합니다 .

따라서 두 개의 디자인을 평가할 수없고 실제로 하나를 다른 것보다 선호하는 것으로 인식 할 수있는 많은 사람들이 있습니다. 좋은 디자인을 만드는 데 얼마나 잘 대처하고 있다고 생각하십니까?

편집 :
'또 다른 팁, 원리에 대해 머리를 숙이고 응용 프로그램을 약간 연습 한 후에 다른 질문과 다른 목적과 규칙을 가진 다양한 언어를 연구하는 것의 가치에 대해 이야기하는 다른 보석이 있다고 생각합니다.

이상적으로 모든 프로그래머는 각 클래스의 언어를 알아야합니다. 무엇을 배울 수 있습니까?

1. 정적 유형의 OOP 주류 언어 : Java, C # (대부분 엔터프라이즈 소프트웨어에서 사용) 및 C ++ (시스템 프로그래밍 및 복잡한 데스크탑 애플리케이션)
2. 프로토 타입 기반 OOP 언어 : Javascript (클라이언트 측 웹 프로그래밍)
3. 절차 적 언어 : C (내장 소프트웨어 및 시스템 프로그래밍)
4. 기능적 언어 : Haskell, ML 또는 Lisp (기능적 언어는 고도로 병렬화 된 소프트웨어에 적합합니다).

논리 프로그래밍 언어 (Prolog)는 아마도 AI에서 연구에 주로 사용되는 산업에서는 그다지 유용하지 않을 것입니다.

이는 솔루션을 설계 할 때 떠오르는 다양한 아이디어를 넓히는 데 도움이됩니다.

1. 여러 사람이 서로 다른 품질의 디자인을 생각해내는 것은 절대적으로 정상적인 일입니다. 나는 과거에 소프트웨어 디자인의 경쟁을 평가하도록 초청 받았으므로이 사실을 직접 목격했습니다. 가장 단순한 디자인조차도 똑똑하고 경험이 풍부한 사람들이 제공하는 매우 다른 품질의 솔루션을 만들어 냈습니다.
2. 소스 코드를 읽는 것이 너무 낮아서 디자인 기술을 향상시킬 수 없습니다. 코드는 전체 디자인보다 낮은 수준의 복잡성을 해결합니다.

소프트웨어 설계에서 개선하는 가장 좋은 방법은 소프트웨어를 설계하는 것입니다 ^* . 이를위한 한 가지 방법은 디자인 경쟁을 살펴 보는 것입니다. TopCoder에는 100 개 이상의 구성 요소 디자인의 아카이브가 있으며 Java 및 / 또는 C #에서 UML 디자인 문서 및 구현으로 완성됩니다. 원하는 완성 된 구성 요소를 선택하고 요구 사항 사양을 읽은 다음 요구 사항을 충족시키기 위해 독창적 인 디자인을 생각해보십시오. 문제에 대해 1 시간 또는 2 시간 동안 생각하고 수업 다이어그램을 스케치 한 다음 수상 경력에 빛나는 디자인을 열고 작가가 한 일을 읽으십시오. 그의 디자인을 당신의 것과 비교하고, 차이점을 발견하고, 당신의 디자인이 더 나은지 확인하십시오. 심사 위원이 디자인을 평가 한 방법을 보려면 경쟁 스코어 카드를 확인하십시오. 이를 통해 설계 기술을 향상시키는 방법을 결정하는 데 필요한 피드백을 얻을 수 있습니다.

일을 그만 두지 마 당신보다 더 나은 기술을 가진 사람과 함께 일하는 것이 좋습니다.

더 나은 디자인을보고 더 좋은 이유를 결정하십시오. 수용된 디자인을 배우고 다른 상황에서 단순한 디자인을 적용 할 수있는 방법에 대해 생각하십시오. 왜 그것이 디자인보다 나은지 알면, 다음에 디자인 할 때 어떤 미스 태크를 만들지 않는지 알 수 있습니다. 다른 개발자와 이야기하고 디자인을 어떻게 구했는지 물어보십시오.

디자인 기술을 향상 시키려면 가장 좋은 방법은 디자인을 만든 다음 평가하고 개선 방법을 결정하는 데있어 자신에게 잔인한 것입니다. 다음과 같은 질문을 해보십시오. 작동하고 모든 측면에서 요구 사항을 충족합니까? 유지 관리가 가능합니까? 어떻게 테스트 할 수 있습니까? 성능 문제가 발생할 수 있으며 변경 요구 사항이 얼마나되며 디자인이 얼마나 좋을까요? 변화를 다룰 수 있습니다. 디자인 패턴에 대해 읽고 디자인에 적용하십시오. 초기 디자인을 만든 후 무자비하게 리팩터링하십시오. 응용 프로그램과 함께 데이터베이스를 디자인하는 경우 db 정규화 및 성능 조정에 대해 자세히 읽으면 데이터베이스를 가장 효과적이고 효율적으로 만드는 방법을 배우면 데이터베이스 디자인에 대해 많이 배울 수 있습니다. 응용 분야의 경우 설계 수행시 DRY 및 SOLID 원리를 고려하십시오. 반 패턴에 대해 읽고 피해야 할 일을 알아보십시오.

더 나은 디자인을 인식하는 것은 중요한 능력입니다. 디자인을 보는 것과 관련된 이전 제안 중 일부를 따를 때이를 권장해야합니다.

다른 디자인을 어떤 기준으로 더 잘 판단 했습니까? 더 간단하고 이해하기 쉬웠습니까? 성능 이점을 제공 했습니까? 더 확장 가능 했습니까? 분해, 추상화, 정보 숨기기 및 구성 요소 모듈화와 같이 설계를 판단하고 이미 인식 할 수있는 많은 설계 원칙이 있습니다.

• 기준의 이름을 정하고 이해하고 확장하고 다른 디자인을 보면서 재사용하십시오. 직접 디자인 할 때는 이러한 기준을 사용하고 의도적으로 디자인을 측정하는 프로세스의 일부로 만드십시오. 그런 다음 기준에 맞지 않으면 디자인을 완전히 수정하거나 버릴 준비를하십시오.

다음 소스 중 일부에서 디자인에 대한 다양한 원칙에 대한 아이디어를 얻을 수 있습니다. http://www.cs.wustl.edu/~schmidt/PDF/design-principles4.pdf Wikipedia의 소프트웨어 디자인 Google "소프트웨어 디자인 원칙"

• 객체 지향 설계 또는 기능 설계 또는 구조 분석 설계와 같은 소프트웨어 설계에 대한 다양한 모델을 이해합니다. 이들은 디자인 작업에 접근 할 수있는 완전히 다른 사고 방식이 될 수 있으며 각자 뛰어난 영역을 가지고 있습니다. 툴박스를위한 도구로 배우십시오. http://userpages.umbc.edu/~khoo/survey2.html

• 디자인을 구현에서 분리하고, 우수한 디자인으로 보이는 것을 다이어그램으로 표현하고, 언어 및 구현 세부 사항을 상위 레벨 디자인 원칙과 분리하십시오. 그리고 "디자인 아이"와 커뮤니케이션 능력을 개발하십시오.

• 마지막으로, 아마도 가장 중요한 것은 넓게 읽는 것이 매우 좋은 도구입니다. Fractals에서 Bayesian 분석, Fuzzy Logic에서 Natural Language Processing에 이르기까지 흥미로운 것들이 많이 있습니다. 웹을 사용하면 즐거움과 교양을 위해 주제를 광범위하고 광범위하게 파악할 수 있으며 이점이 있습니다. 용어와 아이디어에 익숙해 져 전문가가 될 필요는 없습니다.

재미있게 보내십시오-적어도 조금이라도 즐기지 않으면하지 마십시오!

글쎄, 당신은 이미 첫 단계를 밟았습니다. 배우고 싶은 것이 있고, 동료의 일이 나보다 낫다는 것을 인정하고 배우고 향상 시키려고합니다.

두 번째 단계는 분석하는 것입니다. 그의 작품을보고 더 좋다고 말하지 마십시오. 왜 더 좋은지 알아 내십시오 . 그가 더 잘한 구체적인 세부 사항과 요점을 찾으십시오.

일단 이해하면 그 뒤에있는 원칙을 추출하십시오. 다음과 같은 질문을하십시오.

• 이 디자인은 내 디자인보다 낫습니까?
• 이 점이이 디자인과 관련이 있습니까, 아니면 나중에 다른 디자인에 적용될 수있는 일반적인 원칙입니까?
• 일반적인 원칙이라면 그 한계는 무엇입니까? 때 그것은 좋은 생각이 없는 일이 방법을 수행하는? (이것은 매우 중요합니다. 부적절한 경우에도 유용한 아이디어를 황금 망치 로 취급하지 못하게합니다 .)

스스로 결론을 내릴 수있는 추론 체인을 생각해 내면 아이디어를 더 잘 내재화 할 수있을뿐만 아니라 동료와 대화하여 물건을 얻었는지 확인해야합니다. 권리. (당신은 추론에서 실수를 저지르고 나쁜 원칙을 내면화하고 싶지는 않습니다.) 그리고 일을 알아낼 수 없다면 동료에게 도움을 요청하십시오. 프로그래밍은 겸손이 존중되는 분야이며 많은 코더가 누군가에게 새로운 것을 가르 칠 기회에 뛰어 넘을 것입니다. 아마도 StackOverflow가 그렇게 빨리 커지는 이유의 큰 부분 일 것입니다.

또한 "그보다 나보다 나은 디자인을 만들 수 있습니다"보다 더 많은 답변이 있습니다. 다른 답변은 Design에서 어떻게 더 나아질 수 있는지에 초점을 맞추고 있습니다.

나는 당신이 당신의 동료보다 더 나은 것을 할 수 있다는 것을 내기했습니다. 성냥이나 다른 것을 만들지 말고 (Y 더 잘할 수 있습니까? 당신을 조이십시오. X를 더 잘 할 수 있습니다!) 모든 사람이 강점과 약점을 가지고 있다는 사실을 지적하십시오.

제 직업에는 4 명의 개발자가 있습니다. 두 명의 "프로그래머"가 먼지 속에 나를 버리는 물건을 만들 수있는 경우가 있습니다. 내 머리를 회전시켜 창조물 주위로 머리를 감싸려고한다.

그러나 나는 SQL과 명령 줄 스크립팅보다 훨씬 뛰어나며, 먼지를 남기는 것들을 자동화 할 수 있습니다.

그들이 나보다 낫습니까? 어떤 지역에서는 확실합니다. 지옥, 많은 지역에 있습니다. 저는 제 상점의 저급 개발자이며 개인적으로 저에게 수년간의 경험이 있습니다. 그 수년간의 경험에도 불구하고, 나는 심지어 어떤 지역에서는 그들보다 더 낫습니다.

누군가 X가 당신보다 낫다는 사실에 집중하지 마십시오. 그 사람은 시도하거나 생각하지 않고 향후 10 년 동안 연습 한 후에도 당신을 능숙하게 설계 할 수 있습니다. 당신이 약점을 고치기 위해 노력해서는 안되지만, 모든 힘에 대해 약점이 있다는 것을 기억하십시오.

당신과 동료의 강점과 약점 모두에 중점을 둡니다.

인생의 모든 측면에서 당신은 특히 "2 년"의 경험 후에 당신보다 더 나은 사람들뿐만 아니라 당신보다 더 나은 사람들을 찾을 것입니다.

당신은 모든 사람에게서 배워야합니다.

기분 나빠하지 마십시오. 어쩌면 당신은 동료가 자연 스럽습니다. 그를 진심으로 축하하고 최대한 많은 것을 배워야합니다.

전문가가 당신과 배울 기회 사이에 질투하게 가지 않도록하십시오.

1. 몇 년은 실제로 그렇게 많지 않습니다. 더 우수하거나 최악의 디자인 뷰를 가진 사람들이 있습니다. 예를 들어, 눈을 번쩍이면서 낮은 수준의 프로그램을 위해 복잡한 알고리즘을 작성할 수 있지만 응집력 및 종속성과 같은 높은 수준의 디자인과 개념을 이해할 수는없는 사람들을 알고 있습니다. 그러나 이것은 사실상의 상태가 아닙니다. 둘 다 더 높은 수준의 디자인 (몇 권의 책을 읽고 집에서 몇 가지 트릭을 시도하는 등)을 향상시킬 수 있으며 프로그래밍의 다른 영역에서 동료 프로그래머가 덜하다는 것을 알 수 있습니다. 또한 경험과 기술 지식 모두에서 같은 수준에 있다고 생각하면 빈이 무작위로 발생했을 수 있습니다. 다음에는 더 나은 디자인 아이디어가 있습니다. 또한 직업을 포기하지 말고이 기회를 잡고 동료로부터 배우십시오. 다음에는 함께 디자인을하세요 그의 비밀, 생각을 잡으려고 노력하십시오. 프로그래밍은 공예와 같습니다. 다른 사람들이하는 것을보고 배우면서 배웁니다.

2. 디자인 기술은 대부분 경험이 풍부하고 몇 가지 중요한 책을 읽은 후에 제공됩니다. 다음을 추천합니다.

   • Robert C. Marting-민첩한 원칙, 패턴 및 실습 (Java 및 C #의 두 가지 버전이 있습니다. 어떤 버전을 선택하든 상관없이 아이디어 지향과 원칙을 모든 객체 지향에 적용 할 수 있습니다. - 소스 코드)
   • Robert C. Marting에게는 Clean Code와 The Clean Coder라는 두 가지 흥미로운 책이 있습니다.
   • Martin이 첫 번째 책에서 모든 현대적인 디자인 패턴을 다루더라도 Gang of Four의 원본 디자인 패턴 책을 찾아보고 싶을 것입니다.
   • 마지막으로 오늘 높이 평가되는 다른 책들도 있습니다 : 테스트를 통해 성장하는 객체 지향 소프트웨어 또는 M. Feathers의 리팩토링 (제 생각에) 또는 A. Cockburn의 효과적인 유스 케이스 작성 등 몇 가지 더 많은 것들이 있습니다.

이 책들 중 어느 것도 마법의 총알은 아니지만 처음 두 가지 권장 사항을 읽으면 프로그래밍에 대한 견해와 인식이 영원히 바뀌게 될 것입니다.

그것이 당신에게 도착하게하지 마십시오. 버그를 수정하고 작은 프로그램을 만드는 데 수년간의 경험이 있다면 그 점이 탁월한 것입니다. 동료는 아마도 더 큰 프로젝트를 설계 한 경험이 있습니다.

기본 비트에 익숙해지는 것이 매우 유용하지만 디자인을 더 잘 활용하려면 몇 가지 프로젝트를 디자인해야합니다. 기술이 흡수 될 때까지 반복하십시오.

간단히 말해서 "경험 년"이 항상 동등한 것은 아닙니다. 몇 년 동안 가치있는 것을 만들어보십시오.

"더 나아진다"는 디자인이나 코드를 더 나은 사람이나 다른 사람과 비교하여 측정하고, 차이점을주의 깊게 비교하고, 이러한 차이점을 배우고,이를 바탕으로 미래 디자인을 지속적으로 개선하려고 시도하는 것을 의미합니다. 더 많은 것을 배워야한다는 사실을 알게되면이 유익한 과정이 느려질 것입니다. 때때로 또는 항상 더 나은 비교를 제공 할 수있는 사람 (또는 다른 자원)이없는 곳으로 이사하면,이 기회를 잃고 더 나은 베팅 과정을 늦출 수 있습니다.