코드의 이해 추상화를 어떻게 처리합니까?

새로운 코드베이스를 볼 때 나는 상향식 접근법에서 시작하는 것을 좋아합니다.
하나의 파일을 이해하고 다음 추상화로 넘어갑니다.
그러나 종종 저수준 추상화가 무엇을하고 있는지 잊어 버리는 경우가 있습니다.

그래서 나는이 시점에서 내가 완전히 이해했던 파일로 돌아가서 다시 배우려고하는 거의 끝없는 루프 안에서 자신을 발견 할 것입니다. 내 머리 속에 서로 연결된 수많은 다른 추상화를 저글링하려고 노력하는 동안.

이 상황을 다루는 더 나은 전략이 있습니까?

하위 수준의 세부 정보를 잊고 주어진 것으로 간주해야합니까? 그럼에도 불구하고, 현재 추상화가 무엇을하고 있는지 이해하려면 하위 레벨 추상화에 대한 이전의 이해가 여러 번 필요합니다.

구체적으로 프로그래밍하는 것은 세부 사항을 당신쪽으로 끌어 당기는 충동이므로 한 곳에서 세부 사항을 모두 적용 할 수 있습니다. 우리는 모두 이런 식으로 시작하고 놓기 어렵습니다.

추상적 프로그래밍은 가장 확실하게 "낮은 수준의 세부 사항을 잊어 버렸습니다". 때로는 높은 수준의 세부 정보도 있습니다. 당신은 세부 사항을 밀고 다른 것을 다루게합니다. 비열한 것은 당신 이이 일을 계속하고 있다는 것입니다. 당신은 정말로 print "Hello world"당신의 화면에 나타나는 사이의 모든 일을 이해하고 있습니까?

이러한 세부 사항을 없애기 위해 노력해야 할 가장 중요한 것은 좋은 이름입니다. 좋은 이름은 내부를 볼 때 놀라지 않을 것입니다. 그렇기 때문에 print화면에 무언가 를 넣는 것에 놀라지 않고 실제로 어떻게 신경 쓰지 않았습니까? foo "Hello world"다른 이야기 였을 것입니다.

또한 추상화 수준이 일정해야합니다. pi를 계산하는 수준에 있다면 pi를 표시하는 방법에 대해 걱정할 필요가 없습니다. 그 세부 사항은 속하지 않은 추상화로 유출되었습니다.

이 장소에서 내가 생각하고있는 한 가지에 관한 것이 아닌 더 낮거나 높거나 옆으로 세밀한 세부 사항은 완전히 사라지거나 적어도 좋은 이름 뒤에 숨길 수 있습니다.

따라서 파일에서 파일로 수신 거부하는 데 어려움을 겪고 있다면 누군가가 나쁜 이름이나 유출 된 추상화로 당신을 붙 잡았을 가능성이 있습니다.

손가락으로 읽어서이 문제를 해결합니다. 이 혼란에 대한 적절한 테스트를 마치면 책임을 따돌리고 놀라움을 피하는 명확한 이름을 부여하고 환상의 세계에 살지 않도록 다른 사람에게 보여줍니다.

분명히이 방법으로 일할 때 나는 혼자가 아닙니다.

익숙하지 않은 코드를 다룰 때마다 메소드 추출을 시작합니다. 이 작업을 수행 할 때 이름을 지정할 수있는 코드 덩어리를 찾은 다음 추출합니다. 나중에 추출한 메소드를 인라인하더라도 적어도 전체 구조를 볼 수 있도록 세부 사항을 일시적으로 숨기는 방법이 있습니다.

마이클 페더스-오렌지 코드

맨 아래에는 1 년마다 분기마다 이것이 어떻게 진행되었는지에 대한 업데이트가 있습니다.

좋은 이름입니다. 또는 다른 사람의 코드 인 경우 해당 시스템의 클래스 / 함수에서 나쁜 이름을 기반으로 좋은 이름 / 책임을 부여하려고하면 내 머리에 의미가 있습니다. 일단 구현되면 저수준 구현이 기억하기 쉬워집니다.

