개발자 도구가 더욱 견고하고 강력 해졌지만 좋은 코드를 작성하는 것은 어려운 일이되었습니다. 그 도구조차도 더 강력하고 코드 품질이 좋아지지 않았습니다. 두 가지 중요한 요소가 있습니다. 시간이 짧고 프로젝트가 더 복잡합니다. 오늘날 우리가 사용하는 도구가 더 강력하기 때문에 더 복잡한 코드를 작성하는 것이 더 쉽지만 계획을 세우지 않고 되돌아 보지 않으면 코드 품질이 떨어지고 버그와 유지 관리가 향상됩니다. 이전에 복잡한 코드를 작성하지 않은 것은 아닙니다. 더 복잡한 코드를 작성하는 것입니다.
내 질문은 다음과 같습니다. 더 강력한 언어와 도구가 있다고 생각합니다.
내가 생각하는 프로젝트 유형은 복잡성과 비즈니스 논리가 큰 엔터프라이즈 응용 프로그램입니다. “좋은 코드”의 정의는 개별적입니다.“좋은 코드”의 해석에 갇히지 마십시오.
답변:
약 20 년 전 Peopleware 에서 DeMarco와 Lister가 말했듯이 , 실패한 소프트웨어 프로젝트의 대부분은 기술적 인 문제가 아니라 사회 학적 문제로 인해 실패합니다 . 도구가 아무리 개선 되었더라도 지난 수십 년 동안 바뀌지 않았습니다.
잘못된 관리, 비현실적인 기대, 직무에 적합한 직원을 확보하지 못하거나 직무를 수행하지 못하게함으로써 결과적으로 유지하지 못하는 경우. SW 개발 작업에 적합하지 않은 작업장 및 도구; 처리되지 않은 개인 갈등; 정치 ; 이것들은 프로젝트를 처음부터 파멸시킬 수있는 전형적인 문제 중 일부일뿐입니다.
좋은 코드를 작성하는 것이 더 어려운 이유는 무엇입니까?
수십 년 전보다 좋은 코드를 작성하는 것이 실제로 어렵다는 확신이 들지 않습니다. 실제로 머신 코드 또는 어셈블리와 비교할 때 현재 주류에있는 모든 것은 처리하기가 훨씬 쉽습니다. 더 많은 것을 생산해야 할 수도 있습니다.
언급 요소, 시간 및 복잡성 때문입니까?
예, 도구의 성능이 향상됨에 따라 달성 가능한 복잡성이 확실히 증가했습니다 (그리고 계속 증가하고 있습니다). 다시 말해, 우리는 한계를 뛰어 넘고 있습니다. 30 년 전에 그날의 가장 큰 도전을 해결하는 것이 오늘날의 가장 큰 도전을 해결하기가 어렵도록 번역했습니다.
OTOH는이 분야가 엄청나게 성장한 이래로 30 년 전보다 훨씬 더 "작거나"알려진 문제가 있습니다. 이 문제들은 기술적으로 (더 이상) 도전이되어서는 안되지만 여기에 위의 최대 값을 입력합니다 :-(
또한 프로그래머의 수가 엄청나게 커졌습니다. 그리고 적어도 제 개인적 인식은 평균적인 경험과 지식 수준이 떨어 졌다는 것입니다. 단순히 교육을받을 수있는 노인보다 필드에 계속 도착하는 주니어가 훨씬 많기 때문입니다.
방법론이 올바르게 실행되지 않았습니까?
확실히 그렇지 않다. DeMarco와 Lister는 big-M 방법론에 대한 가혹한 단어를 가지고 있습니다. 그들은 어떤 방법론도 프로젝트를 성공시킬 수 없다고 말합니다. 팀의 사람들 만이 할 수 있습니다. 그들이 칭찬하는 작은 방법론은 우리가 현재 "민첩한"것으로 알려진 것과 매우 유사하다. 10 년 전만해도 널리 알려지지 않은 단위 테스트 및 리팩토링과 같은 모범 사례는 말할 것도없고, 오늘날 많은 졸업생들도이를 알고 있습니다.
비현실적인 마감일에 따른 코딩 및 기술 부채 처리와 관련된 문제는 Weinberg '71 및 Brooks '72 이후로 알려져 있습니다. 그 전에는 온라인에서 자료를 찾기가 어려워졌지만 같은 말을하는 오래된 CDC, IBM 및 NASA 보고서가 있다고 확신합니다.
우리 모두는 "좋은 코드"에 대한 우리 자신의 아이디어와 임계 값을 가지고 있다고 생각합니다. 그러나 모두 기여하는 여러 가지 문제가 있습니다.
결국, 나는 "좋은"또는 "최상의"를 추구하는 것보다 더 나은 것을 추구하는 것이 최선이라고 생각합니다 . 우리가 가장 좋은 코드를 본다면 그렇게 인식 할 것입니까?
좋은 코드를 작성하는 것이 더 어려운 이유는 무엇입니까?
소프트웨어가 점점 추상화 계층 위에 구축되고 있기 때문입니다. 보다 쉽고 빠르게 개발할 수 있다고 주장하는 각각의 새로운 기술은 개발자가 이해해야 할 수준의 복잡성을 한층 더 추가합니다. 이제 이러한 추상화는 생산성에 큰 이점을 줄 수 있지만 숨기려는 내용을 이해하지 못하면 소프트웨어가 버그와 품질에 취약 해집니다.
최신 소프트웨어 개발에서 좋은 코드가 불가능합니까?
실제로는 불가능합니다. 그러나 당신이 이미 들어 본 이유는 없습니다.
대부분의 프로젝트의 범위는 인간 두뇌의 능력을 훨씬 뛰어 넘습니다. 그렇기 때문에 사람들은 추상화 개념을 생각해 냈습니다. . 즉, 세부 정보를 숨기고 분기의 밀도 (처리 할 정보의 양)가 수용 가능한 비율로 떨어질 때까지 추상화 트리를 더 높이 올라갑니다.
우리는 복잡성 문제를 해결했지만 이전에는 더 큰 문제를 제거하지 못했습니다.
우리가 처리하기에는 여전히 너무 복잡합니다.
고품질 솔루션을 만들려면 모든 것을 동시에보고 이해할 수 있어야합니다 . 즉 모든 모듈이 크고 작은 구현 세부 사항입니다. 한 번에 불일치를보고 가능한 모든 시나리오의 맥락에서 각 코드를보고 동시에 전체 코드베이스를 최적화하십시오.
우리는 그렇게 할 수 없습니다.
우리가 할 수 없다면 우리는 결코 양질의 코드를 만들지 않을 것입니다.
관리자는 모듈의 비열한 부분을 볼 수 있지만 모듈 당 내부 문제와 제한 사항은 알 수 없습니다.
모듈 프로그래머는 로컬 제한 사항을 알고 있지만 더 큰 상황에서이를 최적화 할 수는 없습니다.
관리자와 프로그래머 간 (그리고 심지어 프로그래머 간) 이해를 전달할 방법이 없습니다. 그리고 존재하더라도 인간의 뇌는 그것을 처리 할 수 없었습니다.
계속 노력하는 것 외에는 할 수있는 일이 거의 없습니다 (헛된 운동). 코드를 어느 정도 작동하게 유지하고 인생을 즐기자.
나는 당신의 질문의 전제를 부인합니다. 좋은 코드를 작성하는 것이 그 어느 때보 다 쉬워졌고, 그로 인해 우리는 이전에 해결했던 문제를 훨씬 더 힘들게 다루고 있습니다.
특정 공급 업체를 선택하고 싶지 않지만 Windows 1.0과 Windows 7을 비교하고 싶습니다. 후자는 수천 배 더 많은 코드를 포함하지만 충돌 사이의 평균 시간은 100 배 증가했습니다. 우리는 Windows 3.1 이후로 Word 문서에 Excel 스프레드 시트를 포함시킬 수 있었지만 요즘에는 실제로는 다소 작동합니다.
"요즘 오리 타이핑 및 VM을 사용하는 아이들"이라는 감정에 빠지지 않고 80 년대에 TINY, SMALL 및 HUGE 메모리 모델, 오버레이 등의 좋은 코드를 다시 작성하는 것이 얼마나 어려운지 전혀 알 수 없습니다. 임대가 아닌 OS 호출 (shudder) 그 모든 것들에 대한 좋은 조롱.
현대적인 응용 프로그램 은 20-30 년 전보다 더 복잡합니다. 환경이 더 풍부하고 다양하기 때문입니다.
DOS 프로그램은 사용자가 다음 키를 누를 때까지 긴밀한 루프에 앉아 해당 코드를 호출 한 후 다음 키를 누를 때까지 되돌아가는 것이 일반적이었습니다.
마우스를 전혀 사용할 수없는 최신 응용 프로그램에는 심각한 설명 문제가 있습니다. 사용자가 입력 할 때 사용자에게 최신 항목을 표시하는 응용 프로그램에서 RSS-feeds가 업데이트되는 동안 사용자가 입력하고 마우스로 클릭 한 후 입력을 계속할 수 있기 때문에 어떤 순서로든 문제가 발생할 수 있습니다.
이 모든 멀티 태스킹 작업은 사용자가 생각해야 할 모든 것보다 본질적으로 훨씬 더 복잡합니다. 정말 좋은 코드를 작성하기가 더 어렵습니다.
연구자들이 멀티 태스킹 프로그램을 개발자의 관점에서보다 유용하게 만들 수있는 방법을 알아 냈 으면 좋을 것 같지만 지금은 모든 사람이 잘하려고 노력하지만 어떻게해야할지 잘 모릅니다. 그것.
사실, 지난 10 년간 좋은 코드, 즉 예상대로 작동하고 유지 보수가 가능한 프로그램을 작성하는 것이 더 쉬워 졌다고 생각합니다. 사용 가능한 도구가 개선되었으며, 라이브러리가 더욱 성숙하고 포괄적이며 하드웨어가 훨씬 빨라 졌으므로 최적화 기법을 사용할 필요가 없습니다.
왜 우리는하지 않습니까?
IMO의 주된 이유는 우리가 물건을 남용하는 방법과 변명을 끊임없이 찾는 것입니다. Windows 실행 파일을 만드는 것과 같이 구식의 쉽고 지루한 방법을 사용하는 대신 가능한 경계를 넓히고 PhotoShop과 같은 것을 웹 응용 프로그램으로 다시 만드는 방법을 찾습니다. 왜? 우리가 할 수 있기 때문에. 아니면 적어도 우리는 그렇게 생각합니다.
마지막으로 누군가가 악용을 쓰지 않았거나 어셈블리로 커널 링 해커와 ASIC 녀석을 세지 않고 연구하기 위해 공부하지 않은 것은 언제입니까? C 코어 라이브러리에서 몇 개의 버그가 발견 되었습니까? 거의 없음. 내가 말하는 것은 사람들이 훌륭한 코드를 작성할 수 있다는 것입니다. 도구와 언어가 향상되면 '필수'가 줄어들고 '선택적'이 높아집니다. 우리 모두가 정말 끔찍한 코드를 작성해야한다고 생각하지는 않지만 복잡한 논리 구조를 생각할 때 아무도 해시 배열로 무언가를 작성하는 것을 꿈꾸지 않았을 것입니다. 복잡한 구조를 사용하는 대신 논리를 처리하는 '더 나은'방법이 있어야했습니다. 코드가 아름답더라도 때로는 접근 방식이 우아하지 않습니다. 나는 그것이 당신이 언급 한 문제를 해결한다고 생각합니다. 좋은 코드는 항상 정리 된 것이 아니라
더 나은 도구와 빠른 반응의 컴퓨터는 몇 년 (또는 수십 년)보다 더 많은 최종 제품 복잡성을 기대할 수 있기 때문입니다. 따라서 앱의 복잡성이 계속 증가하고 합리적인 수준의 생산성에 대한 가정이 계속 커지고 있습니다.
내가 일하는 곳에서 개발자는 항상 서둘러야합니다 (고객이 원하는 시간이 더 많기 때문에). 따라서 많은 코드 블록이 최소한의 편집으로 복사되며 실제로 이해하려고 노력하지 않아도됩니다. 물론 오류가 발생합니다. 방금 개발자가 최적화 한 일부 코드를 복사 한 버그가 수정되는 것을 보았습니다. 최적화를 유효하게 한 가정은 그가 어디에 두 었는지 알지 못했습니다.
이 모든 것은 내부 (우리 자신의 기대)와 조직의 기대에 달려 있습니다. 우리는 가능한 한 짧은 시간에 가능한 한 많은 일을하려고 노력합니다. 그리고 오류는 필연적으로 발생합니다.
또한 컴퓨터 응답 성은 빠른 편집과 컴파일 및 테스트 실행을 권장합니다. 예전에는 (35 년 전과 같이) 처리 시간이 너무 느려서 코드를 인쇄하고 (소스는 펀치 카드 였음) 내 덱을 제출하기 전에 코드를 수동으로 처리했습니다. 이제 우리는 단순히 컴파일과 실행을 편집합니다. 따라서 체계적인 코드 연습을 통해 발견했을 많은 버그가 이제 컴파일러 및 / 또는 단위 테스트 스위트를 사용하여 대신 잡습니다.
좋은 코드를 만드는 데 사람들이 어떻게 나빠졌습니까?
당신이 먹는 경우 .NET 및 C # 같은 언어, 예를 들어, 내가 코딩 주장 것 (그리고 나는 그것이 유일한 플랫폼 / 언어 아니다 실현) 잘 때문에 비주얼 스튜디오 내에서 여러 가지의 자동화에 훨씬 훨씬 쉬워졌다 환경.
어쨌든 우리가 코딩 및 개발 프로세스를 안내 할 수있는 매우 정교한 IDE를 보유하고 있다는 사실은 "좋은 코드"를보다 쉽게 달성 할 수있게 해줍니다.
프로그래머는 이제 대괄호와 중괄호와 줄 바꿈을 입력하고 메서드 호출과 클래스 이름을 기억하는 데 많은 시간을 소비하는 대신 실제로 좋은 구조를 만드는 데 집중할 수 있습니다.
내 두 센트
예, 업계로서 우리는 좋은 방법론으로 알려진 것을 실천하지 않습니다. 참조 : Steve McConnell의 Construx 소프트웨어 소프트웨어 개발의 낮은 매달린 과일 .
코드 품질이 좋아지지 않았습니다
"좋은 코드"의 해석에 갇히지 마십시오
훌륭한 논리적 타우 톨 로지.
사람들이 "좋은"이라는 정의를 계속 움직이기 때문에 코드가 나아지지 않습니다.
"좋은 코드"에 대해 논의 할 수 있다면, 비교할 수 없으며 그것이 "도전"인지 아닌지를 결정할 수 없습니다.