프로젝트는 거의 완료되었지만 절차 적 스파게티 코드입니다. 다시 쓰거나 계속 배송하려고합니까? [닫은]


242

저는 초보자 웹 개발자입니다 (1 년의 경험).

졸업 한 지 몇 주 후, 소유자가 기술 전문가가 아닌 회사를 위해 웹 응용 프로그램을 작성하는 작업을 제안했습니다. 그는 자신의 아이디어 도용, 서비스 회사가 부과하는 높은 개발 비용을 피하고 장기적으로 프로젝트를 유지하기 위해 신뢰할 수있는 젊은 사람을 고용하기 위해 저를 모집했습니다. ).

내가 컴퓨터 과학에 졸업장을 가지고 돌아 왔을 때, 우스꽝스러운 나는 무엇이든 만들 수 있다고 생각하는 제안을 받아 들였다.

나는 총에 전화했다. 몇 가지 연구를 한 후 PHP를 결정하고 일반 PHP로 시작했습니다. 개체가없고 추악한 절차 적 코드였습니다. 두 달 후 모든 것이 지저분 해져서 발전하기가 어려웠습니다. 웹 응용 프로그램은 거대합니다. 그래서 나는 내 인생을 편하게 해줄 MVC 프레임 워크를 확인하기로 결정했습니다. 그곳에서 PHP 커뮤니티의 멋진 아이 인 Laravel을 우연히 발견했습니다. 나는 그것을 좋아하고 배우기 쉬웠으며 즉시 코딩을 시작했습니다. 내 코드는 더 깔끔하고 체계적으로 보입니다. 매우 좋아 보였다.

그러나 다시 웹 응용 프로그램은 거대했습니다. 회사는 저에게 첫 번째 버전을 제공하도록 압력을 가하고 있었으며,이 버전은 분명히 배포하고 고객을 찾고 싶었습니다.

라 라벨은 함께 일하는 것이 즐거웠 기 때문에 내가 왜이 산업을 선택했는지 기억 나게했습니다.

그래서 밤에 소규모 프로젝트를 시작하면서 방법론과 모범 사례에 대해 읽었습니다. 나는 OOP를 다시 검토 설계 및 분석을 객체 지향에 이동, 읽기 삼촌 밥의클린 코드 .

이것은 내가 정말 아무것도 몰랐다는 것을 깨닫는 데 도움이되었습니다. 소프트웨어를 올바르게 구축하는 방법을 몰랐습니다. 그러나이 시점에서 너무 늦었고 이제 거의 끝났습니다. 내 코드는 전혀 깨끗하지 않고 스파게티 코드, 버그를 해결하기위한 진정한 고통, 모든 논리가 컨트롤러에 있으며 객체 지향 디자인이 거의 없습니다.

나는 전체 프로젝트를 다시 작성해야한다는 지속적인 생각을 가지고 있습니다. 그러나 나는 그것을 할 수 없습니다 ... 그들은 언제 다 끝날지 묻습니다.

이 코드가 서버에 배포 된 것을 상상할 수 없습니다. 또한 코드 효율성과 웹 응용 프로그램의 성능에 대해서는 아직 아무것도 모릅니다.

한편으로 회사는 제품을 기다리고 있으며 더 이상 기다릴 수 없습니다. 반면에 실제 코드로 더 이상 나아갈 수는 없습니다. 나는 마무리하고 마무리하고 배치 할 수 있지만 신은 사람들이 그것을 사용할 때 일어날 수있는 일만을 알고 있습니다.

다시 쓰거나 계속 배송하려고합니까, 아니면 놓친 다른 옵션이 있습니까?


142
시작한대로 마무리하고 다음 버전에서 기술 부채를 정리하십시오 (있는 경우). 당신의 상사는 그 차이를 알지 못할 것입니다. 잘 테스트하십시오.
Robert Harvey

45
"하지만 신은 사람들이 그것을 사용하기 시작할 때 일어날 수있는 일만 알고 있습니다."... 소프트웨어 개발의 재미입니다. 더 잘 익숙해

144
이것은 당신이 만든 모든 단일 시스템입니다.
Dismissile

57
소프트웨어는 결코 완성되지 않으며, 일단 가까워지면 항상 전체 코드베이스를 창 밖으로 던져 버리는 통찰력을 갖게됩니다. 하지마 작동하는 제품을 제공 한 다음 리팩토링 기술을 숙달하십시오. 귀중한 교훈이 될 것입니다.
Pieter B

14
아버지는 "때로는 엔지니어를 쏘고 배를 쏴야한다"고 말 했어요.
corsiKa

답변:


253

당신은 대부분의 CS 교육의 아킬레스 건을 우연히 발견했습니다. 그들은 당신에게 도구와 기술을 가르치지 만 거래는하지 않습니다. 소프트웨어 제작은 수년간의 실습과 소프트웨어 사용 경험을 통해서만 얻는 기술입니다 (사용자는 교사보다 훨씬 더 비판적입니다). 소프트웨어 구축은 비즈니스 목표가 기술 목표를 무시할 수있는 비즈니스이기도합니다.

우선, 배. 비즈니스 소유자에게 소프트웨어를 보여주고 배송 할 준비가되었다고 생각되면 배송하십시오. 그 시점이 아니지만 닫으면 마무리하십시오. 중요한 소프트웨어는 실제로 사용되는 소프트웨어입니다. 돈을 버는 유일한 소프트웨어 사업은 제품이있는 사업입니다.

둘째, 당신은 많은 귀중한 것들을 배웠으므로 그것이 배운 것에 대한 경험에 감사해야 합니다 .

  1. 계획이나 아키텍처가없는 코드를 슬링하는 것은 재난의 요리법입니다
  2. 코드 작성보다 프로그래밍에 더 많은 것이 있습니다
  3. 비 기술적 비즈니스 소유자는 종종 기술 결정 (임직원 등)의 영향을 이해하지 못하며,이를 설명하는 것은 개발자의 몫입니다.
  4. 기존 프레임 워크에서 대부분의 문제는 이미 해결 한 것보다 훨씬 잘 해결되었습니다. 존재하는 프레임 워크와 사용시기를 알아야합니다.
  5. 지도가 거의없는 큰 프로젝트에 배정 된 신입생은 스파게티 코드 한 그릇을 생산하는 경향이 있습니다. 이것은 정상입니다.

다음은 진행 방법에 대한 조언입니다.

  1. 의사 소통, 의사 소통, 의사 소통 확실하지 않고 여러 경로를 보더라도 프로젝트 상태와 진행 방법에 대한 아이디어에 대해 매우 개방적이고 솔직해야합니다. 이로 인해 비즈니스 소유자는 수행 할 작업을 선택할 수 있습니다. 자신에게 지식을 간직 할 경우 선택권을 박탈 당하게됩니다.
  2. 완전한 재기록의 유혹에 저항하십시오. 다시 쓰는 동안 비즈니스에는 제품이 없습니다. 또한, 재 작성은 당신이 상상했던 것만 큼 좋은 것으로 밝혀지지 않습니다. 대신 아키텍처를 선택하고 코드베이스를 점진적으로 마이그레이션하십시오. 이런 식으로 끔찍한 코드베이스조차도 구제 될 수 있습니다. 리팩토링에 관한 책을 읽고 도움을 받으십시오.
  3. 자동 테스트 / 단위 테스트에 대해 알아보십시오 . 코드에 대한 신뢰를 쌓아야하며이를 수행하는 방법은 자동화 된 테스트로 코드를 처리하는 것입니다. 이것은 리팩토링과 함께 진행됩니다. 테스트를하지 않는 한 수동적이고 포괄적으로 테스트하십시오 (사용자가 그렇게하기 때문에 코드를 위반하십시오). 찾은 모든 버그를 기록하여 우선 순위를 정하고 수정할 수 있습니다 (모든 버그를 수정할 시간이없고 실제 버그가없는 소프트웨어는 제공되지 않습니다).
  4. 웹 애플리케이션을 배치하고 계속 실행하는 방법에 대해 학습하십시오. Web Operations : Data On Time 책 은 좋은 시작입니다.

4
비 기술적 인 비즈니스 사람들은 마음에 드는 것을 가지고 있으며 기술적 인 것을 이해하지 못합니다. 기술적으로 실행 가능한 옵션에 비용과 이점을 제공하는 것은 개발자의 몫입니다.
Jan Hudec

1
전체 재 작성이 적절한 상황 중 하나입니다. 기본적으로 첫 번째 버전을 교육 도구로 사용하는 경우 두 번째 버전은 "필자가 작성한 버전"이됩니다. 다른 모든 경우에는 다시 쓰기가 좋지 않은 조언이지만 여기서는 아닙니다. 코드를 작성한 사람은 자신이 무엇을하고 있는지 알지 못합니다. 그것을 고치는 것은 또 다른 훌륭한 훈련 기회가되어야합니다!
gbjbaanb

2
"모든 프로덕션 코드는 적어도 한 번은 다시 작성됩니다."라는 이론이 있습니다. 지금까지 나의 전문적인 경험에서, 그것은 매크로 (건축) 및 마이크로 (방법) 수준에서 꽤 사실이었습니다. 트릭은 이러한 리 팩터가 적절한 경우 학습 합니다.
zourtney

