그들이 말했듯이, 당신이 당신의 오래된 코드를 부끄러워하지 않는다면 당신은 프로그래머로서 성장하고 있지 않은 것입니다. 그리고 나는 이 의견에 동의합니다. 40년 전에 재미로 프로그래밍을 시작했고, 직업적으로는 30년 전에 프로그래밍을 시작했기 때문에 실수가 많습니다. 대단히. 컴퓨터 과학 교수로서 저는 학생들에게 자신의 실수, 저의 실수, 그리고 다른 사람의 실수로부터 배우도록 가르칩니다. 겸손함을 잃지 않기 위해 내 실수에 대해 이야기해야 할 때라고 생각합니다. 누군가에게 유용할 수 있기를 바랍니다.

XNUMX위 - Microsoft C 컴파일러

우리 학교 선생님은 등장인물들에게 비극적인 죄책감이 없기 때문에 로미오와 줄리엣이 비극으로 간주될 수 없다고 믿었습니다. 그들은 단지 십대들이 그래야 하는 것처럼 어리석게 행동했을 뿐입니다. 당시 나는 그의 의견에 동의하지 않았지만 지금은 특히 프로그래밍과 관련하여 그의 의견에 어느 정도 합리성이 있다고 봅니다.

MIT에서 86학년을 마쳤을 때 나는 인생과 프로그래밍 모두에서 어리고 경험이 부족했습니다. 여름에는 Microsoft의 C 컴파일러 팀에서 인턴으로 일했는데, 처음에는 프로파일링 지원과 같은 일상적인 일을 하다가 (내 생각으로는) 컴파일러의 가장 재미있는 부분인 백엔드 최적화 작업을 맡게 되었습니다. 특히, 분기문에 대한 xXNUMX 코드를 개선해야 했습니다.

가능한 모든 경우에 최적의 기계어 코드를 작성하기로 결심하고 나는 풀장에 몸을 던졌습니다. 값의 분포 밀도가 높으면 전환 테이블. 만약 그들이 공약수를 가지고 있다면, 나는 그것을 사용하여 테이블을 더 조밀하게 만들었습니다. 비트 시프트). 모든 값이 XNUMX의 거듭제곱이 되면 또 다른 최적화를 수행했습니다. 일련의 값이 내 조건을 만족하지 않으면 최적화 가능한 여러 케이스로 분할하고 이미 최적화된 코드를 사용했습니다.

그것은 악몽이었다. 몇 년 후 나는 내 코드를 물려받은 프로그래머가 나를 싫어한다는 말을 들었습니다.

교훈

David Patterson과 John Hennessy가 Computer Architecture and Computer Systems Design에 쓴 것처럼 아키텍처와 디자인의 주요 원칙 중 하나는 일반적으로 작업을 최대한 빨리 수행하는 것입니다.

일반적인 사례의 속도를 높이면 드문 경우를 최적화하는 것보다 성능이 더 효과적으로 향상됩니다. 아이러니하게도 흔한 경우는 드문 경우보다 단순한 경우가 많습니다. 이 논리적 조언은 어떤 사례가 일반적인 것으로 간주되는지 알고 있다고 가정합니다. 이는 신중한 테스트 및 측정 프로세스를 통해서만 가능합니다.

변호를 위해 실제로 분기 문이 어떻게 생겼는지(예: 분기 수, 상수 배포 방법 등) 알아내려고 노력했지만 1988년에는 이 정보를 사용할 수 없었습니다. 그러나 현재 컴파일러가 내가 생각해낸 인공적인 예에 ​​대한 최적의 코드를 생성할 수 없을 때마다 특별한 경우를 추가하지 말았어야 했습니다.

나는 숙련된 개발자에게 전화를 걸어 그와 함께 일반적인 사례가 무엇인지 생각하고 구체적으로 처리해야 했습니다. 코드를 적게 작성하면 좋겠지만 그게 좋은 일이죠. Stack Overflow 창립자 Jeff Atwood가 쓴 것처럼 프로그래머의 최악의 적은 프로그래머 자신입니다.

