JavaRush /Java Blog /Random-KO /자바 개발자의 하루. 1 부
alex8894
레벨 34
Санкт-Петербург

자바 개발자의 하루. 1 부

Random-KO 그룹에 게시되었습니다
안녕하세요, 동료 여러분! 『 20+ 년 후 』 가 출간된 후 일부 독자들은 이야기의 연속을 요청했습니다. 내가 또 무슨 얘기를 할 수 있겠어? "수염 난 엔키"를 Java 개발자로 전환하는 주제는 충분히 다룬 것 같습니다. 1년의 작업이 끝나기 전에 몇 가지 결론을 내리는 것이 가능할 것입니다. 그런 다음 나는 일반적인 근무일이 어떻게 진행되는지 간단히 설명하기로 결정했습니다. "Java 개발자의 하루"라는 컷 아래에 있습니다. 나는 어렸을 때 잠자는 것을 좋아했습니다. 제가 에니키였을 때 정오까지 자고 3시, 심지어 3시 반에 출근한 적도 있어요. “다른 사람들처럼 오세요”라는 경영진의 주기적인 요구에 내가 오전 9시까지 항상 같은 방식으로 응답할 때마다 그들은 누구에게도 방해가 되지 않을 때 컴퓨터 작업을 해야 한다고 말합니다. 그것은 굴러 갔다. 그러나 나이가 들면서 몸에 뭔가가 변한 것 같고 이제 나는 "밤 올빼미"보다 "종달새"에 더 가깝습니다. 그래서 지금은 내가 먼저(또는 첫 번째 중 하나) 출근합니다. 오늘은 내가 첫 번째이고, "일찍 일어나는 새"가 아닌 다른 사람들이 따라잡을 때까지 30분에서 1시간 정도 침묵의 시간을 갖습니다. 오늘은 계획을 세울 시간이에요. 저는 Linux Mint에서 개발합니다. 저는 이런 타일보다는 겸손하고 우아한 시작 버튼을 좋아합니다. Cinnamon 데스크탑 관리자는 시각 효과로 인해 과부하가 발생하지 않지만 광택 측면에서는 물론 이 문제의 표준인 MacOS보다 약간 열등합니다. 비교하기 쉽습니다. 옆 테이블에는 Mac이 있고 그 뒤에는 UX 디자이너가 일하고 있습니다. OS 자체에 대한 불만도 거의 없습니다. 빠르고 안정적으로 작동하며, 긴 연휴 동안 컴퓨터를 끌 때 이 기간 동안 세 번만 재부팅했습니다. 실제로 모든 개발자의 컴퓨터에는 SSD 드라이브가 장착되어 있기 때문에 거의 즉시 로드되며 스플래시 화면이 나타날 시간도 없습니다. 먼저 Thunderbird 이메일 클라이언트를 열면 Wiki에서 관심 있는 페이지의 변경 사항에 대한 정보가 담긴 편지가 도착하지만(설정 및 사양이 있음) 가장 중요한 것은 추적기의 알림입니다. 우리에게 무슨 흥미로운 일이 일어났나요? 아, 제가 어제 완료한 기능을 테스트하고 돌아왔는데, 버그를 발견한 것 같습니다. 네, 그렇습니다. 가능한 한 빨리 고쳐야 합니다. 아마도 테스터가 도착하기 전에 시간이 있을 것이고 그는 아직 "미완성된 구성"에 들어가기 전에 즉시 수정 사항을 살펴볼 것입니다. 그것이 오늘의 첫 번째 일입니다. 그래서 이것은 제가 지난 스프린트 내내 썼던 "미완성 건축물"에 관한 것입니다. 이번에 그는 지옥의 모든 원을 성공적으로 견뎌낸 것 같습니다테스트 단계에 있으며 아마도 오늘은 프로젝트의 메인 브랜치에 병합해야 할 것입니다. 하지만 그건 나중에 점심 식사 후에 올 거예요. 오늘도 우리는 DevOps 작업을 수행하고 현재 개발이 진행 중인 지점에서 스탠드를 업데이트해야 하며 새로운 기능을 보여줘야 합니다. “큰 힘에는 큰 책임이 따른다”는 sudo 명령은 루트 권한을 부여하기 전에 경고를 표시합니다. 내 다소 느슨한 번역에서 이 문구는 "더 많이 할 수 있으면 더 많이 해야 한다"처럼 들립니다. 그러므로 '관리자의 도장'을 받은 내가 이런 '경계선' 업무를 자주 받는 것은 놀라운 일이 아니다. 자, 시작해 보겠습니다. 어제는 다른 기능을 작업 중이었는데 이제 버그가 있는 브랜치로 돌아가야 합니다. Windows 사용자는 일반적으로 모든 종류의 그래픽 셸을 좋아하고 Turtle(TortoiseGit)을 사용하지만 나에게는 명령줄을 사용하는 것이 더 쉽고 친숙합니다. 일반적으로 Linux의 명령줄은 작은 걸작이며, 특히 Midnight Commander와 함께 사용하면 믿을 수 없을 만큼 사려 깊고 강력합니다. 전환했으니 이제 프로젝트를 다시 빌드해야 합니다. 나는 gradle clean ass 명령을 입력합니다. 이 명령이 원래 Gradle 작성자가 의도한 것인지 아니면 우연히 만들어진 것인지는 모르겠지만 단순히 프로젝트를 정리하고 다시 빌드하는 것뿐입니다(ass는 assemble의 약자이며 처음 떠오르는 것이 아닙니다). javarush에서는 gradle이 "및 기타 빌드 시스템"으로 간략하게 언급됩니다. 예, Gradle은 교육 프로젝트를 조립하는 데 Maven보다 장점이 없습니다. 인터넷에 있는 대부분의 튜토리얼과 방법 역시 Maven을 사용합니다. Gradle의 출현과 인기 증가는 현대 프로젝트 구축의 복잡성이 급격히 증가했기 때문일 가능성이 높습니다. 제가 참여하고 있는 프로젝트는 백엔드가 Java로 작성되고, 프론트엔드가 Javascript로, 테스트가 Python으로 작성되는 수십 개의 구성요소로 구성되어 있습니다. 그건 그렇고, 요즘 Javascript 프로젝트를 조립하는 것은 웹 워크플로라는 이름을 가진 별도의 완전히 복잡한 프로세스이며 거기의 종속성 트리는 Java만큼 광범위합니다. 글쎄, 최소한 Python 구성 요소를 조립할 필요는 없습니다. 음, 거의 필요하지 않습니다... 조립 및 실행 후(이 역시 중요하지 않음) 관계형을 사용하여 전체 환경을 테스트 데이터로 생성하고 초기화해야 합니다. NoSql 데이터베이스, 메시지 대기열 및 메모리 내 캐시. 그런 다음 이 모든 것을 다시 어셈블하여 CI 서버에서 실행한 다음 ansible을 사용하여 배포해야 합니다. 동시에 개발은 주로 Windows에서 수행되며 "전투", 데모, 테스트 및 기타 사전 프로덕션 서버는 당연히 Linux에서 수행됩니다. 메이븐에서는 그런 것들을 구현하는 것이 어떻게 가능한지 상상이 안 되지만, gradle에서는 꽤 잘 구현됩니다. 사실 Gradle 빌드 파일은 Groovy로 작성되었습니다. 매우 재미있는 언어입니다. Java와 Ruby의 혼합이라고 합니다. 하지만 저는 Ruby를 모르지만 Javascript를 조금 알고 있으며 그 언어로 만든 많은 구성도 작동합니다. Gradle 제작자는 간단한 경우 빌드 파일이 매우 선언적으로 보이는 API를 구현했습니다(그런데 제 생각에는 Maven의 pom.xml보다 읽기가 더 쉽습니다). 그러나 더 복잡한 것이 필요한 경우에는 이 모든 선언성은 폐기되고 변수, 함수, 클래스가 나타납니다. 한마디로 Groovy의 모든 기능은 Java 코드와 동일한 JVM에서 컴파일되고 실행될 수 있습니다. 이미 언급했듯이 어셈블리 자체는 크로스 플랫폼이지만 환경과 상호 작용하므로 Windows에서도 확인해야 합니다. 이를 위해 가상 머신에 Windows를 설치했습니다. KVM은 비약적으로 발전하고 있으며 게스트 시스템이 올바르게 구성되면 가상화가 거의 눈에 띄지 않습니다. 예, 이제 Spice는 두 대의 모니터를 지원하고 화면 해상도는 자동으로 조정되며 반가상화 장치 드라이버는 성능 손실을 거의 일으키지 않습니다. 가끔 두 플랫폼 사이에 별 차이를 못 느낀다는 생각이 들 때가 있어요. 그럼에도 불구하고 Java는 완전히 다른 두 가지 세계, 때로는 적대적인 세계를 더 가깝게 만드는 놀라운 도구입니다. 크랙, 키젠 및 연재물,Windows와 개방형 시스템 Linux의 세계로 대표됩니다. 따라서 프로젝트가 조립되고 이를 실행하고(물론 Gradle을 통해서도) 살펴봅니다. 네, 회색 수염이 아쉽네요. 저는 제작 요구 사항 중 하나를 구현하지 않았습니다. 여기 위키에 흑백으로 적혀 있습니다. 이전 직장에서 저는 이런 상황을 정기적으로 겪었고 개발자가 사양에서 전체 단락을 놓쳤을 수 있다는 사실에 항상 당황했습니다. 네, 쉽게요! 나는 그것에 대해 생각하고 또 다른 문제에 집중했는데 버그가있었습니다. 여러 단계의 테스트 덕분에 여기에서만 그녀가 잡히게 될 것이지만 이전 장소에서는 무슨 일이 있었는지 알 수 있습니다. 다행히 여기서의 작업은 오래 가지 않을 것입니다. 저는 개발에 사용되는 몇 안 되는 유료 제품 중 하나인 Idea Ultimate를 출시할 예정입니다. 원칙적으로 Community Edition을 사용해도 괜찮지만 Spring과의 통합과 같은 좋은 기능에 빠르게 익숙해집니다. 또한 로그용 터미널 두 개, 프런트엔드 및 Wiki용 브라우저, 명령줄이 있는 또 다른 터미널이 필요하며 모든 것이 움직이고 깜박입니다... 일반적으로 두 모니터 화면의 그림이 무서운 모습을 보이기 시작합니다. 저예산 영화에서나 보던 것처럼 해커의 노고를 그린 모습이다. 그러나 이것들은 여전히 ​​사소한 일이지만 장애 조치 클러스터를 생성하고 구성해야 했던 때를 기억합니다. 7개의 터미널 창, 화면 모서리, 모든 창에 다른 항목, ASCII 그래픽의 일부 숫자와 그림... 하지만 일에서 조금 벗어나 시간이 흘러갑니다. ... 휴, 필요한 건 다 한 것 같고, 아까 했던 건 하나도 안 깨뜨린 것 같아요. 기능에 설명을 추가하고 테스트용 스레드를 보냅니다. 나는 테스터의 작업을 단순화하기 위해 내가 정확히 무엇을 했거나 변경했는지 더 자세히 작성하려고 노력합니다. 이전 직장에서는 개발자들로부터 개선 사항을 확인해야 할 때 이러한 설명이 정말 그리웠습니다. 그러는 동안 아침은 순조롭게 낮으로 바뀌었고 사람들은 점차 차를 세웠습니다. 곧 스탠드업 회의가 열릴 것입니다. 우리 생각으로는 스탠드업 회의가 있을 것입니다. 사실, 근무일은 그것부터 시작되어야 하며, 대부분의 "야간 올빼미"에게는 이것이 거의 사실입니다. 스탠드업은 가능한 한 늦게 직장에 도착하기 위한 경계선 역할을 하며 지각하는 것은 강력히 권장하지 않습니다. 글쎄, 나에게 그것은 휴식과 같다. 그러니 모두 일어나자. 늘 그렇듯이 스탠드업에서 개발자는 어제 무엇을 했고 오늘 무엇을 할 계획인지 말하고, 테스터는 자신이 테스트한 것과 결과가 무엇인지 말해줍니다. 상사는 다음에 무엇을 할 계획인지 분명합니다. 어떤 문제가 발생했으며 특별히 주의해야 할 사항은 무엇입니까? 우리 팀은 지리적으로 분산되어 있으며 전체 팀은 스탠드업(물론 TV에서)에서만 볼 수 있으며 아마도 1년에 두 번씩 일반 기업 행사에서도 볼 수 있습니다. 스탠드업 중에 나는 이것이 실제로 개발자들이 긴장을 풀지 못하게 하기 위해 발명된 것이라는 생각을 자주 한다. 매일 업무 진행 상황을 보여줘야 할 때, 상사만이 읽을 종이 보고서가 아니라 동료들 앞에서는 아무렇지도 않게 더 많은 일을 하려고 노력할 것입니다. 얘기할 게 있어서. 물론 "어제 이 일을했고 오늘도 계속할 것입니다"를 며칠 연속 반복하는 "장기 건설 프로젝트"가 있지만 그중에서도 일부 작은 긴급 작업이 끊임없이 발생합니다. 끼어들었다. 한마디로 진짜 카우보이 개발자는 동료들에게 늘 하는 말이 있다. 스탠드업에서 신속하게 스탠드를 업데이트하라는 요청을 받았으므로 이제 업데이트하겠습니다. 프로젝트의 메인 브랜치가 게시되면 관리자가 업데이트를 수행하지만 이제 아직 완료되지 않은 기능을 게시해야 하며 동시에 관리자가 해결할 수 없는 몇 가지 문제가 필연적으로 발생합니다. 스탠드는 데이터 센터에 있으며 SSH를 통해서만 액세스가 가능하며 물론 그래픽 셸이 없습니다. 따라서 명령줄만 있고 하드코어만 있습니다! 업데이트 자체는 자동화되어 원활하게 진행되었지만 업데이트 후에 구성 요소 중 하나가 시작되지 않습니다. less 명령으로 로그를 보는데 아주 편리한 기능이 있습니다: Shift-F를 누르면 파일의 현재 내용이 지속적으로 표시되므로 로그에 적합합니다. 그런데 이게 무슨... 이상한 걸까요? 쉼표로 구분된 물음표의 전체 화면입니다. 두 번째 화면, 세 번째, 열 번째… 몇 개나 있나요? 아, 끝났습니다. 꽤 스택트레이스로 밝혀졌습니다. 누군가 목록에서 원하는 레코드를 선택하기 위해 IN 연산자를 사용하여 SQL 쿼리를 작성하고 목록의 각 요소에 대한 매개변수를 생성했습니다. 목록에 32767개 이상의 요소가 포함될 때까지 모든 것이 작동했지만 그 후 SQL 서버는 마침내 인내심을 잃었습니다. 이에 대한 버그 보고서를 작성해야 하지만 이는 작동하지 않는 구성 요소의 문제와는 아무런 관련이 없습니다. 더 자세히 살펴 보겠습니다. 이제 데이터베이스 구조를 새 버전으로 마이그레이션하지 않은 것이 분명하며 기능 작성자가 마이그레이션 중에 무언가를 변경한 것으로 보이며 여기 스탠드에는 이전 버전이 있었습니다. SQL Server 콘솔 유틸리티를 통해 구조 변경 사항을 수동으로 롤백해야 합니다. 필드를 삭제하려면 DML에 명령을 어떻게 작성해야 합니까? 색인? 테이블? 그게 다인 것 같습니다. 구성 요소를 다시 시작했는데 마이그레이션이 잘 진행되었습니다. 모든 것이 정상입니다. 이제 점심 먹으러 갈 시간인데, 그런데 오늘 날씨가 너무 좋네요. "하늘에 꼼짝도 하지 않고 떠다니면서 마을 사람들을 겁나게 했던 밝은 노란색 공이 알고보니 태양이었습니다." 거의 올해의 첫 화창한 날입니다. 나는 거리를 떠나고 싶지도 않지만 그래야합니다. 합병 시간이 다가오고 있습니다. 계속됩니다
코멘트
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION