O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

2021년 4월 10일 개발자 이야기

유튜브에서 방송한 자료입니다. 오늘자 방송: https://www.youtube.com/watch?v=IO7TcBu-x8s&list=PLdntWJk2tJPKvRB0mSqC5tyKUv7HFtcqg&index=1

  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

2021년 4월 10일 개발자 이야기

  1. 1. 레거시를 파악하고 변경해나가기: 우선순위와 고려 사항들 CTO들이 풀어주는 주간 뉴스 2021.4.10 OKdevTV
  2. 2. 참고자료 • <컴퓨터vs책> 블로그 http://jhrogue.blogspot.com/ • 오늘자방송https://www.youtube.com/watch?v=IO7TcBu- x8s&list=PLdntWJk2tJPKvRB0mSqC5tyKUv7HFtcqg&index=1 • 유튜브채널OKdevTV >재미있는개발이야기리스트 https://www.youtube.com/playlist?list=PLdntWJk2tJPKvRB0mSqC5tyKUv7HFtcqg • 슬라이드셰어 https://www.slideshare.net/jrogue/presentations • 채널박재호(초급개발자를위한...)https://www.youtube.com/c/박재호dev OKdevTV
  3. 3. 오늘의 짤방 OKdevTV
  4. 4. 제가 개인적인 사정으로 인해 4월 17일부터 5월 10일까지 5주 동안 주간 뉴스 방송을 쉽니다. 큰 문제는 아니며 일 때문에 그러니까 걱 정하지 마시고… 더 좋은 소식을 들고 찾아 뵙겠습니다. 공지사항 한 가지 OKdevTV
  5. 5. ① 호텔에서 찾아낸 미스테리한 UDP 스트림 ② 승자의 경기와 패자의 경기 ③ 레거시를 파악하고 변경해나가기: 우선순위와 고려 사항들 ④ 웹에서 접근성 높은 색상을 고르려면? ⑤ 마이크로소프트 OpenJDK 빌드 ⑥ 미국 대법원, 구글의 자바 API 사용을 공정 사용으로 판결 오늘의 소개할 내용 OKdevTV
  6. 6. • https://www.gkbrk.com/2016/05/hotel-music/ • 호텔에 묶고 있다가 wireshark를 연 개발자 이야기(그런데 호텔에서 wireshark를 왜 열었지? T_T) • 포트 2046에서 엄청난 UDP 트래픽 발생 • TV 스트림으로 보기에는 비디오 패킷 길이가 너무 짧음 • 멀티캐스트 패킷 • 파이썬으로 간단한 분석 스크립트 작성 • 첫 15바이트가 동일 • MPEG 압축 오디오 데이터로 보이는 LAME3.91UUUUUUU 시그니처를 발견 • 저장해서 file 유틸리티로 확인해보니 mp3가 아닌 data라고만 나옴 • 다시 파이썬 프로그램을 작성해 바이트를 건너뛰며 어떤 형식인지 판단 • 패킷에서 8바이트를 건너뛴 지점에서 MPEG 오디오 데이터 시작을 발견 • 스트림으로 저장해서 재생 → 음악이었음 • 어디서 음악이 들려올까? • 방도 아니고 스마트 TV도 아님 • 복도를 걷다가 찾아냄: 엘리베이터 음악. OKdevTV (개발) 호텔에서 찾아낸 미스테리한 UDP 스트림 1
  7. 7. • https://thehosk.medium.com/software-development-is-a-losers-game-fc68bb30d7eb • 위대한 코드는 당신을 구원할 수 없지만, 나쁜 코드는 당신을 죽일 수 있다! • 개발자들이 힘들어하는 이유는 경기의 규칙을 모르기 때문 • 프로 테니스는 승자의 경기(즉, 승자의 활동에 의해 결정), 아마추어 테니스는 패자의 경기(즉, 패자의 활동에 의해 결정) • 소프트웨어 개발 게임 • 소프트웨어 개발자의 80%는 아마추어이고, 20%는 프로 • 아마추어 개발자는 표준, 단위 테스트, 빌드 수정, 코드 검토, 코드 분석과 같은 활동을 싫어함 • 대다수 개발자들은 코드 작성을 과소평가하며 작동하는 소프트웨어를 만드는 능력을 과대 평가함 • 그렇다면? • 대다수 개발자들이 아마추어라면, 패자의 경기로 접근해서 실수를 줄이는 데 집중 • 아마추어 개발자의 목표는 코드 작성 자체! 나머지 활동은 모두 속도를 줄인다 • 하지만 코드를 빠르게 작성하려면, 품질에 초점을 맞추고 버그를 줄여야 한다. 즉 코드를 빠르게만 작성해서는 안 된다 • 개발 팀 관점에서 • 버그, 오류, 실수 비용은 단독 개발보다 점점 더 커지는 경향이 있다 • 우리와 같은 사람들이 매우 똑똑해 지려고 노력하는 대신 지속적으로 어리석지 않게 노력함으로써 얼마나 많은 장기적 이점을 얻었는지를 알면 놀랄 겁니다." — 찰리 멍거 OKdevTV (개발) 승자의 경기와 패자의 경기 2
  8. 8. • https://thehosk.medium.com/software-development-is-a-losers-game-fc68bb30d7eb • 거꾸로 하자 • 거꾸로 작동하는 코드를 빠르게 작성하는 것이 아니라 품질이 낮은 코드와 버그를 피하는 데 시간을 소비하는 것을 목표로 삼는 다. • 아마추어 개발자는 코드를 빠르게 작성하는 것이 양산/서비스 코드를 만드는 가장 빠른 방법이라고 생각한다. 하지만 엄청나게 복잡한 프로젝트에서는 코드에 한 줄 한 줄이 추가 될 때마다 복잡성이 증가하고 개발을 더 어렵게 만드는 코드 기반을 만든다. 빠르게 코드를 작성하는 방식은 한두 명의 개발자가 작업하는 소규모 프로젝트에서만 작동한다. • 버그 비용 줄이기 • 개발 과정에서 버그를 나중에 발견할수록 비용이 커진다. 버그 파악과 수정이 어려운 경우에 특히 버그 감지 기법을 고안해서 게임을 이겨야 한다 • 특히, 대부분의 개발 팀이 프로가 아닌 아마추어라고 가정할 경우 우리는 버그 감소에 초점을 맞춰야 한다 • 개발의 성공은 코드를 처음에 올바르게 작성하는 것이 아니라 여러 가지 실패 방법을 피하는 것이다 • "전문가는 점수를 얻고 아마추어는 점수를 잃는다." OKdevTV (개발) 승자의 경기와 패자의 경기 2
  9. 9. OKdevTV (개발) 레거시를 파악하고 변경해나가기: 우선순위와 고려 사항들 3 • https://kadensungbincho.tistory.com/72 • 문서화가 잘 되어 있지 않고, 단기간에 계약이 끝나 자세한 인수인계를 받기 어려운 서비스에 대해, 특히 30개 저장소로 분산된 코드를 효율적으로 파악하는 방법은 무엇일까? • 기술 부채와 관련해 ‘시간’이라는 측면을 신중하게 고려해야 한다 • 시간이 지남에 따라 이자는 복리로 붙는다 • 팀은 무엇에 가장 큰 이자를 지불하고 있는가? • 코드에서 메타 데이터 파악하기 • git history로 소스코드이 메타 데이터 확인하기: 형상 관리 시스템은 소스 코드의 정적인 측면에 시간 축을 부여 → 변경이 언제 발생했고, 누가 발생시켰는지 포함 → 따라서 특정 시점에 특정 부분에 대한 변경을 누구에게 확인해야 할지를 파악할 수 있음 • 저장소 이름, 브랜치 명, 총 커밋 수, 총 참여자 수, 마지막 커밋 일시를 토대로 가장 빠르게 수정되거나 활성화된 부분을 파악
  10. 10. OKdevTV (개발) 레거시를 파악하고 변경해나가기: 우선순위와 고려 사항들 3 • https://kadensungbincho.tistory.com/72 • 코드에서 메타 데이터 파악하기(계속됨) • 개발의 초기 시점에 생성된 파일이 오래 남아 (비교적 안정적일지는 모르겠지만) “높은 이자율”을 발생시킴 • git log로 초기에 개발되거나 초기에 자주 변경된 파일을 특정해서 파악 • 소스 코드의 메타 데이터 파악하기 • 소스 코드의 총 라인 수는 복잡도를 유추할 수 있는 가장 간단하면서도 중요한 지표 • 정적분석기인 소나큐브를 활용 • 변경 범위를 결정하고 단계별로 나눠서 분석하기 • 코드의 나이: 같이 변경해야 하는 파일들은 동시기의 변경 로그에 포함됨 → 변경 범위 결정에 중요한 단서 • 인터페이스: 넓은 범위에서부터 좁혀가면서 인터페이스 지점을 우선적으로 파악한 다음에 이들을 연결 • 테스트가 존재하지 않던 레거시에 테스트 더하기 • 변경 이전의 최소한의 안전 장치 마련: 코드 바이스 • 구분되지 않던 복잡한 덩어리를 뜯어서 표시하기 위한 울타리를 생성
  11. 11. OKdevTV (팁) 웹에서 접근성 높은 색상을 고르려면? 4 • https://learnui.design/tools/accessible-color-generator.html • Accessible color generator • 웹 디자인, 개발할 때 사용하려는 색상이 WCAG 명도 대비 요구 수준(4.5:1)에 도달하는지 간단하게 체크하고 충분하지 않은 경우 적절한 대비를 가진 유사 색상을 추천 via @naradesign
  12. 12. • https://devblogs.microsoft.com/java/announcing-preview-of-microsoft-build-of-openjdk/ • 마이크로소프트가 OpenJDK 빌드 미리보기 발표 • MacOS X, 리눅스, 윈도우의 x64 서버/데스크톱 환경에서 OpenJDK 11.0.10 + 9를 기반으로 한 Java 11 용 바이너 리 공개 • https://www.microsoft.com/openjdk • Java 11 용 TCK(Java Technology Compatibility Kit)를 통과 • 최소 2024 년까지 Java 11을 지원 • 라이선스: GPLv2 + CE (Classpath Exception)가 포함된 General Public License 2.0 • 조만간 컨테이너 이미지도 공개 예정 • 목표: Azure 관리 서비스 전반에서 Java 11의 기본 배포로 자리잡게 만듦 OKdevTV (뉴스) 마이크로소프트 OpenJDK 빌드 5
  13. 13. • https://www.infoq.com/news/2021/04/java-api-fair-use/ • 2020년 10월에 심리 시작 2021년 4월 5일 결정 • 시작 • 구글은 안드로이드에 자바 API의 하위 집합을 사용, OpenJDK에서 코드 자체를 복사하지 않았지만, 오라클은 API 정 의가 저작권에 보호된다고 주장 • 2010년 8월 13일 하급 법원에서 case 시작 → 2012년 5월 31일 API에 저작권이 없다고 판결 • 오라클은 전체 API가 더 큰 저작물로 결합되어 저작권이 있다고 주장하면서 공정 사용 건으로 다시 재소 • 2016년 5월 9일 지방 법원에서 case 시작 → 2016년 5월 26일 공정 사용이 적용된다고 판결 • 오라클은 항소 → 2018년 3월 27일에 구글의 API 사용이 공정하지 않다는 판결이 내려짐 • 구글이 다시 항소 → 2020년 3월 24일 case 시작 • 최종 결론 • 자료에는 저작권이 있다고 가정 → 하지만 공정한 사용 • API 자체에 저작권이 있는지는 아직은 판단을 보류 → 하지만 API 자체에 저작권이 있더라도 해당 API를 재구현하는 것은 공정 사용이며 저작권 침해가 아님 • 새롭고 혁신적인 프로그램 개발을 위해 구글의 자바 SE API 복제는 법에 정해진 원칙에 맞춰 공정 사용으로 판단됨 OKdevTV (뉴스) 미국 대법원, 구글의 자바 API 사용을 공정 사용으로 판결 6

×