11
첫 번째 포인트 만 +1 모든 사람을 기억, 배송 너무 기능입니다 .
thegrinner

5
당신의 부가 사이트를 좋아한다면, 완료된 것입니다. 당신의 상사는 싸고 새로운 대학 졸업생을 고용했습니다. 그는 자신이 무엇을 받을지 알았거나 교육을받을 자격이있었습니다. 소프트웨어에 버그가 있습니다. 함께 살아라. 우리 모두가 할. 당신은 1 년 전보다 더 똑똑합니다. 인상을 요청하거나 새로운 직업을 찾으십시오 (둘 다 좋습니다). 새로운 일자리를 찾는다면 좋은 습관을 습득 할 수있는 팀과 함께 고용주를 선택하십시오.
SeattleCplusplus

114

이것은 나에게 던져진 다른 모든 시스템처럼 들린다.

긴장을 푸십시오. 이것은 많은 사람들에게 발생합니다. 경험이없고, 도움이없고, 지원이없고,지도가없는 깊숙한 곳에 던져진 주니어는 성공을위한 레시피가 아닙니다. 주니어 프로그래머가 잘 작동하고 성능이 우수하며 유지 보수가 가능한 새로운 시스템을 처음부터 새로 구축 할 것을 기대하고있는 것은 현실적이지 않습니다. 선임 프로그래머에게 이런 일이 생기면 운이 좋을 것입니다.

제 생각에는 깨끗해야합니다. 재미 없을 것입니다. 그들에게 당신이 최선을 다했다고 말하지만, (대부분은) 효과가 있지만, 성능이 좋지 않을 수도 있고 많은 버그가있을 것이라고 걱정합니다 ( 항상 버그가 있습니다). 상급 프로그래머가 검토해야하며 눈에 띄는 성능 / 보안 문제를 매우 빠르게 해결할 수 있어야합니다. 또는 그것을 배치하고 손가락을 교차시킬 수 있습니다. 괜찮아 지거나 연기로 올라갈 것입니다. 문제가 발생할 때 문제를 해결할 수 있습니다. 큰 사용자 기반이 있다면 아닐 수도 있습니다.

또는이 상황에서 대부분의 사람들이하는 일을 할 수도 있습니다. 돈을 가져 가서 사라지게하십시오. 윤리적 인 선택이 무엇인지 해결하기 위해 당신에게 맡길 것입니다.

편집 (이 질문에 많은 투표권이 있으므로 내용을 더 추가 할 수도 있음)

프로그래머가되는 기쁨의 일부는 비 기술적 인 사람들 (아마도 당신의 관리자, 나머지 사업)은 당신이 무엇을하는지 전혀 모른다는 것입니다. 이것은 좋고 나쁘다. 나쁜 점 중 하나는 소프트웨어 개발 프로젝트의 작동 방식을 지속적으로 설명해야한다는 것입니다. 계획, 요구 사항, 코드 검토, 테스트, 배포 및 버그 수정 테스트의 중요성을 설명하고 테스트 할 시간을 따로 두는 것이 귀하의 임무 입니다. 당신 여기에 당신의 입장을 견뎌야합니다. 사람들은 그 중요성을 이해하지 못할 것입니다 ( "우리는 그것을 사용할 수 없습니까?") (실제 환경이 아닌) 테스트를 시작하면 이점을 빠르게 이해할 수 있습니다. 그들이 당신을 고용 한 이유 중 하나는 소프트웨어 개발에 대해 아무것도 모르기 때문에 교육하는 것은 당신에게 달려 있습니다. 테스트와 버그 수정의 중요성을 강조해야합니다. 프로그래머는 아니고 0으로 나누기와 깨진 html 태그의 차이점을 모릅니다.

종종 발생하는 많은 문제는 실제로 버그가 아닙니다. 유용성 문제, 누락 된 요구 사항, 변경된 요구 사항, 사용자 기대치 (내 모바일에서는 이것을 사용할 수없는 이유) 및 실제 실제 버그가 될 것입니다. 라이브로 가기 전에 이러한 문제를 해결해야합니다. 며칠 후 많은 버그가 해결되거나 수정 될 수 있습니다. 사람들이 완벽한 시스템을 원한다면 많은 고통을 겪을 것입니다. 그들이 버그를 기대하고 있다면 앞으로 몇 주 동안 인생이 훨씬 쉬워 질 것입니다.

아, 그리고 사용자 테스트를 단위 테스트 나 시스템 테스트와 혼동하지 마십시오.

  • 단위 테스트-내 코드 함수가 올바른 값을 반환합니까?
  • 시스템 테스트-X를 클릭하면 오류가 발생합니다
  • UAT (사용자 승인 테스트) – 프로그램이 요구 사항을 준수합니까? 그들이 요청한대로합니까? 생방송 할 수 있습니까?