나는 당신이 우리 모두와 마찬가지로 최선의 의도를 가지고 있다는 것을 알고 있습니다. 우리는 프로그램을 만들고 코드 작성을 좋아합니다. 그것이 우리가 만들어진 방식입니다. 우리는 접착테이프, 집에서 만든 목발, 코드 몇 개만 있으면 어떤 문제든 해결할 수 있다고 생각합니다. 코더가 이를 인정하는 것이 고통스러운 만큼, 최고의 코드는 존재하지 않는 코드입니다. 각각의 새로운 라인에는 디버깅과 지원이 필요하며 이를 이해해야 합니다. 새로운 코드를 추가할 때는 다른 모든 옵션이 소진되었기 때문에 꺼리고 혐오감을 느끼며 추가해야 합니다. 많은 프로그래머가 너무 많은 코드를 작성하여 코드를 적으로 만듭니다.

일반적인 경우를 다루는 간단한 코드를 작성했다면 필요할 때 업데이트하는 것이 훨씬 쉬웠을 것입니다. 나는 아무도 처리하고 싶지 않은 혼란을 남겼습니다.

XNUMX위: 소셜 네트워크 광고

제가 Google에서 소셜 미디어 광고 작업을 할 때(Myspace를 기억하시나요?) C++로 다음과 같은 내용을 썼습니다.

