나는 1 년 반 동안 앱 개발자로 일해 왔으며 (아는 길이는 멀다) 방금 첫 번째 큰 프로젝트를 받았다.

말할 것도없이 원활하게 진행되지 않았으므로 프로젝트에 참여하는 선임 프로그래머에게 접근 방법에 대한 조언을 구했습니다.

그는 현재 과제에 대해 과감하게 생각하고 있으며, 디자인 패턴을 생각하는 데 너무 많은 시간을 소비하기 전에이 규모의 프로젝트를 수행 한 적이 없기 때문입니다. 그의 현명한 말로, 그는 나에게 "미래를 위해 미래를 건설하라"고 말했습니다.

이와 같은 프로젝트를 진행할 때 프로그래머가 일반적으로 따르는 추세입니까? 예를 들어, 개념 증명 모델을 요청한 경우 가능한 한 빨리 실행 가능한 예제를 작성하는 것이 일반적인 추세입니까?

편집 :이 논쟁이 빛났다, 나는이 상황이 매우 극단적이라고 언급하고 싶습니다 : 우리는 통제 할 수없는 요인으로 인해 매우 마감 기한이 있습니다 (예 : 우리가 목표로하는 시장은 우리가 원하지 않으면 관심을 잃을 것입니다) '그들에게 무언가를 보여주지 말 것'과 그의 조언은이 특정 작업에 매우 효과적인 것으로 판명되었습니다.

구조에 명백한 선장!

캡틴이 될 것입니다. 여기에 중간 근거가 있습니다.

미래를 위해 구축하고 기술적 선택이나 나쁜 디자인에 얽매이지 않기를 원합니다. 그러나 단순해야 할 것을 설계하거나 수명이 2 년이고 후속 프로젝트가 거의없는 빠르고 더러운 앱의 확장 점을 추가하는 데 3 개월을 소비하고 싶지는 않습니다.

제품의 성공 여부를 항상 예측할 수는 없으며 나중에 제품을 확장해야하므로 차이를 찾기가 어렵습니다.

지금 구축하십시오 ...

• 프로젝트가 폐기 될 것입니다
• 프로젝트 수명이 짧다
• 프로젝트 확장이 없어야합니다
• 프로젝트에는 위험 영향 가치가 없습니다 (주로 이미지 측면에서)

일반적으로 현재 사내 프로젝트 나 고객을 위해 개발 된 것이 개발되어야합니다. 요구 사항이 정확해야하며 필요에 따라 필요하지 않은 것을 알아야합니다. "좋은 것"에 너무 많은 시간을 보내고 싶지 않습니다. 그러나 돼지처럼 코딩하지 마십시오.

필요할 때 노력할만한 가치가 있다면 나중에 일반 문제를 남겨 두십시오.

미래를 위해 건설

• 프로젝트는 공개됩니다
• 프로젝트는 재사용 할 구성 요소입니다
• 이 프로젝트는 다른 프로젝트를위한 디딤돌입니다
• 프로젝트는 개선 된 후속 프로젝트 또는 서비스 릴리스를 갖습니다.

대중을 위해 건축하거나 다른 프로젝트에서 재사용 할 계획이라면 나쁜 디자인이 다시 등장 할 가능성이 훨씬 높아 지므로 더주의를 기울여야합니다. 그러나 항상 보장되는 것은 아닙니다.

지침

다음과 같은 원칙을 최대한 준수하고 효율적이고 적응 가능한 제품을 설계해야합니다.

• 알고 YAGNI을 ,
• 키스 ,
• 가려움증을 긁고 추가를 생각할 때마다 적어 두십시오. 프로젝트 요구 사항을 되돌아보고 추가가 우선 순위인지 아닌지 스스로에게 물어보십시오. 그들이 주요 비즈니스 가치 를 추가하는지 묻습니다 .