그들이 당신에게 요구 한 것들의 요구 사항을 기록하지 않았다면 UAT 는 훨씬 더 어려울 것입니다. 이곳은 많은 사람들이 쓰러지는 곳입니다. 그들이 시스템에 원하는 것을 종이에 적어 놓으면 인생이 훨씬 쉬워집니다. 그들은 "왜 X를하지 않습니까?"라고 말할 것입니다. "당신은 나에게 Y를 시키라고 말 했어요." 프로그램이 틀렸다면 수정하십시오. 요구 사항이 잘못된 경우 문서를 수정하고 하루나 이틀을 요청 (아니오, 고집)하고 변경하고 문서를 업데이트 한 후 다시 테스트하십시오.

이 과정을 몇 차례 거치면 애자일을 조사 할 수 있습니다.

TL; DR 테스트는 좋습니다


7
진실하고 전형적인. 나는 떠나는 것이 분명히 윤리적이라고 말하고 싶습니다. 프로젝트에서 인력을 관리하는 것은 새로 온 주니어 학생들의 문제가 아니기 때문에 누군가가 그 때문에 떠나면 절대 이해할 것입니다.
CsBalazs 헝가리

1
대부분의 사람들이 돈을 가지고 사라진다는 것을 인정하여 +1. 이런 일이 컨설턴트를 업무에 유지시키는 것입니다.
James_pic

여기서 좋은 테스트 정의는 아닙니다. 단위 테스트는 단위의 기술 사양을 확인하고 통합 테스트는 엔드 투 엔드 시스템의 기술 사양을 확인하고 수락 테스트 ( "사용자"유무에 관계없이)는 제품의 비즈니스 사양을 확인합니다. "시스템 테스트"는 단위 테스트 이외의 거의 모든 것을 의미 할 수 있습니다. 반환 값을 확인하는 것이 단위 테스트에서 항상 필요하거나 도움이되는 것은 아니며, 시스템이 "오류를 발생"하는 경우에만 자동 UI 테스트가 제대로 수행되지 않는 경우는 거의 없습니다.
Aaronaught

"테스트의 중요성을 설명하고 테스트 할 시간을 정하는 것이 당신의 임무입니다." 저는 '실제'프로그래머는 아니지만 선반 작업자가 기계에 다이얼 캘리퍼 세트를 가지고 있지 않은 경우이를 설명 할 수있는 가장 좋은 방법입니다. 그가 자신이 잘못한 것을 알게 된 유일한 방법은 QC가 그것을 확인하고 그에게 잘못되었다고 말하는 것입니다. QC가없고 단위 테스트가없는 경우 부품을 맹목적으로 가공하여 문 밖으로 보내는 것과 같습니다. 다른 산업과 마찬가지로-제품을 테스트 할 방법이 없다면 배송 대상 제품이 제대로 작동하는지 알 수있는 방법이 없습니다.
user2785724

@ user2785724-코드를 작성하는 경우 실제 프로그래머입니다. 어쩌면 경험이 적더라도 코더가 더 적지는 않습니다.
Rocklan

61

처음부터 시작할 때마다 Second System Syndromme 으로 인해 거의 같은 양의 실수가 발생합니다 . 새로운 실수는 다를 수 있지만 디버깅에 필요한 시간은 비슷하므로 적합하지 않은 방법에 대해서는 절망합니다. 또한 첫 번째 버전이 배포 된 경우 프로덕션 또는 새로운 기능의 배포로의 배포가 지연 되어 회사에 심각한 문제 가 될 수 있습니다 . Joel Spolsky는 회사 나 개발자가 할 수있는 "단일 최악의 전략적 실수"라고 말합니다.

권장되는 방법은 유지 관리 중에 초기 엉망을 조금씩 정리하는 것입니다. 그리고 그것을 위해서만 리팩토링하지 마십시오. 또한 관리자는 일반적으로 돈 낭비라고 생각하며 새로운 버그가 발생할 위험이 불필요합니다. 코드를 고통스럽게 디버깅하면 예쁘지 않지만 작동합니다. 따라서 다른 이유로 인해 버그 수정, 새로운 기능 또는 마케팅에서 요청한 변경 등의 이유로 터치해야 할 때까지 기다리십시오. 그런 다음 조정하기 어려운 부품을 청소하십시오. 이것을 보이 스카우트 규칙 이라고합니다 .

