개발자들에게 악몽을 가져다주는 호러 코딩!

반응형

개발자들은 자신이 무엇을 하고 무엇을 만들고 프로그래밍하는지에 대해 진정한 자부심을 갖는다. 만약 당신이 개발자인 경우, 당신은 발광 화면 앞에 앉아서 프로그램을 개발하기 위한 또 다른 프로그램을 작성하거나 애플리케이션을 오류 없이 만드는 것과 관련될 수 있다.

코딩에 관한 한 트럭의 짐이 있는데, 개발자가 작성한 모든 코드는 보이는 것보다 꽤 취약하기 때문이다.

코딩은 악몽이 닥치기 전까지 모두 재미있고 멋지고, 여러분 중 일부는 우리가 무엇을 말하고 있는지 생각하고 있는 반면, 일부는 이미 우리가 무엇에 대해 이야기하고 있는지 알고 있다. 코딩은 어떤 사람들에게는 더 쉽지만, 다른 사람들에게는 어렵지만, 그것은 모두 프로그램을 짜는 것과 개발자에게 개발하는 것에 달려 있다.

이 블로그에서는 "개발자의 코딩 공포"에 대해 논의할 것입니다. 아니면 여러분은 그들을 악몽이라고 부르셔도 됩니다.

 

1. "전체 시스템을 손상시키거나 더 나쁜 경우 데이터 센터의 모든 컴퓨터를 손상시키면 어떻게 됩니까?"

만약 어떤 사람이 비기술적 배경에서 왔다면, 그들은 간단한 코드 라인이 무엇을 할 수 있는지 전혀 알지 못할 것이다. "단순 코드 라인"은 컴퓨터의 전체 시스템을 손상시킬 수 있으며, 데이터 센터의 거의 모든 데스크톱을 손상시키는 사건도 있었습니다. 따라서 프로그래머들은 자신이 개발한 바로 그 코드나 소프트웨어 응용 프로그램을 두려워할 것이 분명하다.

2. "휴식 중이었어요!" 그래, 그랬지?

소프트웨어 애플리케이션의 기능은 효율성을 위해 정기적으로 모니터링해야 합니다. "break" 절을 올바르게 사용하는 것은 코드의 다른 부분과 마찬가지로 중요하다. "if", "do" 등과 같은 조항들은 처리되어야 하며, 그렇지 않을 경우 부적절한 배치가 코드를 손상시킬 수도 있다.

 

해당 응용 프로그램 업데이트를 추적하십시오. 그렇지 않으면 혼돈으로 인해 "끝나지 않는 중단"이 발생할 수 있습니다.

3. 실험이 실수로 바뀌면 돌이킬 수 없는 것이 된다!

누가 실험을 싫어하겠어요? 개발자의 임무는 새로운 프로그램, 디자인 등을 만드는 것인데, 이것들은 꽤 창조적인 기술을 필요로 하지 않나요? 창의력은 실험으로 이어지며, 보일라는 새로운 프로그램을 준비했습니다. 하지만, 실험이 오류로 판명되면 어떻게 될까요? 너무 돌이킬 수 없는 거야? 여러분의 노력이 헛수고가 될 뿐만 아니라 자원과 함께 시간과 에너지의 낭비가 있을 것이다.

4. 내가 할 수 있을 때 내 작품을 구했더라면!

 

작업을 저장하는 것은 매우 중요합니다. 단순한 실수로 시스템이 고장나더라도 몇 시간 동안 노력하면 수포로 돌아가고 처음부터 다시 작업하느라 매우 지칠 것이기 때문입니다. 따라서 단순히 "저장하는 것을 잊어버렸다"는 이유로 파일을 절대 잃어버리지 마십시오.

5. 왜 조립하는 것보다 수리하는 데 더 오래 걸리나요?

코드를 고치는 데 걸리는 시간이 빌드하는 데 걸리는 시간보다 더 오래 걸립니까? 정말 답답할 수 있습니다. 코드가 복잡할 때는 확장하기가 상당히 어려워진다. 따라서 소프트웨어 구축만으로는 충분하지 않으며 몇 주 후에 오류나 버그를 발견할 수 있습니다. 따라서 코드를 오류 없이 효율적으로 만드는 것 또한 중요합니다. 순서대로 버그의 근원을 숙지하세요.

6. 안 되는 오류지만, 효과가 있습니다.

이상 현상이라고 할 수 있는 몇 가지 사건들이 있는데, 그럴 수 없는 오류들, 혹은 사실 잘 안 됐어야 하는 오류들이 그것이다. 발디스 클레트넥스 전 컴퓨터 시스템 선임 엔지니어가 공유한 사건 중 하나죠

 

그는 약 150줄의 짧은 펄 프로그램을 작성했는데, 이것의 목적은 소프트웨어 패키지가 합리적인 방식으로 제공하지 않는 백업 시스템의 여러 기능을 자동화하기 위한 것이었다. 그래서 이 프로그램은 매일 아침 6-7년 동안 완벽하게 잘 운영되었습니다.

그러나 실제 코드 행이 "A가 B1, B2, B3과 같으면 이렇게 해라"이고 "A가 B1, B2, B3, B4와 같으면 이렇게 해라"로 변경되어야 한다.

필요한 변경을 하는 동안, 몇 줄 아래에 있는 또 다른 "만약" 진술이 거꾸로 되어 있다는 것을 알게 되었다. 그리고 그 진술은 150줄 중 가장 중요한 진술로 밝혀졌습니다. 그리고 그 코드는 작동하지 않고 충돌했어야 했습니다. 하지만 어찌된 일인지 6-7년 동안이나 그랬답니다!

몇몇 동료들에게 코드를 교차 검사받고도 모두 같은 결론에 도달했다. 그리고 그 다음날 아침 그는 코드가 고장났다는 것을 알게 되었다. 시작부터 정확히 그렇게 되어야 했다.

 

그 코드가 어떻게 작동했는지는 아직도 수수께끼야 누군가 제대로 보기 전까진 말이야

7. 당신을 영원히 괴롭히는 오류들!

당신은 언제 다른 프로그래머가 당신의 코드를 읽고 수정해야 하는지 모르기 때문에 당신은 항상 읽기 쉽고 이해하기 쉬운 코드를 작성해야 한다. 게다가, 몇 일, 몇 달, 심지어 몇 년 동안 당신을 괴롭힐 수 있는 오류들이 있다. 따라서 코드를 개발할 뿐만 아니라 효율적인 코드를 만들기 위해 항상 준비하십시오.

이 블로그가 섬뜩하지는 않더라도 당신에게 도움이 되었기를 바랍니다. 이러한 상황은 개발자들이 마주하고 싶지 않은 몇 가지 상황일 뿐이며, 이러한 사건에 대해 더 알고 싶다면, 우리 커뮤니티, 즉 NADOS라는 소셜 플랫폼에 동참할 수 있습니다. 숙련된 프로그래머 및 동료뿐 아니라 업계 전문가들과 협업하고 교류하며 교류할 수 있습니다. 자세한 내용은 Pepcoding에서 확인하십시오.

 

또한 읽기-