그게 전부 야 이 사이트에는 어떤 유형의 어떤 패턴이나 물건을 신으로 맹세하는 많은 순수 주의자들이 있지만, 좋은 이름은 당신을 멀게 할 것입니다. 나는 최소한의 문서화 / 잘 명명 된 / 잘 분리 된 코드를 만들어서 혼자서 더 많은 것을 해왔으며 내 코드가 많은 장소에서 많은 사람들에 의해 사용 되더라도 나를 물지 않았습니다. 내가 옳은 것은 코드의 흐름을 설명하는 좋은 이름, 좋은 주석 및 회로도에 많은 시간을 낭비하는 것이 었습니다. 내 코드를 심도있게 확장하려면 이해하기 위해 저수준 구현이 필요합니다. 잘 작성된 코드는 합리적인 방식으로 확장 될 수 있으므로 다른 사람이나 저수준 구현을 이해하거나 기억하지 않는 것이 좋습니다.

내 원래 분야의 사람들과 내가 진실이라고 알고있는 약간의 논쟁에 관심이 있다면, 여기에 적힌 내용을 들으면이 대답에 동의하고 동의하지 않는 법을 배우게됩니다 미리 읽어보십시오.

그러나 여기 또 다른 문제가 있습니다-순수 주의자. 합리적이고 완전하게 논리적으로 잘 짜여진 답변과 이데올로기를들을 수 있습니다. 사실, 그들에게는 아무런 문제가 없습니다. 그러나 당신은 그것들을 따를 필요가 없습니다. 사실, 그들은 당신의 단점을 가지고있을 수도 있습니다.

내 친구들은 큰 시스템을 가지고 일했고 그들은 관습과 패턴에 대해 너무 많은 관심을 가진 사람들을 웃어 버렸습니다. 그리고 정당한 이유 때문에 그렇게 할 것입니다. 내 주요 데이터 분석 분야에서 이에 대한 내 추론을 찾을 수 있습니다. 나는 경험이 풍부한 개발자가 아니기 때문에 : 당신이 중요하다고 생각하는 것의 대부분은 중요하지 않으며, 이러한 의미에서 당신의 자아와 강한 상관 관계가 있습니다.종종 자신의 자아로 인해 개인이 자신의 편견으로 인해 오해했을 가능성이 가장 크다는 사실을 알게되었을 것입니다. 이것은 당신이 절대로 빠지지 않아야 할 매우 잘 알려진 함정입니다. 그렇다고해서 그가 정당하게 또는 더 큰 이익을 위해 그것을 사용하지 않는다는 것을 의미하는 것은 아니지만 종종 사람들이 할 일은 황금 상이라고 약속하는 것입니다.

그래서 당신은 무엇을 할 수 있습니까?

동료에게 코드를 설명하고 높은 수준의 관점에서 말이되는지 물어보십시오.

그게 다야 물론 다른 사람의 코드를 읽는 사람은 항상 특정 항목의 구현을 볼 수있는 alt- 탭 축제를 갖지만, 코드를 읽는 사람이 시스템에 대한 높은 수준의 이해를 가지고 "일이 발생하는 이유를 이해하는 경우에는 중요하지 않습니다. "(다시 말하지만,"어떻게 일이 일어나는지 "몰라도) 당신은 황금입니다.

이것은 내가 말하지 않고 성능이 좋지 않거나 아무것도 존중하지 않는 쓰레기 코드를 작성하지만 내가 말하는 것은 다음과 같습니다.

1) 잊어도 괜찮습니다. 시간이 지나면 작업중인 코드를 더 잘 읽을 수 있습니다. 읽고있는 코드가 저수준 구현을 좋은 수준으로 알기를 요구하면 코드가 잘못 작성되어 내가 전에 말한대로 재생됩니다. 동료가 당신을 이해합니까?

