Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

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

  • Be the first to comment

  • Be the first to like this

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

×