나는 개인적으로 지나치게 생각하고 지나치게 설계하는 경향이 있다는 것을 알고 있습니다. 아이디어를 작성하는 데 도움이되며 추가 기능이 필요한 경우 종종 다시 생각하는 것이 좋습니다. 대답은 '아니오'또는 '나중에 시원 할 것'입니다. 그 마지막 아이디어는 내 머리 뒤에 머물러 있기 때문에 위험합니다. 나는 계획을 세우지 않도록 스스로를 강요해야합니다.

과도하게 엔지니어링하지 않고 나중에 스스로를 차단하지 않고 코딩하는 가장 좋은 방법은 최소한의 훌륭한 디자인에 집중하는 것입니다. 나중에 확장 할 수는 있지만 나중에 확장 할 수 있는 방법에 대해서는 생각하지 않고 구성 요소를 정리하십시오 . 미래를 예측할 수 없습니다.

간단한 것들만 만드십시오.

딜레마 타

오버 엔지니어링

이와 같은 프로젝트를 진행할 때 프로그래머가 일반적으로 따르는 추세입니까?

그럼 당연하지. 알려진 딜레마이며 제품에 대한 관심 만 표시합니다. 그렇지 않으면 더 걱정됩니다. 적은 것이 항상 더 많은지 아닌지, 더 나쁜 것이 항상 더 나은지에 대해서는 의견이 일치하지 않습니다 . 당신은 MIT 또는 뉴저지 종류의 사람 일 수 있습니다. 여기에 쉬운 대답이 없습니다.

프로토 타이핑 / Quick-n-Dirty / Less is more

가능한 한 빨리 실행 가능한 예를 없애는 것이 일반적인 추세입니까?

일반적인 관행이지만 대다수의 프로젝트에 접근하는 방식이 아닙니다. 여전히 프로토 타이핑은 제 생각 에는 좋은 경향이지만 평균 단점이 있습니다. 실제 제품에 대한 빠르고 더러운 프로토 타입을 홍보하거나 관리 압력 또는 시간 제약 조건에서 실제 제품의 기반으로 사용하려는 유혹이있을 수 있습니다. 그때 프로토 타이핑이 다시 당신을 괴롭힐 수 있습니다.

프로토 타이핑 에는 분명한 장점이 있지만 오용 및 남용 의 가능성이 많습니다 (이전에 언급 된 장점과 결과의 정확한 반대).

프로토 타이핑을 언제 사용해야합니까?

프로토 타이핑을 사용 하는 가장 좋은 유형의 프로젝트에 대한 힌트가 있습니다 .

[...] 프로토 타이핑은 사용자와 많은 상호 작용을하는 시스템에서 가장 유리합니다.

[...] 프로토 타이핑은 온라인 시스템의 분석 및 디자인, 특히 화면 처리 대화 상자 사용이 훨씬 많은 트랜잭션 처리에 특히 효과적입니다. 컴퓨터와 사용자 간의 상호 작용이 클수록 더 큰 이점이 있습니다 ...]

"현재까지 빠른 프로토 타입 제작의 가장 생산적인 용도 중 하나는 반복적 인 사용자 요구 사항 엔지니어링 및 휴먼 컴퓨터 인터페이스 디자인을위한 도구였습니다."

반면에 :

일괄 처리 나 계산을 주로 수행하는 시스템과 같이 사용자 상호 작용이 거의없는 시스템은 프로토 타이핑의 이점이 거의 없습니다. 때때로 시스템 기능을 수행하는 데 필요한 코딩이 너무 집중되어 프로토 타입이 제공 할 수있는 잠재적 인 이득이 너무 작을 수 있습니다.

주변에 녹색 괴물이 있다면 예산 내에서 프로토 타입을 유지하십시오 ...

