유창한 코더가 좋은 관행을 무시한다면, 유창한 사람이 그를 상대하지 않습니까? [닫은]

나는 상당히 크고 버그가 많은 응용 프로그램을 작성 중입니다. 작성 방법으로 인해 (세부 사항을 아끼지 만 생각할 수있는 대부분의 영역에서 규칙을 위반합니다) 주요 리팩토링없이 개발하는 것이 불가능합니다.

앱의 중요한 부분은 인턴, n00bs 등이 작성했습니다. 그러나 마스터 개발자의 순위에 프로그래머가 있었고 모든 겸손으로 그가 남긴 코드는 아마도 다른 방법으로 여전히 모호합니다.

물론, 그의 코드는 대부분의 시간에 작업을 수행하는 경향이 있지만 일반적으로 암호화되어 바퀴를 재발 명합니다 (예 : 다소 일반적인 SQL db 백업을 수행하는 큰 사용자 정의 방법). 기본적으로 불필요 한 혼란과 많은 오버 엔지니어링

그리고 다른 기술을 수반하지 않는 한, 숙련 된 코더 (고의적으로 "개발자"라는 단어를 사용하지 않는 경우가 많음)는 실제로 다른 종류의 독이 될 수 있다고 생각했습니다.

그것이 사실이라고 가정하면, 내가 생각할 수있는 몇 가지 이유는 다음과 같습니다.

• 쉽게 코딩하는 경우 라이브러리, 기존 기능 등을 사용하지 않고도 현장에서 자체 솔루션을 신속하게 스냅 할 수 있습니다.
• 복잡한 프로그램의 정신적 이미지를 쉽게 유지하기에 충분한 경험이 있다면, 모듈, 레이어 등으로 나누려는 경향이 적습니다.

유창한 코더가 나쁜 개발자라면 유창함이 후자를 보상 할뿐만 아니라 실제로 더 많은 해를 입히는 것입니다.

당신은 어떻게 생각하십니까? (그렇다면 어느 정도) 사실입니까?

쉽게 코딩하는 경우 라이브러리, 기존 기능 등을 사용하지 않고도 현장에서 자체 솔루션을 신속하게 스냅 할 수 있습니다.

예. 나는 그 사람이었다. 그리고 나는 그것이 끔찍한 일이라는 것을 배웠습니다.

그것은 모두 당신을 위해 아주 좋습니다, 당신은 새로운 것을 배울 필요가 없습니다.

하지만 나머지 팀은 어떻습니까? 그들은 당신에게 매우 의존하게됩니다. "Clive 's Quicky ORM"에 대해 Google에서 작성한 객체 관계형 매퍼에 대한 도움말을 얻을 수 없습니다.

그리고 새로운 사람을 고용해야하는 날이오고 Clive의 Quicky ORM에 경험이있는 사람들을 찾을 수 없습니다.

그리고 마침내 당신이 떠날 날이 오며 누군가 ORM에 버그를 발견했습니다. 그리고 제품을 테스트하고 수정하는 사람들로 구성된 커뮤니티가 없기 때문에 존재합니다.

그렇습니다. Hibernate를 배우는 것은 가벼운 것을 쓰는 것보다 더 많은 시간이 걸렸을 것입니다. 그러나 그렇게하는 것의 이점은 무시하기에는 너무나 크다, IMHO.

• 쉽게 코딩하는 경우 라이브러리, 기존 기능 등을 사용하지 않고도 현장에서 자체 솔루션을 신속하게 파악할 수 있습니다.

언어에는 능숙하지만 도구에는 익숙하지 않습니다. 그것은 실제로 강력한 코더가 아닙니다. 그것은 단지 한 기술을 연마하고 (언어 지식) 다른 사람이 녹슨 것을 얻을 수있게합니다 (도서관 지식). 다른 방법은 나쁘지만 발견하기 더 쉽습니다.

• 복잡한 프로그램의 정신적 이미지를 쉽게 유지할 수있는 경험이 있다면, 모듈, 레이어 등으로 나누려는 경향이 적습니다.

그것은 단지 기술로 위장한 게으름입니다. 적극적으로 작업중인 내용을 머리에 담기 위해 많은 노력을 기울이지 않습니다. 적절한 이음새를 찾고 코드를 분할하는 데는 기술이 필요합니다. 모든 것을 한곳에 두는 것이 더 빠르거나 낫다고 말하는 코더는 종종 어떤 항목을 분리할지 알 수 없습니다.

"키보드를 클릭하지 않으면 작동하지 않습니다"환경에서 작업하고 있기 때문에 이것이 아닌지 확인하십시오. 우리는 모두 코드를 되돌아보고 우리가 무엇을 생각하고 있었는지 궁금합니다. 또한이 상점은 코드를 리팩토링하는 실습입니까? 그가받지 못한 사치 였을 수도 있습니다.

그러나 우리는 첫 번째 아이디어 (당신이 앉아서 망치는 아이디어)에서 벗어나 계획, 연구, 사고를 조금 더해야합니다. 각 작은 문제를 해결하려는 유혹은 유혹적이며 전체 프로젝트는이 관행으로 어지럽 힙니다. 아무도 "파산하지 않은"문제를 해결하기 위해 사람들에게 비용을 지불하고 싶지 않은 이유는 무엇입니까?