그 시점에서 관리자와 논의 할 필요가 없습니다. 요청 견적에 원하는 최소 리팩토링을 포함하십시오. 회사가 실제로 고치기 때문에 비트를 생산할 여유가있을 때와 미래에 문제를 일으키고 싶지 않고 빠르게 해킹 할 가능성을 인정하지 않을 때 경험을 통해 배울 수 있습니다.

마지막으로, 조금 더 권장되는 독서 : 진흙큰 공 .


1
+ long.MaxValue는 대한 c2.com/cgi/wiki 나는 종류의 죽은 것 같습니다에도 불구하고, 해당 사이트를 사랑 해요.
AnotherUser

4
나는 Joel Spolsky에 대해 들어 본 적이 없지만 그의 블로그 게시물을 읽는 데 시간을 보냈습니다. 그는 절대적으로 재밌고 분명히 지식이 풍부합니다.
Adam Johns

9
@AdamJohns :하지만 당신은 그의 소프트웨어를 사용하고 있습니다. 지금. 그는이 사이트의 주요 인물입니다.
Jan Hudec

1
@ JanHudec 그와 Atwood.
jpmc26

5
마지막으로, 누군가 다른 사람 이 사이트를 방문하시기 이전 Spolsky 들어 본 적이. 여기에서 당신은 그가 재림이라고 생각할 것입니다.
MDMoore313

29

처음 읽은 부분을 잊어 버렸지 만 다른 사람들이 말한 것을 다소 강력하게 반향하고 싶었습니다.

배송은 기능입니다.

완벽하게 작동 하는 기존 코드 (해킹, 못생긴, 더러워진)를 "정리"하는 사람보다 새로운 버그를 도입 하는 것보다 더 나쁘지는 않습니다 . 당신은 그렇게했습니다. 배. 보기 흉한 환경에서도 완벽하게 작동하는 프로젝트의 재 설계에서 길을 잃지 마십시오. 수정하면 점진적으로 수정하고 가능한 한 적은 회귀를 가질 수 있도록 좋은 테스트 스위트로 만드십시오.


그것이 원본인지 확실하지 않지만, 이 기사 는 첫 번째 Google 인기 기사로 제공됩니다. 물론 Joel은 (주제에 대해 꽤 많이 작성했으며 꽤 잘 작성했습니다).
Jan Hudec

24

모든 프로젝트는 예전보다 똑똑해집니다. 모든 프로젝트 후에는 더 많은 경험을 쌓았을 것입니다. 나는 모든 것을 다시 방문하고 배운 것을 적용하기가 어렵다는 것을 알고 있습니다. 하지만 기억해:

완전은 선의 적입니다.

클라이언트에게는 결코 출시되지 않는 완벽한 소프트웨어보다 좋은 소프트웨어를 항상 갖추는 것이 좋습니다.

이것은 단지 첫 번째 프로젝트였습니다. 앞으로 배운 모든 것을 처음부터 적용 할 수있는 더 많은 프로젝트가있을 것입니다.


15

나는 [...] 삼촌의 밥 깨끗한 코드를 읽었습니다.

나는 전체 프로젝트를 다시 작성해야한다는 지속적인 생각을 가지고 있습니다.

이 책에는 "하늘의 재 설계"라는 제목의 섹션이 있습니다.

당신이 그것을 만들 시간이 없을 것 같은 경우에도, 당신은 어쨌든 같은 문제에 직면 할 것이기 때문에 모든 것을 다시 쓰려고하지 마십시오. 재 설계를 마치면 새로운 것을 배웠고 첫 번째 부분이 매우 전문적이지 않다는 것을 깨달을 것이므로 다시 작성하고 싶을 것입니다.

재 설계 및 재 작성은 작업 시스템에서 점진적으로 수행되는 경우에만 좋습니다. 다른 사용자가 지적했듯이, 보이 스카우트 규칙에 따라 작업하면서 코드를 조금씩 리팩터링하십시오.


6
사실입니다. 나는 같은 코드베이스의 디자인을 10 년 동안 반복 해 왔으며 작년에 만든 아키텍처는 여전히 엉망이라고 생각합니다. 당신은 학습을 멈추지 않습니다.
Joeri Sebrechts

1
명확하게 말하면, 점진적 개선이 가능한 이유는 기존 기능을 중단하지 않는다는 확신을 줄 수있는 테스트 배터리를 보유하고 있다는 것입니다. "변경할 수 없습니다"라고 생각하면 테스트 범위가 필요한 곳을 식별 한 것입니다.
PhilDin

9

잘하고 있어요

당신은 당신의 코드가 작동한다고 말하면 거의 준비가 되었습니까? 그리고 코드가 크게 향상 될 수 있다고 생각합니다. 좋은.