프로그래밍을 시작할 때 모든 것이 자신에게 있어도 개념 증명입니다. 시간이 핵심 요소이기 때문에 아이디어에 빠르고 더러운 것이 있거나 프로토 타입이 필요한 경우가 있습니다. 개발자들 사이에서 큰 두려움은 작은 앱이 프로덕션을위한 준비가되어 있다고 생각하거나 영원히 같은 속도로 기능을 추가 할 수 있어야한다고 생각하는 이해 관계자들입니다. 당신은 큰 프로젝트에서 일하고 이것이 사실이 아니라는 것을 알게됩니다.

대규모 프로젝트에는 일반적으로 더 복잡한 요구 사항이 있으므로 복잡한 디자인을 시도하고 구현하려는 유혹이 있습니다. 당신은 그것들을 읽고 연구하고 구현하는데 많은 시간을 할애 할 것입니다. 이것은 큰 시간 낭비가 될 수 있지만, 학습과 경험의 전부입니다. 특정 디자인을 사용할시기를 아는 것은 어렵고 대개 경험이 있습니다. "this"프로젝트에서 "that"을 시도했지만 작동하지 않았지만 이제 "here"에서 작동해야합니다.

계획을 많이 세우고 계획해야하지만 한 번에하지 마십시오. 처음에 모든 것을 할 필요는 없습니다. 차라리 누군가가 다음과 같은 첫 번째 큰 프로젝트를 만드는 것을 보았습니다.

1. 조금 디자인하고 토론하십시오.
2. 무언가를하는 많은 코드를 작성하십시오.
3. 문제를 인식하고 코딩을 중지하십시오.
4. 디자인에 대해 진지하게 생각하고 모멘텀이나 코드 모조를 잃을 염려를 없애고 프로젝트 관리자를 무시하십시오 (당신이 호의적 인 일을하고 있습니다).
5. 프로젝트를 통제하십시오. 당신의 혼란을 해결하십시오. 모두가 계획을 이해하도록하십시오. 프로젝트를 통제하십시오.

때로는 기존 코드베이스에서 구현하는 방법에 대해 실제로 우려하는 기능 중 하나를 선택했습니다. 지금은 "그냥 작동"해야 할 때가 아닙니다. 나는 "때로는 망치 대신 의자를 잡아야한다"고 말한 보스가있었습니다. 그는 내 책상에서 "생각"을 잡은 후 나에게 이것을 말했다. 많은 상사 들과는 달리, 그는 내가 실수를했다고 가정하지 않았고 그가 더 많은 일을하기를 원한다는 것을 이해하게 만들었습니다. 천재.

궁극적으로 코드는 디자인입니다. 문서, 다이어그램, 회의, 이메일, 화이트 보드 토론, SO 질문, 논증, cussing, 격렬한 대화 및 커피를 통한 조용한 대화로 지원됩니다. 더 이상 디자인 할 수없고 코드를 작성하려고 할 때만 발견 할 수있는 결함으로 인해 더 많은 디자인 시간을 버릴 위험이 있습니다. 또한 코드를 많이 작성할수록 코드를 작성할 수없는 디자인 결함이 발생할 가능성이 높아집니다. 대변을위한 시간.

프로그래머는 일반적으로 미래에 대해 생각하지 않고 지금 작동하는 것을 구축합니까?

예.

그렇게해야합니까?

아니.

언뜻보기에 "미래에 대한 생각"은 KISS 및 YAGNI 와 같은 기존의 설계 원칙을 위반하는 것으로 보이며 , 현재 요구되지 않는 것은 구현해서는 안된다고 주장합니다.

그러나 실제로는 그렇지 않습니다. 미래를 생각한다는 것은 간단하고 확장 가능하며 관리 가능한 소프트웨어를 설계하는 것을 의미합니다. 이것은 장기 프로젝트에서 특히 중요합니다. 시간이 지남에 따라 새로운 기능이 필요하며 견고한 디자인으로 새로운 작품을 쉽게 추가 할 수 있습니다.

프로젝트를 완료 한 후에는 프로젝트를 진행하지 않더라도 지능적으로 개발해야합니다. 그것은 당신의 일이며 적어도 좋은 일이 얼마나 잘 이루어 졌는지 잊지 않기 위해 잘해야합니다.