2) 세상은 똑똑하지 않은 많은 똑똑한 사람들로 가득 차 있습니다. 그들은 또한 종종 매우 감정적이며 외부 세력으로부터 편견을 강화하는 경향이 있습니다. 그들은 정보를 퍼뜨리는 행위자들이 잊어 버린 것처럼 그들이하는 일에 매우 능숙하지만, 아이디어 나 정보는 "논리"에 의해 뒷받침 되더라도 정보를 보내는 사람의 맥락을 가지고 있습니다. 정보도 당신에게도 유용합니다. 당신에게 의미가있는 것은 다른 사람들에게도 합리적이며 사람들은 그것을 좋아하지만 정보는 절대적인 것으로 간주되어서는 안되며, 다시 한번, 그 정보의 출처를 파악하고 그에 대한 점검을 시도하거나 확인해야합니다. 자신의 컨텍스트가 일치하는지 확인하십시오. 억만 장자와 같은 방식으로 우리에게 이러한“앞서 나아갈 지식”을주었습니다.

한마디로 : 이해할 수있는 코드를 작성하고 일부 패턴 / 클래스 및 정제소가 필요한 곳에서도 여전히 논쟁의 여지가 있음을 인식하십시오. 논쟁의 양쪽에는 매우 똑똑한 사람들이 있으며, 팀을 위해 어떤 일이든 합리적인 방식으로 수행한다는 아이디어 만 강화해야합니다. 중요하지 않은 작은 세부 사항에 집착하지 마십시오. 나중에 타이밍이 가장 중요한 경쟁이 치열한 세상에 살고 있음을 기억하십시오.

스타트 업 성공의 타이밍.

의미 있고 탐욕스러운 방식으로 시간과 자원을 할당하십시오.

6 개월 후 수정 사항이 있습니다.

미친 여행이었습니다. 나는 단지 분리 / 좋은 이름 지정 및 문서화가 기본적으로 코드베이스에 무엇이든 연결할 수 있다고 생각하지 않았습니다. 새로운 변경 사항을 신속하게 처리하기 위해 많은 코드를 다시 작성해야했으며 2-3 일 안에 좋은 코드를 만들었습니다. 지식이 부족하거나 모범 사례로 인해 SOLID를 어느 곳에서나 따르지 않았다는 것을 안전하게 말할 수 있으며 기술 부채에 있다고 말할 수는 있지만 많이는 아닙니다. 별도의 이름과 문서를 사용하면 얼마나 멍청한 지 알 수있는 시간에 코드를 변경할 수 있습니다.

나를 오해하지 마십시오. 코드를 단단히 결합하면 SOLID를 싫어하든 아니든 기본 수준에서 코드를 이해하고 적용해도 큰 분리가 가능해집니다. OOP가 실제로 도와주는 유일한 것입니다. OOP는 또한 코드 재사용에 관한 것으로 생각되었지만 여기저기서 발생 합니다.실제로 생성 한 많은 객체를 재사용 할 필요가 없으므로 시스템이 잘 분리되어 있는지 확인하십시오. 성숙에 도달하고 밥 삼촌이 와서 프로젝트를 이끌었다 고 가정 해 보자. "좋아, 이건 멍청한 짓이지만 적어도 모든 것이 분리되어 있고, 이름이 잘 정리되어 있고 문서화되어있어 적어도이게 무슨 일인지 알아 " (나는 희망). 나를 위해, 그것은 작동합니다. 내 LOC는 지속적으로 변경되지만 작성 당시에는 110k 코드 라인, 110k 코드 수행 코드는 한 사람과 조화롭게 작동합니다.

3 개월 후 8 개월 코드를 리팩토링하는 편집 내용이 있습니다.

모든 것이 이해됩니다. 이제 내가 작성한 내용을 개념적으로 설명하고 새로운 아이디어로 코드를 새로 만들 수 있습니다. 회로도 / 좋은 이름 및 주석으로 인해 진행중인 작업과 왜 작동하는지 완벽하게 이해하기 때문입니다. 나는 오래 전에 코드를 잘 작성하지 않는 코드를 작성했으며 그 과정에서 고통을 겪고 있습니다. 이제 내 코드를 설명하는 다음 단계가 무엇인지 생각하고 있습니다.