편집 : 답변을 알고있는 사람들을 처벌하지 않도록하십시오. 유창하고 속도가 좋은 코드를 작성하는 사람들이 있습니다. 열쇠는 이런 식으로 모든 문제에 접근하는 것이 아닙니다.

100 %

이것을 보는 냉소적 인 방법은 이러한 종류의 코더가 실제로 대부분의 개발자를 작업 상태로 유지하면서 안정적이고 유연하며 안전한 절반으로 가지 않고도 수천 시간의 개발자 시간을들이 킬 수있는 근본적인 버그를 수정하는 것입니다 , 모듈 식 또는 [좋아하는 소프트웨어 속성] 시스템. 이 시스템은 많은 특유의 특성을 가지고 있기 때문에 이미 존재하는 기능의 95 %와 그 뒤에 역동적 인 커뮤니티가 있어도 다른 것으로의 마이그레이션에 대한 생각은 터무니없고 근거가있는 것으로 간주됩니다.

요컨대, 유창한 코더는 많은 경쟁자보다 더 많은 피해를 줄 수 있지만 가격은 일반적으로 수년에 걸쳐 지불됩니다. 그리고 그들은 보통 단순히 다른 사람이 정의한대로 일을하고있었습니다.

개발자인지 코더인지 어떻게 알 수 있습니까? 불가능하다고 생각하지만 품질 을 낮추지 않고 코드를 간단 하게 만드는 방법을 찾을 때마다 깨달음을 향한 또 다른 단계를 밟았습니다.

설명하신 문제는 기본적으로 NIH ( "여기서는 발명되지 않았습니다")였습니다. 다른 증상이 있습니까?

때때로 NIH, 특히 한 두 사람에게 격리 된 경우 그룹 토론에서 다루어 질 수 있습니다 ( "Joe는 표준 라이브러리를 사용하여 SQL 백업을 수행 한 경험이 있습니다"). 이것은 사람에게 직접 가서 "이봐! 표준 라이브러리를 사용하라."라고 말하는 것보다 덜 대립적 일 수있다. :)

귀하의 상황에 처해 있고 유사한 상황을 초래 한 것은 귀하의 좌절을 이해하지만 귀하의 질문에 대한 대답은 평평한 "아니오"라고 생각합니다. Fluency는 프로그래머가 유지 관리 가능한 코드를 생성한다고 보장하지 않습니다. 종종 조직은 예산과 시간 제약으로 인해 프로그래머가 잘못 설계되고 구현 된 소프트웨어를 제공하도록 강요합니다. 유창한 프로그래머가 고객이 관심을 갖는 것을 제공하기 위해 프로그래머 만 관심을 갖고있을 가능성이 있습니다. 분명히 이것은 실제로는 좋지 않지만 슬프게도 모든 프로그래머가 경력의 어느 시점에서 처리해야하는 현실입니다. 유창한 프로그래머가 게 으르거나 만족 스러울 수도 있습니다. 완벽한 영어를 구사할 수 있지만 속어를 사용하는 것이 더 쉽고 재미 있습니다.

다른 사람의 코드를 사용하거나 자신의 주장을 굴리는 것에 관해서는, 그것이 가장 잘하는 일에 달려 있다고 생각합니다. "최고"가 2 주 안에 6 주 프로젝트를 제공하는 경우 "최고"는 스타일 및 유지 관리 성과 같은 것을 고려하지 않는 경우가 있습니다. 이것이 우리가 리팩토링하고 개선하는 이유입니다. 또한 개발자는 타사 코드와 관련하여 제공되는 내용을 알고 있어야하며 코드를 사용하는 방법을 알고 코드가 작동하고 제대로 지원 / 유지 될 것임을 신뢰해야합니다. 이러한 것들을 사용하는 대중적인 개발 패러다임을위한 수천 개의 선택적 프레임 워크, 라이브러리 및 API가 있다고 가정하면, 사용자 자신을 굴리는 것보다 더 많은 시간, 에너지 및 스트레스를 줄 수 있습니다. 또한 타사 코드가 내가해야 할 일을 정확하게 수행하지 않는 경우를 찾습니다.

나는 그 보트 (유창하게 유창하게 작성된 코드)에 있고 잠시 유창한 유형이었습니다.

"빠르고 더러운"솔루션의 가장 큰 장애물은 나중에 더 많은 솔루션을 추가해야 할 때입니다. 더 많은 기능이 필요할 때 구조 없이는 할 수있는 일이 너무 많습니다. 그 후에는 깨지고 재정렬하는 데 많은 비용이 듭니다 (아직 만족 스럽지만 실제로는 감사하지는 않습니다).

기본적으로, 당신은 열망하는 영업 사원이 판매 할 준비가 된 "가능한 솔루션"이 될 수있는 모든 해킹 으로부터 자신을 보호해야합니다 . 그것은 "준비되지 않았습니다!-그러나 그것은 효과가 있습니다." 수수께끼.