민첩한 개발자는 "YAGNI (You Are n't Gonna Need it (YAGNI))" 라는 말을 통해 미래에 필요할 것으로 생각되는 것보다는 지금 필요한 것을 디자인하도록 권장합니다. 향후 작동하도록 설계를 확장하려면 권장 경로를 리팩터링하는 것이 좋습니다.

이에 대한 중요한 측면은 디자인 할 때 제품 요구 사항을 염두에두고 향후 발생할 수있는 요구 사항을 많이 설계하지 않도록하는 것입니다.

두세 번의 반복을 미리 생각할 수있는 개발자들에게는 고객이나 도메인을 잘 알고 있기 때문에 미래의 요구를 높은 정확도로 예측하고 구축 할 수 있지만 확실하지 않은 경우, 귀하 또는 고객이 필요로하지 않는 것에 너무 많은 시간을 소비하지 않는 것이 가장 좋습니다.

이와 같은 프로젝트를 진행할 때 프로그래머가 일반적으로 따르는 추세입니까?

멘토가 의미하는 바는 최종 솔루션에 필요하지 않은 추가 복잡성을 빌드하지 않아야한다는 것입니다.

앱이이 작업을 수행하고 대규모로 추적해야한다고 생각하는 것은 너무 쉽습니다.

디자인 패턴에 관해서는 디자인 패턴이 끝났다는 것을 기억할 가치가 있습니다. 경험에 따라 초기 디자인에도 불구하고 특정 디자인 패턴이 맞지 않으면 코드 냄새가 날 수 있습니다.

예를 들어, 개념 증명 모델을 요청한 경우 가능한 한 빨리 실행 가능한 예제를 작성하는 것이 일반적인 추세입니까?

프로젝트가 시작되기 전에 이정표가 무엇인지, 그리고 개발할 때 모든 부분 (수직 조각) 또는 각 부분을 자세히보고 싶어하는지 (수평 조각) 여부를 판단하는 것이 좋습니다. 초기 디자인의 일환으로 전체 앱에 스토리를 적용 할 가치가 있으므로 코드가 작성되지 않았더라도 전체 내용에 대한 헬리콥터보기 또는 주어진 영역에 대한 심층 다이빙을 할 수 있습니다.

그는 내가 겪고있는 과제에 대해 과감하게 생각하고 있었고, 이와 같은 큰 프로젝트를 수행 한 적이 없었기 때문에 디자인 패턴을 생각하는 데 너무 많은 시간을 소비했을 것이라고 말했다. 그의 현명한 말로, 그는 나에게 "미래를 위해 미래를 건설하라"고 말했습니다.

다른 개발자의 카우보이 정신이라고 생각합니다. "지금하고있는"터프한 머저리의 현대판. 그것은 스타트 업들 사이에서 인기있는 주제가되었으며 페이스 북 사람들이 "올바르게하는 것보다 낫다"라는 문구를 시작한 것에 대해 감사하지 않습니다.

매력적입니다. 시간이 지남에 따라 예산과 예산에 맞춰 프로젝트를 시작할 때 콘솔을 둘러싼 개발자의 비전을 제시합니다.

이상적인 환상이며 인생은 이런 식으로 작동하지 않습니다.

바보는 단지 "그것을"하고 끝낼 수 있다고 생각하는 프로젝트에 돌입 할 것입니다. 성공은 보이지 않는 도전에 대비하고 자신의 직업을 훌륭한 장인 정신으로 대하는 개발자에게 유리할 것입니다.

모든 선임 개발자는 비판, 비난 및 불만을 제기 할 수 있습니다.

그 / 그녀는 당신이 프로젝트를 "과도하게 생각하고있다"고 말합니다. 실제로 "생각"을 먼저 축하합니다. 당신은 다른 사람보다 더 나은 개발자가되기위한 첫 걸음을 내딛었습니다.