당신의 딜레마는 프리 랜싱에 대한 나의 첫 경험을 생각 나게합니다. 나는 코드에 결코 만족하지 않고 확장 성을 원했고 더 나은 바퀴를 재발 명하고 싶을 때 끝없는 질문을 겪었습니다. 일단 당신이 물건을 배포하면 여전히 많은 교정, 테스트, 패치 등이 필요합니다 ...

전문적인 코드 기반 작업 경험이 있습니까? 많은 코드 기반은 기발하고 코드를 유지하기가 어렵습니다. 큰 프로그램을 직접 구축하여 소프트웨어의 복잡성을 발견하는 대안은 다른 사람들이 작성한 엉망인 코드를 유지 / 확장하는 것입니다.

내가 완전한 재 작성을 보았던 유일한 경우는 팀이 새로운 툴체인 / 프레임 워크를 동시에 채택했을 때입니다.

기본 논리 (프로그램이 수행하는 기능, 함수, 클래스 등으로 배치되는 방법이 아니라 ...)가 소리가 들리면 제대로 작동하므로 스파게티 코드라고 생각하지 않습니다. 배포해서는 안됩니다.

고객이 사용할 수있는 것을 갖도록해야합니다. 그런 다음 고객에게 개선 / 기능 추가를 요청하면 리 팩터가 필요한지 여부를 결정하고 고객에게 "새 기능을 통합하려면 일부 기술 작업이 필요합니다"라고 알릴 수 있습니다. 이를 통해 더 많은 비용이 소요되며 더 오래 기다려야한다는 것을 이해하게 될 것입니다. 그리고 그들은 이해할 것입니다 (또는 당신은 철수 할 수 있습니다).

모든 것을 다시 쓰는 더 좋은 시간은 다른 고객이 비슷한 것을 만들도록 요청할 때입니다.

요컨대, 모든 것이 배포되면 모든 사람의 얼굴에 날려 버린다는 것을 입증 할 수 없다면, 배포를 지연시키는 것은 전문가가 아니며 귀 하나 귀하의 고객에게 이익이되지 않을 것입니다. 버그를 수정하거나 새로운 기능을 추가하면서 작은 리팩터링을 배우는 것은 귀중한 경험입니다.


7

귀하의 질문에 대한 답변으로 제가 말하고자하는 대부분의 사람들은 다른 사람들에 의해 언급되었습니다. Joel Spolsky ( "아키텍처 우주 비행사"에 관한 다른 글과 함께)의 "당신이 절대로하지 말아야 할 것들"을 읽으십시오. "완벽은 선의 적"이라는 것을 기억하십시오. 점진적으로 리팩토링하는 법을 배우십시오. 배송이 중요합니다.

내가 추가 할 것은 이것입니다 : 당신은 작은 시작 예산 / 기간으로 일하는 하나의 신선한 졸업생이 할 수 있다고 생각한 일을 맡았습니다. 우수하고 체계적이며 절차적인 프로그래밍보다 더 정교한 것은 필요 하지 않습니다 . 그리고 참고로 "프로 시저 프로그래밍"은 나쁜 단어가 아닙니다. 대부분의 경우 어느 수준에서 필요하며 전체 프로젝트에 전체적으로 적합합니다.

실제로 체계적이고 절차적인 프로그래밍을 수행 하십시오 . 코드 반복이 반드시 웅장한 다형성 구조가 필요하다는 신호는 아닙니다. 반복되는 코드를 가져 와서 서브 루틴에 넣어야한다는 신호일 수 있습니다. "스파게티"제어 흐름은 단순히 글로벌을 제거 할 수있는 기회 일 수 있습니다.

다형성, 구현 상속 등 을 합법적으로 요구 하는 프로젝트 측면이 있다면 프로젝트 의 크기가 과소 평가되었을 수 있습니다.


4
스파게티 코드는 절차 코드에만 국한되지 않는다고 덧붙입니다. 다형성과 상속을 잘못 사용하면 많은 복잡한 절차 적 조각보다 이해하기가 훨씬 더 어려워 질 수 있습니다. 제어 흐름이 잘못 정의 된 프로 시저를 사용하거나 복잡한 클래스 계층 구조에서 상속을 사용하여 모든 곳에서 점프하는지 여부는 중요하지 않습니다. 그것은 여전히 ​​도처에 뛰어 오르고 따르기가 어렵다.
Jan Hudec

4

