저는 초보자 웹 개발자입니다 (1 년의 경험).
졸업 한 지 몇 주 후, 소유자가 기술 전문가가 아닌 회사를 위해 웹 응용 프로그램을 작성하는 작업을 제안했습니다. 그는 자신의 아이디어 도용, 서비스 회사가 부과하는 높은 개발 비용을 피하고 장기적으로 프로젝트를 유지하기 위해 신뢰할 수있는 젊은 사람을 고용하기 위해 저를 모집했습니다. ).
내가 컴퓨터 과학에 졸업장을 가지고 돌아 왔을 때, 우스꽝스러운 나는 무엇이든 만들 수 있다고 생각하는 제안을 받아 들였다.
나는 총에 전화했다. 몇 가지 연구를 한 후 PHP를 결정하고 일반 PHP로 시작했습니다. 개체가없고 추악한 절차 적 코드였습니다. 두 달 후 모든 것이 지저분 해져서 발전하기가 어려웠습니다. 웹 응용 프로그램은 거대합니다. 그래서 나는 내 인생을 편하게 해줄 MVC 프레임 워크를 확인하기로 결정했습니다. 그곳에서 PHP 커뮤니티의 멋진 아이 인 Laravel을 우연히 발견했습니다. 나는 그것을 좋아하고 배우기 쉬웠으며 즉시 코딩을 시작했습니다. 내 코드는 더 깔끔하고 체계적으로 보입니다. 매우 좋아 보였다.
그러나 다시 웹 응용 프로그램은 거대했습니다. 회사는 저에게 첫 번째 버전을 제공하도록 압력을 가하고 있었으며,이 버전은 분명히 배포하고 고객을 찾고 싶었습니다.
라 라벨은 함께 일하는 것이 즐거웠 기 때문에 내가 왜이 산업을 선택했는지 기억 나게했습니다.
그래서 밤에 소규모 프로젝트를 시작하면서 방법론과 모범 사례에 대해 읽었습니다. 나는 OOP를 다시 검토 설계 및 분석을 객체 지향에 이동, 읽기 삼촌 밥의 책 클린 코드 .
이것은 내가 정말 아무것도 몰랐다는 것을 깨닫는 데 도움이되었습니다. 소프트웨어를 올바르게 구축하는 방법을 몰랐습니다. 그러나이 시점에서 너무 늦었고 이제 거의 끝났습니다. 내 코드는 전혀 깨끗하지 않고 스파게티 코드, 버그를 해결하기위한 진정한 고통, 모든 논리가 컨트롤러에 있으며 객체 지향 디자인이 거의 없습니다.
나는 전체 프로젝트를 다시 작성해야한다는 지속적인 생각을 가지고 있습니다. 그러나 나는 그것을 할 수 없습니다 … 그들은 언제 다 끝날지 묻습니다.
이 코드가 서버에 배포 된 것을 상상할 수 없습니다. 또한 코드 효율성과 웹 응용 프로그램의 성능에 대해서는 아직 아무것도 모릅니다.
한편으로 회사는 제품을 기다리고 있으며 더 이상 기다릴 수 없습니다. 반면에 실제 코드로 더 이상 나아갈 수는 없습니다. 나는 마무리하고 마무리하고 배치 할 수 있지만 신은 사람들이 그것을 사용할 때 일어날 수있는 일만을 알고 있습니다.
다시 쓰거나 계속 배송하려고합니까, 아니면 놓친 다른 옵션이 있습니까?
답변
당신은 대부분의 CS 교육의 아킬레스 건을 우연히 발견했습니다. 그들은 당신에게 도구와 기술을 가르치지 만 거래는하지 않습니다. 소프트웨어 제작은 수년간의 실습과 소프트웨어 사용 경험을 통해서만 얻는 기술입니다 (사용자는 교사보다 훨씬 더 비판적입니다). 소프트웨어 구축은 비즈니스 목표가 기술 목표를 무시할 수있는 비즈니스이기도합니다.
우선, 배. 비즈니스 소유자에게 소프트웨어를 보여주고 배송 할 준비가되었다고 생각되면 배송하십시오. 그 시점이 아니지만 닫으면 마무리하십시오. 중요한 소프트웨어는 실제로 사용되는 소프트웨어입니다. 돈을 버는 유일한 소프트웨어 사업은 제품이있는 사업입니다.
둘째, 당신은 많은 귀중한 것들을 배웠으므로 그것이 배운 것에 대한 경험에 감사해야 합니다 .
- 계획이나 아키텍처가없는 코드를 슬링하는 것은 재난의 요리법입니다
- 코드 작성보다 프로그래밍에 더 많은 것이 있습니다
- 비 기술적 비즈니스 소유자는 종종 기술 결정 (임직원 등)의 영향을 이해하지 못하며,이를 설명하는 것은 개발자의 몫입니다.
- 기존 프레임 워크에서 대부분의 문제는 이미 해결 한 것보다 훨씬 잘 해결되었습니다. 존재하는 프레임 워크와 사용시기를 알아야합니다.
- 지도가 거의없는 큰 프로젝트에 배정 된 신입생은 스파게티 코드 한 그릇을 생산하는 경향이 있습니다. 이것은 정상입니다.
다음은 진행 방법에 대한 조언입니다.
- 의사 소통, 의사 소통, 의사 소통 확실하지 않고 여러 경로를 보더라도 프로젝트 상태와 진행 방법에 대한 아이디어에 대해 매우 개방적이고 솔직해야합니다. 이로 인해 비즈니스 소유자는 수행 할 작업을 선택할 수 있습니다. 자신에게 지식을 간직 할 경우 선택권을 박탈 당하게됩니다.
- 완전한 재기록의 유혹에 저항하십시오. 다시 쓰는 동안 비즈니스에는 제품이 없습니다. 또한, 재 작성은 당신이 상상했던 것만 큼 좋은 것으로 밝혀지지 않습니다. 대신 아키텍처를 선택하고 코드베이스를 점진적으로 마이그레이션하십시오. 이런 식으로 끔찍한 코드베이스조차도 구제 될 수 있습니다. 리팩토링에 관한 책을 읽고 도움을 받으십시오.
- 자동 테스트 / 단위 테스트에 대해 알아보십시오 . 코드에 대한 신뢰를 쌓아야하며이를 수행하는 방법은 자동화 된 테스트로 코드를 처리하는 것입니다. 이것은 리팩토링과 함께 진행됩니다. 테스트를하지 않는 한 수동적이고 포괄적으로 테스트하십시오 (사용자가 그렇게하기 때문에 코드를 위반하십시오). 찾은 모든 버그를 기록하여 우선 순위를 정하고 수정할 수 있습니다 (모든 버그를 수정할 시간이없고 실제 버그가없는 소프트웨어는 제공되지 않습니다).
- 웹 애플리케이션을 배치하고 계속 실행하는 방법에 대해 학습하십시오. Web Operations : Data On Time 책 은 좋은 시작입니다.
답변
이것은 나에게 던져진 다른 모든 시스템처럼 들린다.
긴장을 푸십시오. 이것은 많은 사람들에게 발생합니다. 경험이없고, 도움이없고, 지원이없고,지도가없는 깊숙한 곳에 던져진 주니어는 성공을위한 레시피가 아닙니다. 주니어 프로그래머가 잘 작동하고 성능이 우수하며 유지 보수가 가능한 새로운 시스템을 처음부터 새로 구축 할 것을 기대하고있는 것은 현실적이지 않습니다. 선임 프로그래머에게 이런 일이 생기면 운이 좋을 것입니다.
제 생각에는 깨끗해야합니다. 재미 없을 것입니다. 그들에게 당신이 최선을 다했다고 말하지만, (대부분은) 효과가 있지만, 성능이 좋지 않을 수도 있고 많은 버그가있을 것이라고 걱정합니다 ( 항상 버그가 있습니다). 상급 프로그래머가 검토해야하며 눈에 띄는 성능 / 보안 문제를 매우 빠르게 해결할 수 있어야합니다. 또는 그것을 배치하고 손가락을 교차시킬 수 있습니다. 괜찮아 지거나 연기로 올라갈 것입니다. 문제가 발생할 때 문제를 해결할 수 있습니다. 큰 사용자 기반이 있다면 아닐 수도 있습니다.
또는이 상황에서 대부분의 사람들이하는 일을 할 수도 있습니다. 돈을 가져 가서 사라지게하십시오. 윤리적 인 선택이 무엇인지 해결하기 위해 당신에게 맡길 것입니다.
편집 (이 질문에 많은 투표권이 있으므로 내용을 더 추가 할 수도 있음)
프로그래머가되는 기쁨의 일부는 비 기술적 인 사람들 (아마도 당신의 관리자, 나머지 사업)은 당신이 무엇을하는지 전혀 모른다는 것입니다. 이것은 좋고 나쁘다. 나쁜 점 중 하나는 소프트웨어 개발 프로젝트의 작동 방식을 지속적으로 설명해야한다는 것입니다. 계획, 요구 사항, 코드 검토, 테스트, 배포 및 버그 수정 테스트의 중요성을 설명하고 테스트 할 시간을 따로 두는 것이 귀하의 임무 입니다. 당신 은 여기에 당신의 입장을 견뎌야합니다. 사람들은 그 중요성을 이해하지 못할 것입니다 ( “우리는 그것을 사용할 수 없습니까?”) (실제 환경이 아닌) 테스트를 시작하면 이점을 빠르게 이해할 수 있습니다. 그들이 당신을 고용 한 이유 중 하나는 소프트웨어 개발에 대해 아무것도 모르기 때문에 교육하는 것은 당신에게 달려 있습니다. 테스트와 버그 수정의 중요성을 강조해야합니다. 프로그래머는 아니고 0으로 나누기와 깨진 html 태그의 차이점을 모릅니다.
종종 발생하는 많은 문제는 실제로 버그가 아닙니다. 유용성 문제, 누락 된 요구 사항, 변경된 요구 사항, 사용자 기대치 (내 모바일에서는 이것을 사용할 수없는 이유) 및 실제 실제 버그가 될 것입니다. 라이브로 가기 전에 이러한 문제를 해결해야합니다. 며칠 후 많은 버그가 해결되거나 수정 될 수 있습니다. 사람들이 완벽한 시스템을 원한다면 많은 고통을 겪을 것입니다. 그들이 버그를 기대하고 있다면 앞으로 몇 주 동안 인생이 훨씬 쉬워 질 것입니다.
아, 그리고 사용자 테스트를 단위 테스트 나 시스템 테스트와 혼동하지 마십시오.
- 단위 테스트-내 코드 함수가 올바른 값을 반환합니까?
- 시스템 테스트-X를 클릭하면 오류가 발생합니다
- UAT (사용자 승인 테스트) – 프로그램이 요구 사항을 준수합니까? 그들이 요청한대로합니까? 생방송 할 수 있습니까?
그들이 당신에게 요구 한 것들의 요구 사항을 기록하지 않았다면 UAT 는 훨씬 더 어려울 것입니다. 이곳은 많은 사람들이 쓰러지는 곳입니다. 그들이 시스템에 원하는 것을 종이에 적어 놓으면 인생이 훨씬 쉬워집니다. 그들은 “왜 X를하지 않습니까?”라고 말할 것입니다. “당신은 나에게 Y를 시키라고 말 했어요.” 프로그램이 틀렸다면 수정하십시오. 요구 사항이 잘못된 경우 문서를 수정하고 하루나 이틀을 요청 (아니오, 고집)하고 변경하고 문서를 업데이트 한 후 다시 테스트하십시오.
이 과정을 몇 차례 거치면 애자일을 조사 할 수 있습니다.
TL; DR
테스트는 좋습니다
답변
처음부터 시작할 때마다 Second System Syndromme 으로 인해 거의 같은 양의 실수가 발생합니다 . 새로운 실수는 다를 수 있지만 디버깅에 필요한 시간은 비슷하므로 적합하지 않은 방법에 대해서는 절망합니다. 또한 첫 번째 버전이 배포 된 경우 프로덕션 또는 새로운 기능의 배포로의 배포가 지연 되어 회사에 심각한 문제 가 될 수 있습니다 . Joel Spolsky는 회사 나 개발자가 할 수있는 “단일 최악의 전략적 실수”라고 말합니다.
권장되는 방법은 유지 관리 중에 초기 엉망을 조금씩 정리하는 것입니다. 그리고 그것을 위해서만 리팩토링하지 마십시오. 또한 관리자는 일반적으로 돈 낭비라고 생각하며 새로운 버그가 발생할 위험이 불필요합니다. 코드를 고통스럽게 디버깅하면 예쁘지 않지만 작동합니다. 따라서 다른 이유로 인해 버그 수정, 새로운 기능 또는 마케팅에서 요청한 변경 등의 이유로 터치해야 할 때까지 기다리십시오. 그런 다음 조정하기 어려운 부품을 청소하십시오. 이것을 보이 스카우트 규칙 이라고합니다 .
그 시점에서 관리자와 논의 할 필요가 없습니다. 요청 견적에 원하는 최소 리팩토링을 포함하십시오. 회사가 실제로 고치기 때문에 비트를 생산할 여유가있을 때와 미래에 문제를 일으키고 싶지 않고 빠르게 해킹 할 가능성을 인정하지 않을 때 경험을 통해 배울 수 있습니다.
답변
처음 읽은 부분을 잊어 버렸지 만 다른 사람들이 말한 것을 다소 강력하게 반향하고 싶었습니다.
배송은 기능입니다.
완벽하게 작동 하는 기존 코드 (해킹, 못생긴, 더러워진)를 “정리”하는 사람보다 새로운 버그를 도입 하는 것보다 더 나쁘지는 않습니다 . 당신은 그렇게했습니다. 배. 보기 흉한 환경에서도 완벽하게 작동하는 프로젝트의 재 설계에서 길을 잃지 마십시오. 수정하면 점진적으로 수정하고 가능한 한 적은 회귀를 가질 수 있도록 좋은 테스트 스위트로 만드십시오.
답변
모든 프로젝트는 예전보다 똑똑해집니다. 모든 프로젝트 후에는 더 많은 경험을 쌓았을 것입니다. 나는 모든 것을 다시 방문하고 배운 것을 적용하기가 어렵다는 것을 알고 있습니다. 하지만 기억해:
완전은 선의 적입니다.
클라이언트에게는 결코 출시되지 않는 완벽한 소프트웨어보다 좋은 소프트웨어를 항상 갖추는 것이 좋습니다.
이것은 단지 첫 번째 프로젝트였습니다. 앞으로 배운 모든 것을 처음부터 적용 할 수있는 더 많은 프로젝트가있을 것입니다.
답변
나는 […] 삼촌의 밥 깨끗한 코드를 읽었습니다.
나는 전체 프로젝트를 다시 작성해야한다는 지속적인 생각을 가지고 있습니다.
이 책에는 “하늘의 재 설계”라는 제목의 섹션이 있습니다.
당신이 그것을 만들 시간이 없을 것 같은 경우에도, 당신은 어쨌든 같은 문제에 직면 할 것이기 때문에 모든 것을 다시 쓰려고하지 마십시오. 재 설계를 마치면 새로운 것을 배웠고 첫 번째 부분이 매우 전문적이지 않다는 것을 깨달을 것이므로 다시 작성하고 싶을 것입니다.
재 설계 및 재 작성은 작업 시스템에서 점진적으로 수행되는 경우에만 좋습니다. 다른 사용자가 지적했듯이, 보이 스카우트 규칙에 따라 작업하면서 코드를 조금씩 리팩터링하십시오.
답변
잘하고 있어요
당신은 당신의 코드가 작동한다고 말하면 거의 준비가 되었습니까? 그리고 코드가 크게 향상 될 수 있다고 생각합니다. 좋은.
당신의 딜레마는 프리 랜싱에 대한 나의 첫 경험을 생각 나게합니다. 나는 코드에 결코 만족하지 않고 확장 성을 원했고 더 나은 바퀴를 재발 명하고 싶을 때 끝없는 질문을 겪었습니다. 일단 당신이 물건을 배포하면 여전히 많은 교정, 테스트, 패치 등이 필요합니다 …
전문적인 코드 기반 작업 경험이 있습니까? 많은 코드 기반은 기발하고 코드를 유지하기가 어렵습니다. 큰 프로그램을 직접 구축하여 소프트웨어의 복잡성을 발견하는 대안은 다른 사람들이 작성한 엉망인 코드를 유지 / 확장하는 것입니다.
내가 완전한 재 작성을 보았던 유일한 경우는 팀이 새로운 툴체인 / 프레임 워크를 동시에 채택했을 때입니다.
기본 논리 (프로그램이 수행하는 기능, 함수, 클래스 등으로 배치되는 방법이 아니라 …)가 소리가 들리면 제대로 작동하므로 스파게티 코드라고 생각하지 않습니다. 배포해서는 안됩니다.
고객이 사용할 수있는 것을 갖도록해야합니다. 그런 다음 고객에게 개선 / 기능 추가를 요청하면 리 팩터가 필요한지 여부를 결정하고 고객에게 “새 기능을 통합하려면 일부 기술 작업이 필요합니다”라고 알릴 수 있습니다. 이를 통해 더 많은 비용이 소요되며 더 오래 기다려야한다는 것을 이해하게 될 것입니다. 그리고 그들은 이해할 것입니다 (또는 당신은 철수 할 수 있습니다).
모든 것을 다시 쓰는 더 좋은 시간은 다른 고객이 비슷한 것을 만들도록 요청할 때입니다.
요컨대, 모든 것이 배포되면 모든 사람의 얼굴에 날려 버린다는 것을 입증 할 수 없다면, 배포를 지연시키는 것은 전문가가 아니며 귀 하나 귀하의 고객에게 이익이되지 않을 것입니다. 버그를 수정하거나 새로운 기능을 추가하면서 작은 리팩터링을 배우는 것은 귀중한 경험입니다.