이와 같은 프로젝트를 진행할 때 프로그래머가 일반적으로 따르는 추세입니까? 예를 들어, 개념 증명 모델을 요청한 경우 가능한 한 빨리 실행 가능한 예제를 작성하는 것이 일반적인 추세입니까?

이것이 바로 개념 증명입니다. 사람들이 한 발짝 물러서서 볼 수 있도록 가능한 빨리 물건을 으깨려고 시도합니다. 실수, 잘못된 방향 및 시간 / 돈 낭비를 방지하기 위해 수행되었습니다.

개념 증명에는 여러 가지 종류가 있습니다. 완료되면 쓰레기통에 버리는 물건을 만들거나 프로젝트의 시작점을 나타내는 것을 만들 수 있습니다. 그것은 모두 당신이 필요로하는 것과 개념이 최종 제품에 얼마나 가까운 지에 달려 있습니다.

또한 아이디어를 보여줄 수있는 기회이기도합니다. 예상치 못한 수준으로 물건을 가져간 프로토 타입을 발표 한 적이 있습니다.

디자인은 일반적으로 개방형이므로 너무 많거나 적게 적용하기가 너무 쉽습니다. 그리고 프로젝트가 완료되거나 폐기 된 후에 만 ​​정확한 금액을 알 수 있습니다. 아니면 그때도 아닙니다.

성공을위한 일반적인 레시피는 없지만 극단적 인 인식을 배울 수 있습니다. 거의 모든 것을 완벽하게 설계하는 것은 사소한 것 이상으로 작동하지 않습니다. 정제를 위해 구성품을 남겨 두어도된다는 느낌이 들거나 문제를 조기에 발견 할 수있는 방법이 있습니다.

익숙하지 않은 경우 증분 개발의 작동 방식을 찾을 수 있습니다 . 성공적인 방법은 일반적으로 하나 이상의 수준에서 반복적이며 엄격한 피드백을 찾고 일부 골격에서 성장합니다.

계획을 중지하고 코딩을 시작하기위한 조언을 듣는 몇 가지 이유가 있습니다.

1. 개발자로서 18 개월 만에 대학 GPA에 관계없이 미래를 제대로 계획 할 가능성은 거의 없습니다. 이것은 밝지 만 경험이 부족한 개발자가 파악하기가 매우 어렵습니다. 모르는 것을 모르는 것이 전부이기 때문입니다. 노련한 사람들은 당신의 비전에서이 약점을 인식했을 것입니다.

2. 젊은 개발자는 코딩을 시작하기 전에 디자인을 완성하는 데 집착 할 수 있습니다. 코드 작성에 대한 두려움 (성능 불안)을 다루거나 코더 블록 (작성자 블록)이있을 수 있습니다. 필요한 작업 결과물이 없기 때문에 디자인에 집중합니다. 젊은 개발자는 아마도 그들이 "무서워"한다는 제안에 화가 나게 반응 할 것입니다. 어쩌면 프로젝트가 끝났을 때 그들이 그렇다는 것을 알게 될 것입니다. 걱정하지 않고 코딩을 얻는 것에 대한 조언은 코더 블록의 유일한 알려진 치료법입니다. 노련한 사람이이 조언을 현명하게 제공 할 수 있습니다.

3. 일정이 열악한 상황에서는 프로젝트를 수행 할 수있는 기회가 제한적입니다. 계획이 너무 길면 계획이 아무리 좋더라도 계획을 제 시간에 실행할 수 없으며 시장에 진출 할 수 없습니다. 처음부터 해킹을 시작하면 운이 좋을 것입니다. 기적적으로 제품을 제공합니다. 또는 운이 좋지 않고 반 구운 슬래그 조각을 배달하지만 제 시간에 시장에 나와 무언가를 배울 수 있습니다. 아니면 실패 할 수도 있습니다. 그러나 "아마도 실패"는 너무 오래 계획했기 때문에 "시장에 진출하지 못한 것"보다 여전히 더 나은 가능성입니다. 주요 이해는 기회가 처음부터 제한되므로 해킹으로 아무것도 잃지 않는다는 것입니다. 귀하의 관리자는 성공 가능성이 거의 없음을 알고 학습 자원으로 주니어 자원을 배정했습니다. 우리는 성공보다 실패에서 더 잘 배웁니다. "전체 프로젝트는 언제 할 수 있습니까?"