실제로 딜레마에 관심이 있다면 "Lean Startup"도 읽어보십시오. 당신이 여기에 주어진 많은 조언들은 당신이 그 책을 읽으면 더 공감할 것입니다. 기본적으로 자원 연소율 은 최악의 적이며 최종 사용자 / 고객 피드백보다 귀하와 조직에 더 가치있는 것은 없습니다 . 따라서 제품을 실행 가능한 상태 (최소 실행 가능 제품-또는 MVP)로 가져온 다음 코드의 실제 모양에 관계없이 제품을 배송하십시오. 고객이 다른 방식으로가 아니라 향후 변경 사항과 버전을 지시하게하십시오. 당신이 그 접근법에 집중한다면 당신과 당신의 상사는 모두 더 행복 할 것입니다.


4

다른 사람들이 철저히 설명한 이유 때문에 프로젝트를 끝내고 배송해야 할 때가 있습니다.

테스트 도 " 마침 "의 일부 라는 점을 강조하고 싶습니다 . 중요한 기능 중 일부가 철저하게 실행되지 않고 올바른 결과가 확인되면이 앱을 배포 할 때 사람들이이 앱에 문제를 겪게 될 것이라는 우려가 정당합니다.

단위 테스트 및 자동화 된 고급 테스트는 훌륭하며이 응용 프로그램을 리팩터링 (또는 다시 작성)하기 전에 가능한 한 많이 있어야합니다. 그러나 모든 테스트를 "손으로"실행하고 "눈으로"올바른 기능을 확인해야하더라도 지금 당장은 주로 테스트 해야합니다 . 나중에 해당 테스트를 자동화하는 방법을 알아낼 수 있으면 다음 버전의 제품에서 작업을 시작할 때 도움이됩니다.

어떤 사람들은 알파 테스트 사용자로서 새로운 소프트웨어 프로젝트 앞에 앉아 잘못을 저지르는 요령을 가지고 있습니다. 즉, 그들은 일을 깨뜨리는 데 능숙합니다. 그런 재능있는 사람이 당신과 함께 일할만큼 운이 좋으면, 먼저 앱을 시험해 보도록해서 명백한 버그를 조기에 해결할 수있는 기회를 가지십시오. 이 작업을 직접 수행해야하는 경우 :

  • 체계적입니다.
  • 모든 기능을 시도하십시오.
  • 당신은 당신의 응용 프로그램에 경험이 사용자 인 척. 어리석은 실수를 저지르고 소프트웨어가 그 실수를 어떻게 처리하는지보십시오.
  • 문제를 해결했다고 생각한 후에 다시 시도 할 수 있도록 수행중인 작업을 적어 두십시오.

나는 진심으로 이것에 동의합니다. 프로덕션 환경에서도 수동으로 테스트하는 것을 잊지 마십시오. 개발 환경에서 수행 한 테스트의 양에 관계없이 모든 배포 후 항상 실제 환경에서 테스트를 수행해야합니다. 동료에게 도움을 요청할 수 있습니다.
윌 셰퍼드

1

귀하의 질문은 "잘못된 시작, 다시 시작해야 함"이라고 말하지만 추가 텍스트에는 실제로 "완료된 프로젝트이지만 다시 시작하면 잘못되었습니다"라고 표시됩니다. 질문 헤드 라인에만 해당 : 수행 한 프로그래밍 작업의 양이 필요한 총 작업에 비해 적 으면 모든 단계에서 시작하는 것이 좋습니다. 문제가 복잡하고 잘 이해되지 않을 때 많은 일이 발생하며 문제가 실제로 무엇인지 알아내는 데 상당한 시간이 걸립니다. 나쁜 시작을 계속하는 것은 아무 의미가 없습니다. 이번에는 문제를 잘 이해하고 버리고 완전히 시작하면 실제로 더 빨리 끝낼 수 있습니다.


0

이것이 제가 개인적으로하는 일입니다.

  1. 종료하고 변명하고 포기하십시오 (나쁜 것처럼 보이지 않도록 급여의 일부를 다시 줄 수도 있습니다)
  2. 가능한 한 코드를 청소하십시오
  3. 좋은 디자인, 좋은 아이디어 등 작업의 모든 좋은 부분에 대한 문서를 작성하십시오.

왜 내가이 모든 것을 당신에게 제안합니까?

미래에 대해 생각하기 때문입니다. 앞으로 특정 사람들이이 코드를 보유 할 시간이있을 것입니다. 그들은 당신과 당신의 능력에 대한 모든 종류의 가정과 판단을 할 것입니다. 그들은 당신이 그것을 쓸 때 상관하지 않으며, 상황을 걱정하지 않습니다. 그들은 확인하고 싶은 것을 확인하기 위해보고 싶은 것을보고 싶어합니다.