for (int i = 0; i < user->interests->length(); i++) {
  for (int j = 0; j < user->interests(i)->keywords.length(); j++) {
      keywords->add(user->interests(i)->keywords(i)) {
  }
}

프로그래머는 즉시 오류를 볼 수 있습니다. 마지막 인수는 i가 아니라 j여야 합니다. 단위 테스트에서는 오류가 밝혀지지 않았으며 내 검토자도 마찬가지였습니다. 출시가 이루어졌고 어느 날 밤 내 코드가 서버로 이동하여 데이터 센터의 모든 컴퓨터가 충돌했습니다.

나쁜 일은 없었습니다. 글로벌 출시 전에 코드가 하나의 데이터 센터 내에서 테스트되었기 때문에 누구에게도 문제가 발생하지 않았습니다. SRE 엔지니어가 당구를 잠시 중단하고 약간의 롤백을 수행하지 않는 한. 다음날 아침 크래시 덤프가 포함된 이메일을 받았고 코드를 수정했으며 오류를 포착할 단위 테스트를 추가했습니다. 나는 프로토콜을 따랐기 때문에(그렇지 않으면 내 코드가 단순히 실행에 실패할 것입니다) 다른 문제는 없었습니다.

교훈

많은 사람들은 그러한 중대한 실수가 범인 해고의 대가를 치르게 될 것이라고 확신하지만 그렇지 않습니다. 첫째, 모든 프로그래머는 실수를 저지르고, 둘째, 같은 실수를 두 번 저지르는 경우는 거의 없습니다.

사실 제게는 뛰어난 엔지니어였지만 한 번의 실수로 해고된 프로그래머 친구가 있습니다. 그 후 그는 Google에 채용되었으며 곧 승진했습니다. 그는 인터뷰에서 자신이 저지른 실수에 대해 솔직하게 말했지만 치명적이라고 간주되지 않았습니다.

여기에 말하다 IBM의 전설적인 수장인 토마스 왓슨(Thomas Watson)에 대해:

약 백만 달러 상당의 정부 명령이 발표되었습니다. IBM Corporation 또는 개인적으로 Thomas Watson Sr.은 정말 그것을 얻고 싶었습니다. 불행하게도 영업 담당자는 이를 수행할 수 없었고 IBM은 입찰에서 패했습니다. 다음 날, 이 직원이 왓슨 씨의 사무실로 찾아와 그의 책상 위에 봉투를 올려 놓았습니다. 왓슨 씨는 그것을 쳐다보지도 않았습니다. 그는 직원을 기다리고 있었고 그것이 사직서라는 것을 알고 있었습니다.

왓슨은 무엇이 잘못되었는지 물었습니다.

영업 담당자는 입찰 진행 상황에 대해 자세히 설명했습니다. 그는 피할 수 있었던 실수를 언급했습니다. 마지막으로 그는 “왓슨씨, 설명해주셔서 감사합니다. 나는 이 명령이 우리에게 얼마나 필요했는지 알고 있습니다. 그 사람이 얼마나 중요한 사람인지 알아요”라고 말하고 떠날 준비를 했다.

왓슨은 문앞에서 그에게 다가가 그의 눈을 바라보며 다음과 같은 문구가 적힌 봉투를 돌려주었습니다. “내가 어떻게 당신을 보내줄 수 있습니까? 나는 방금 당신의 교육에 백만 달러를 투자했습니다.

나는 "실수로부터 정말로 배운다면 나는 이미 마스터입니다."라고 적힌 티셔츠를 가지고 있습니다. 사실, 오류에 관한 한 나는 과학박사입니다.

XNUMX위: App Inventor API

정말 끔찍한 오류는 수많은 사용자에게 영향을 미치고, 대중에게 알려지며, 수정하는 데 오랜 시간이 걸리고, 오류를 만들 수 없는 사람들에 의해 만들어집니다. 나의 가장 큰 실수는 이 모든 기준에 부합합니다.

나빠질수록 좋다

나는 읽었다 리처드 가브리엘의 에세이 저는 XNUMX년대 대학원생으로서 이러한 접근 방식에 대해 이야기를 나눴고, 그것이 너무 좋아서 학생들에게 물어보곤 했습니다. 잘 기억나지 않는다면 기억을 새롭게 해보세요. 작습니다. 이 에세이는 단순성을 포함하여 여러 면에서 "제대로 하려는" 욕구와 "나쁠수록 좋다"는 접근 방식을 대조합니다.

어떻게 해야 할까요? 디자인은 구현과 인터페이스가 단순해야 합니다. 구현의 단순성보다 인터페이스의 단순성이 더 중요합니다.

나쁠수록 좋습니다. 디자인은 구현과 인터페이스가 단순해야 합니다. 인터페이스의 단순성보다 구현의 단순성이 더 중요합니다.

그것에 대해서는 잠시 잊어버리자. 불행하게도 나는 수년 동안 그 일을 잊어버렸습니다.

앱 인벤토리

나는 Google에서 일하는 동안 팀의 일원이었습니다. 앱 인벤토리, 야심 찬 Android 개발자를 위한 드래그 앤 드롭 온라인 개발 환경입니다. 2009년이었는데 여름에는 가을에 가르칠 때 환경을 활용할 수 있는 교사들을 위한 마스터 클래스를 열 수 있도록 제때에 알파 버전을 서둘러 출시했습니다. 나는 TI-99/4에서 게임을 작성하던 방식에 대한 향수를 느끼며 스프라이트 구현에 자원했습니다. 모르는 사람들을 위해 설명하자면, 스프라이트는 다른 소프트웨어 요소를 움직이고 상호 작용할 수 있는 XNUMX차원 그래픽 개체입니다. 스프라이트의 예로는 우주선, 소행성, 대리석, 라켓 등이 있습니다.

우리는 Java로 객체 지향 App Inventor를 구현했기 때문에 거기에는 많은 객체가 있을 뿐입니다. 공과 스프라이트는 매우 유사하게 동작하므로 속성(필드) X, Y, 속도(속도) 및 방향(방향)을 사용하여 추상 스프라이트 클래스를 만들었습니다. 충돌을 감지하고 화면 가장자리에서 튕겨 나가는 등의 방법은 동일했습니다.

공과 스프라이트의 주요 차이점은 정확히 그려지는 것(채워진 원 또는 래스터)입니다. 스프라이트를 먼저 구현했기 때문에 이미지가 위치한 왼쪽 상단의 x 좌표와 y 좌표를 지정하는 것이 논리적이었습니다.

스프라이트가 작동하자 나는 아주 적은 코드로 공 객체를 구현할 수 있다고 결정했습니다. 유일한 문제는 공을 구성하는 윤곽의 왼쪽 상단 모서리의 x 및 y 좌표를 나타내는 가장 간단한 경로(구현자의 관점에서)를 선택했다는 것입니다.

사실, 수학 교과서나 원을 언급하는 다른 출처에서 가르치는 것처럼 원 중심의 x 및 y 좌표를 나타내는 것이 필요했습니다.

과거의 실수와 달리 이번 실수는 동료뿐만 아니라 수백만 명의 App Inventor 사용자에게도 영향을 미쳤습니다. 그들 중 다수는 어린이이거나 프로그래밍에 전혀 익숙하지 않은 사람들이었습니다. 그들은 공이 존재하는 각 애플리케이션을 작업할 때 불필요한 단계를 많이 수행해야 했습니다. 제가 웃으면서 했던 다른 실수들을 기억한다면, 이 실수는 오늘도 땀을 흘리게 합니다.

나는 XNUMX년이 지난 최근에야 마침내 이 버그를 패치했습니다. Joshua Bloch가 말했듯이 API는 영원하기 때문에 "수정"이 아닌 "패치"되었습니다. 기존 프로그램에 영향을 미치는 변경을 수행할 수 없었기 때문에 이전 프로그램에서는 false 값을, 향후 모든 프로그램에서는 true 값을 사용하여 OriginAtCenter 속성을 추가했습니다. 사용자는 논리적인 질문을 할 수 있습니다. 누가 시작점을 중앙이 아닌 다른 곳에 배치할 생각을 했습니까? 누구에게? XNUMX년 전 너무 게으른 나머지 일반 API를 만들 수 없었던 한 프로그래머에게.

교훈

API 작업(거의 모든 프로그래머가 가끔 수행해야 함)을 수행할 때 Joshua Bloch의 비디오에 설명된 최상의 조언을 따라야 합니다.좋은 API를 만드는 방법과 그것이 중요한 이유"또는 이 짧은 목록에서:

• API는 큰 이익과 큰 해를 가져올 수 있습니다.. 좋은 API는 단골 고객을 만듭니다. 나쁜 것은 당신의 영원한 악몽이 됩니다.
• 다이아몬드처럼 공개 API는 영원히 지속됩니다.. 최선을 다하세요. 모든 일을 제대로 할 수 있는 기회는 다시는 없을 것입니다.
• API 개요는 간략해야 합니다. — 클래스 및 메소드 서명과 설명이 포함된 한 페이지로, 한 줄만 차지합니다. 이렇게 하면 처음에 API가 완벽하지 않은 경우 API를 쉽게 재구성할 수 있습니다.
• 사용 사례 설명API를 구현하거나 사양을 작성하기 전에. 이렇게 하면 완전히 기능하지 않는 API를 구현하고 지정하는 것을 피할 수 있습니다.

만약 제가 인위적인 스크립트로 짧은 시놉시스라도 썼다면 아마도 오류를 확인하고 수정했을 것입니다. 그렇지 않다면 내 동료 중 한 명이 분명히 그렇게 할 것입니다. 광범위한 결과를 가져오는 모든 결정은 적어도 하루 동안 생각해야 합니다(이는 프로그래밍에만 적용되는 것이 아닙니다).

Richard Gabriel의 에세이 "Worse Is Better"의 제목은 불완전한 제품이라 할지라도 다른 사람이 완벽한 제품을 쫓기 위해 영원을 보내는 동안 시장에 가장 먼저 출시되는 이점을 나타냅니다. 스프라이트 코드를 곰곰히 생각해보면, 올바른 코드를 얻기 위해 더 많은 코드를 작성할 필요조차 없다는 것을 깨달았습니다. 누가 뭐라고 말하든 나는 크게 착각했습니다.

결론

프로그래머는 버그가 있는 코드를 작성하든, 기술과 생산성을 향상시킬 수 있는 작업을 시도하고 싶지 않든 매일 실수를 합니다. 물론 당신도 나처럼 심각한 실수를 하지 않고도 프로그래머가 될 수 있다. 그러나 자신의 실수를 인식하고 실수로부터 배우지 않고는 좋은 프로그래머가 되는 것은 불가능합니다.

나는 실수를 너무 많이 해서 프로그래밍에 적합하지 않다고 느끼는 학생들을 끊임없이 만난다. 나는 IT 분야에서 사기꾼 증후군이 얼마나 흔한지 알고 있습니다. 제가 나열한 교훈을 여러분이 배우기를 바랍니다. 그러나 주요 교훈을 기억하십시오. 우리 각자는 당황스럽고, 재미 있고, 끔찍한 실수를 저지른다는 것입니다. 앞으로 기사를 계속할 자료가 충분하지 않으면 놀라고 속상할 것입니다.

출처 : habr.com