내성적이며 자아가없는 개발자는 자신의 결함을 볼 수 있으므로 나머지 부분을 읽기 전에 잠시 명상하여 자신의 약점을 간과 할 수있는 변명을하지 않도록하십시오.

모든 개발자가 분석, 계획 및 사고가 필요한 기타 작업에 특히 능숙하지는 않습니다. 생각은 어렵고 icky입니다. 그것은 땀을 흘리게하는 일종의 정신적 땀을 필요로합니다. Monster의 두 캔으로 흐름 상태에 들어가는 것만 큼 재미없고 바위가 크게 코딩, 코딩, 코딩되었습니다. 생각하고 싶지 않은 개발자는 계획이 좋은 아이디어라는 견해에 저항 할 것입니다. 초기 계획이 필요없는 개발 방법론을 권장합니다. 그들은 계획을 강조하지 않는 회사와 관리자를 좋아합니다. 그들은 계획하지 않은 비용이 너무 높지 않은 작업에 끌립니다. 그들은 밤새 코딩 세션을 소중하게 생각하고 버그로 인해 전체 비즈니스가 다운 된 고객에게 핫픽스를 제공합니다.

어떤 개발자들은 데모를하기에 충분히 효과가있는 것을 얻는 것이 완벽하고 모든 상황에서 작동하게하는 것이 지연 될 수 있으며 다른 개발자에게 밀려날 수도 있다는 것을 깨달았습니다.

이미 페이스 북에 침입하기 전까지는 트렌드를 파악할 수없는 관리자가 있습니다. 할인 타이어 상점을 관리하는 직업을 찾는 대신이 관리자는 금요일까지 실행되는 코드가 필요하다는 문제를 일으 킵니다. API를 디자인하거나 알고리즘이 확장 가능한지 테스트해야한다는 말을 듣고 싶지 않습니다. 이것은 그들에게 기술 점보 점보입니다. 고객이 파일을 전송할 수 있도록 펄 스크립트를 작성할 때 소프트웨어에 대해 모두 이해했기 때문에 코드 작성을 권장합니다. (그들은 첫 판매 직종에서 '소프트웨어 엔지니어'라는 제목을 가졌습니다. 소프트웨어가 너무 지루하고 힘들다는 것을 누가 알았습니까?)

코드를 보여 주시면 본인이 누구인지 알려 드리겠습니다

귀하의 코드는 방문 카드입니다. 지저분한 코드를 작성하면 다른 사람들에게 자신에 대해 무엇을 말합니까? 그냥 생각 해봐 우리가 사무실에서 아주 나쁜 코드 조각을 발견 할 때마다, 우리는 누가 그것을 작성했는지 그리고 어떻게 그가 대학을 통과 했는가?

당신은 당신이 코딩하는 것이되고있다

당신의 코드는 평생 프로그램입니다.

나쁜 코드를 작성하는 프로그래머는 스트립 클럽에서 춤을 추는 발레 댄서와 같습니다.

어떤 사람들은 스트립 클럽에서 춤을 좋아하지 않습니다. 그러나 그들이 무용수라면 기술을 낭비하고 있습니다. 댄서가 좋지만 다리가 좋으면 많은 것을 벗길 수 있습니다.

마지막으로, 당신은 고골의 소설 '초상화 (The Portrait)'를 읽고, 주인공의 이야기에 경고를 받아야합니다. 당신은 친구가 초상화에서 남자와 비슷합니다. 그는 돈으로 당신을 유혹하고 있지만, 당신은 그것을 위해 높은 가격을 지불합니다.