당신은 나쁜 이름, 그들이 당신에게 부정적인 영향을 줄 수있는 용어로 브랜드가 될 것입니다. 그리고 미래의 기술 능력, 기술, 지식, 스타일 측면에서 당신과 완전히 다를 수 있지만 상황이 너무 다를 지라도이 코드는 가능한 모든 방법으로 당신에게 불리하게 사용될 것입니다. 그것은 그들이 당신과 당신의 코드와 디자인에 관한 모든 나쁜 것을 말할 수있는 법정과 같습니다. (그리고 당신은 그들이 반복해서 깊이 틀렸다는 것을 매우 자주 배울 수 있습니다.) 그러지 마십시오. 포기 해

날 믿으십시오. 당신이 어떤 순간에 어떤 목적 으로든 무언가를했기 때문에 당신에 대해 많은 가정을 한 사람들이 있습니다. 그들에게 상황 A에서 이것을 좋아한다면 상황 B에서 그렇게 할 것입니다. 그들은 매우 간단하다고 생각합니다.


0

두 가지 제안, 나는 당신이하지 않은 이들 중 적어도 하나를 내기합니다.

1) 버그 추적기를 제자리에 놓고 상사에게 가르쳐주세요. 이것은 당신이 망친 방법, 더 잘 배우고 계획된 방식으로 고칠 방법에 대한 대화의 일부가 될 수 있습니다.

2) 버전 관리를 시작하십시오.

작은 계정에서 위의 두 가지를 모두 무료로 제공하는 호스팅 시스템이 많이 있습니다. 나는 특히 FogBugz를 좋아하는데, 이는 훌륭한 추정 및 작업 완료 시스템을 갖추고있어 상사가 당신이 잘 관리 된 방식으로 물건을 다루고 있음을 더욱 확실하게 줄 것입니다.

편집하다

와우, 누군가 정말 싫어했습니다-downvote 및 삭제 플래그? 왜?

나는 많은 컨설팅 작업을 포함하여 다른 사람들의 코드를 물려받은 것을 포함하여 30 년 동안 소프트웨어를 개발해 왔습니다. 내가 본 많은 문제 시스템은 사람들이 구덩이를 파고 그곳에 어떻게 도착했는지 또는 버전 관리가 없었는지에 대한 자세한 메모가 없었습니다.


-2

귀하의 질문에 대답하기 위해 : 다른 많은 사람들이 말했듯이, 아닙니다. 버그를 수정하는 과정에서 배송하고 비트 단위로 정리하십시오.

또한, book / StackExchange / webforums는 훌륭한 학습 자료이지만 다른 프로그래머와의 작업 (또는 토론)을 통해 얻을 수있는 학습과 일치하는 내용은 없습니다. 당신이 사용하고 있거나 배우고 자하는 기술을 위해 지역 그룹을 찾아 참석하는 것은 당신의 훌륭한 투자입니다. 기술 지식을 습득 할뿐만 아니라 향후 네트워크를 기대할 때 귀중한 네트워크 연결 방법이기도합니다.


-2

상사는 그가 당신을 고용했을 때의 경험 수준을 알고있었습니다. 걱정을 표명하고 신경이 쓰이는 것을 알려주십시오. 또한 배운 내용과 다음 프로젝트를 얼마나 잘 수행 할 수 있는지 알려주십시오.


-2

당신은 조언을 해줄 좋은 개발자가없는 초보 웹 개발자입니다. 당신의 상사는 이것을 완전히 아는 당신을 고용했습니다. 나는 당신이 누군가가 당신이 기대할 수있는만큼 잘하고 있다고 생각합니다. 실제로, 당신은 일이 더 나았을 수 있다는 통찰력을 가지고 있고, 더 잘 할 수있는 것들을 실제로 배웠다는 사실은 대부분보다 더 잘하고 있다는 것을 의미합니다. 일을 시작한 당신의 버전은 더 잘 할 수 없었습니다. 더 많은 경험이 있고 (따라서 더 나은 급여를받는) 사람이나 하나의 프로젝트 경험이있는 사람이 더 잘했을 수 있습니다.

무엇을 지금 : 당신이 년 전보다 더 나은 개발자 행복합니다. 다음 프로젝트는 더 잘할 것입니다 (그리고 결국에는 더 많은 경험을하고 당신이 한 일에 만족하지 않을 것입니다. 정상입니다). 마지막 프로젝트를 변경하거나 다시 작성하면 비용에 거의 이점이 없습니다. 당신이 할 수있는 일은 어쨌든 변경해야 할 때 나쁜 코드를 좋은 코드로 대체하는 것입니다. 유지 관리하기 어려운 코드를 수정하는 것이 좋은 코드로 바꾸는 것보다 어려울 수 있기 때문에 이치에 맞습니다. 그리고 경험이없는 새로운 개발자가 도움을받는다면, 코드는 복사해야 할 예제가 아니라고 알려주십시오 .

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