누군가가 나쁜 프로그래머로 간주되는 시점은 언제입니까? [닫은]

프로그래머가 자신이하고있는 일이 잘못되었다고 어떻게 생각하십니까?

가능하다면 ... 어떻게 개선해야합니까?

그들이 실수와 동료 리뷰로부터 배우지 못하는 경우.

우리는 어느 시점에서 모두 녹색입니다. 그러나 나아지지 않거나 나아지려고하면 나쁜 프로그래머가됩니다.

자신이 모르는 것을 모르고 전혀 관심이없는 프로그래머.

큰 경고 신호는 그들이 "카고 컬트 (cargo cult)"프로그래머라면, 그들이 일을하지만 왜 그런 일을 하는지 모르는 것입니다 (단지 "마법"입니다). 에릭 Lippert의에 의해 위대한 포스트 여기 .

기사에서 :

코드의 기능을 이해하지만 코드의 기능을 이해하지 못하는 프로그래머

저에게 큰 팁은 그들이 당신이나 다른 프로그래머들에게 질문을 할 때 스스로 알아 내기 위해 전혀 노력을 기울이지 않았다는 것을 분명히 보여줍니다.

결과는 그들이 정보를 내재화하지 않았 음을 나타내는 동일한 프로그래밍 질문을 여러 번 요청할 때입니다.

FizzBuzz 문제를 해결하는 데 시간이 오래 걸립니다.

새로운 기술 / 언어를 배우기를 거부하고 이미 알고있는 것을 고집하는 프로그래머.

부록 : (의견에서 대시가 아래에 말한 것을 추가)

이것의 확장은 일부 기술의 기능 중 일부를 알고 있지만 그것에 대해 더 배우고 싶지 않은 사람들입니다. 프로그래밍 언어, 편집기, 기타 도구 ...

팀원이 부정적인 생산 개발자 인 경우 .

|# Lines Written| - |# Lines of bugs introduced| - |# Lines of rework required| < 0

즉, 나머지 팀은 나쁜 개발자로 인해 더 많은 작업을 수행해야합니다. NNPP

그들이 매일 WTF 에 정기적으로 표시 되는 것을 생산할 때 .

그들이 일을하는 더 좋은 방법이 있다는 것을 알고 있지만 시간이 허락 될 때조차도 그 일을 거부합니다.

개인적으로 필자는 얼마 전에 작성한 코드를보고 문제가없는 프로그래머는 좋지 않다고 생각합니다. "한동안"은 경험에 따라 확장 될 수 있습니다 ... 몇 주에서 최대 1 년 정도라고 말하고 싶습니다.

코드의 경고를 무시하고 오류에만 관심이있는 사람.

내가 작은 가게에서 팀장을 지냈을 때, 내가 재지 정해야했던 사람들이 몇 명 있었는데 (나 또는 직접 감독자에게 많은 빨간 테이프 와 문서가 없어도 종료 기능 이 없었거나) 계약 갱신이 없었습니다. 현재 참여가 끝날 때 열거 된 유형 중 일부는 다른 팀 리더에게도 적용되었으며 거의 ​​동일한 견해를 보였습니다. 사람들을 저의 책에서 "나쁜 프로그래머"범주에 넣은 것 :

1. 과거에는 훈련 할 수 없거나 골란 화됨
   '프로그래머'가 훈련 / 훈련을 수행하는 방법에 관계없이 새로운 시스템, 새로운 도구 또는 배포되는 모든 것을 흡수 할 수없는 것처럼 보일 때. 상기 훈련을 빈번하게 반복해야한다.
   '프로그래머'가 10 년 또는 15 년 전에 사용한 기술 또는 코딩 패러다임을 알고있을 때. 그때는 충분히 좋았으므로 왜 바꿔야합니까?
2. 카우보이 코더
   계획없이 먼저 코딩 하는 사람. "지금 수정해야하기 때문에"프로덕션 코드 및 / 또는 데이터를 테스트하지 않은 "프로그래머"가 수정 한 다음 "수정"이 실패하면 놀라게됩니다.
   카우보이는 또한 확실히 팀 선수가 아닙니다. 냄새 나는 팀이 필요하지 않습니다.
3. 날씨 - 베인
   이 '프로그래머'는 "기술과 매혹 금일의 "모든 새로운 프레임 워크, 언어, 방법론을보고하거나 새로운 뭐든 뜨거운 는 AS
4. "빅 브레인 (Brain)"
   이 '프로그래머'는 그의 재능과 능력을 확신하여 많은 프로젝트 이해가되지 않는 일들이 이루어 지도록합니다. 예를 들어 "우리 시스템에는 비효율적이기 때문에"표준 라이브러리를 다시 작성하거나 현재 문제에 적합하지 않은 도구와 기술을 소개합니다. 예를 들어 메인 프레임 환경에서 Lisp 또는 Forth 소개.
5. LOC의 ^가. Sandbagger
   이 '프로그래머'는 난독 화와 잘못된 방향을 사용하여 ^a 를 증가시킵니다 ^. LOC : 지불 되는 코드 라인 . 이 상황에서 페이지 뒤, 중복 구조 및 논리 화면 뒤의 화면 인 코드 또는 단락 또는 제어 변수 이름만이 줄 수를 늘리기 위해 변경된 코드를 보았습니다.
6. 없어서는 안될 전문가
   당면한 문제를 해결하기위한 도메인 지식이 있지만 '문제를 알고있는'프로그래머입니다. 실제로 버스에 치면 전체 조직이 무너질 것입니다. { 관찰 : 자신이 없어야한다고 생각하는 사람들은 대개 있습니다. (누구든지이 격언의 근원을 얻었습니까?)}
7. 파스타 셰프이
   '프로그래머'는 스파게티 코드를 전문으로하며, 구문 적으로 구현 된 IDE없이 따르기가 너무 어려운 식별자로 구성되었습니다. 예 : IndexI1O0, Index1I0O 등
8. Summer Intern-특수 하위 유형 워킹 재해
   나의 오래된 상점은 많은 고등학생 또는 대학생 인턴을 고용하는 데 사용되었습니다. 한때 부서에서 일부 장비 사용을 추적하기 위해 작은 데이터베이스가 필요했습니다 (이제 포기되었으며 dBase III을 사용하고있었습니다). 그 남자는 여름 내내 코딩을했지만 대학이 가을에 시작했을 때는 끝나지 않았습니다. 그는 1 주일 연장 후 2 주가 연장되었습니다. 두 번째 주가 끝날 무렵, 나는 그의 프로젝트를 인수하고 시스템 개발에 다시 가져 와서 끝냈습니다. 그는 나에게 그가 한 일과 미완성 된 부분을 보여주었습니다. 효과가 좋은 아이 캔디가 있었지만 응용 프로그램 은불완전한. 사본을 얻기 위해 새 포맷의 플로피 상자를 열었을 때, 그는 "잠깐만, 테스트 파일을 삭제하겠습니다 ..."라고 말한 후 아무 말도하기 전에 많은 파일을 삭제했습니다.
   의심스러운 종류 였고 가게로 돌아 왔을 때 그의 응용 프로그램이 눈 사탕에 지나지 않았다는 것을 알게 된 후 부서로 돌아가서 Norton을 꺼내고 삭제 한 파일을 삭제하지 않고 추가 논리를 찾으려고 노력했습니다. 불완전하더라도.
   나는 나쁜 논리가 아니라 나쁜 행동을 발견했습니다. 그가 사용하고 있던 PC에 연결된 프린터는 데이지 휠 프린터였습니다. 일반적으로 마운트 된 문자 세트는 스위스 변형이었습니다. 삭제 된 프로그램의 출력은 이름, 주소, DOB, 일부 문자 코드 및 일부 유형의 ID 번호를 표시합니다. 형식과 레이아웃이 나를 귀찮게했습니다. 여러 사람의 생년월일은 거의 법적 음주 연령이었습니다. 내가 십자형 디렉토리에서 찾을 때 대부분의 주소는 거기에 없었습니다. 내가 그의 상사에게 인쇄물을 보여줄 때, 그는 나를보고 "운전 면허증, 당신은 생각하지 않습니까?"라고 말했습니다. 나는 그렇게 말했다. 그는 이것이 제록스 옆 쓰레기통에있는 투명성 원료를 모두 발견 한 이유라고 말했다. 우리의 나쁜 소년은 운전 면허증으로 자신과 친구의 나이를 조정하기 위해 오버레이를 만들었습니다. 당국에 신고했습니다.그의 마지막 2 주 동안은 지불 하지 않았습니다 .

이것들은 내가 함께해야했던 나쁜 캐릭터 중 일부입니다 ....

/ s / BezantSoft

다가오는 기술에 적응할 수 없습니다

지식 / 능력의 명백한 부족과는 별도로, 프로그래머는 코드가 읽기 및 / 또는 유지하기가 어렵다면 나쁜 것입니다.

아무도 그의 코드를 읽을 수 없을 때. 얼마나 밝아도 상관 없습니다. 어떤 프로그래머도 섬이 아닙니다.

세부 사항에주의를 기울이지 않고 항상 작동하는 사람은 항상 작동합니다. 로그에있는 모든 예외는 중요하지 않습니다.

나를 위해 프로그래머에는 솔로와 팀의 두 가지 범주가 있습니다.

나쁜 솔로 프로그래머들은

• 간단한 작업을 수행하는 데 너무 오래 걸린 사람들.
• 그들이하고있는 일에 대해 스스로 연구 할 수없는 사람들.
• 며칠 내에 오늘날 코딩 된 것을 잊어 버리고 자신의 코드 기반을 잘 유지할 수없는 사람들.
• 요구 사항 변경에 적응할 수없는 사람들.

나쁜 팀 프로그래머는 다음을 포함하여 나쁜 솔로 프로그래머 범주에 속하는 사람들입니다.

• 다른 팀원과 조율 할 수없는 사람.
• 비판을 환영하지 않는 사람들.
• 다른 사람에게 유용하고 다른 팀원의 혜택을받는 방법을 모르는 사람.
• 읽을 수있는 코드를 작성할 수없는 사람들.
• 가독성을 위해 다른 사람들에게 논평하지 않는 사람들.

그들이 기꺼이 대답을 알지 못하거나 물건을 찾는 것을 꺼려한다는 것을 인정하지 않습니다.

당신이 그것을 모른다면 포기하지 마십시오. 알아 내고 끝내십시오.

내 경험에 큰 경고 표시는 해킹에 대해 언급하지 않을 때입니다.

당신은 내가 의미하는 바를 알고 있습니다 : 당신이 할 일이 더 이상 없기 때문에 매우 해킹을해야만 할 때.

좋은 프로그래머는 그렇게해야하는 것을 싫어하고 그러한 종류의 해킹을 얼마나 싫어하는지 말하는 인라인 주석을 달지만 선택의 여지가 없습니다. 나쁜 프로그래머는 방금 해킹에 넣고 언급하지 않습니다.

프로그래머가 많은 코드를 작성할 때 분명히 조용하십시오. 프로그래머가 원하는 것을 수행하는 표준 기능을 모르지만 시간이 많이 걸리지 않기 때문에 매우 큰 기능, 아마도 복사 또는 붙여 넣기 행 또는 코드 블록 등이 필요할 수 있습니다.

그것을 하는 올바른 방법을 반복적으로 보여 주면서 반복적으로 쉬운 방법을하는 것.

나는 당신이 나쁜 프로그래머인지 알 수 있습니까? 응답을 작성하면서 다른 주제가 종료되었습니다. 내 대답은 다른 질문자가 표현한 질문을 더 직접적으로 다루며 이해하면 더 잘 읽을 것입니다.

한숨! 내 일부는 이미 바쁜 주제에 추가하고 싶지 않았지만 다른 부분은 이겼습니다! 왜 이겼습니까? 왜이 특정 다자간에 더 많은 단어를 추가하려고합니까? 글쎄, 어느 정도까지, 나는 이전의 많은 주석가들과 약간 다른 견해를 가질 수 있기 때문입니다.

이진은 컴퓨터에서 훌륭하게 작동합니다. '1'또는 '0', "on"또는 "off"입니다. 우리는 유명한 두 가지 상태를 사용하여 많은 정보를 추상화하고 인코딩 할 수 있습니다. 그러나 "좋은"또는 "나쁜", "정신"또는 "미친", "좋은"또는 "사악한", "스마트 한"또는 "멍청한", "뚱뚱한"인간의 경우에는 잘 작동하지 않는 경향이 있습니다. 또는 "얇은", "살아있는"또는 "죽은?" 이런 종류의 양극화 된 평가는 항상 돌보는 인간이 나를 만족시키지 못하도록 내버려 두었습니다. 어떤 측정 방식을 적용하든, 나는 일반적으로 그러한 뚜렷한 대비에 대한 답이 실제로 한쪽 끝이 아닌 다른 쪽 기둥 사이의 연속체를 따라 어딘가에 있다는 것을 알았습니다.

나는 지금까지 한동안 양극화 경향에 맞서 싸웠고, 개인적 해결책은 그러한 평가에 세 단어를 적용하는 것이 훨씬 더 유용하다는 것입니다 : " 어느 정도!"

따라서 귀하의 질문에 대한 나의 대답은 당신이 그 말을 다시 말하고 다음과 같이 자문 해 보라고 제안하는 것입니다. 또는 다른 방향으로 물어 보는 것이 더 좋습니다. "저는 어느 정도 좋은 프로그래머입니까?" 진실을 추구한다면 아마도 "나쁜"프로그래머와 "좋은"프로그래머의 연속체를 따라 어딘가에있을 것입니다. 그런 다음이 경로를 따라 대략적인 위치를 찾으면 "좋은"쪽에 가까운 지점, 즉 가까운 미래에 자신을 찾을 지점을 식별 할 수 있습니다.

해당 지점을 너무 멀리 설정하지 않으면 후단이 기어로 ​​들어가 해당 방향으로 움직일 수 있습니다. 이 간단한 휴리스틱 알고리즘을 여러 번 반복하면이 질문에 다시 질문하기에 너무 바쁜 프로그래밍이 곧 발견 될 수 있습니다! 아, 그리고 가능한 빨리 그리고 자주 키보드로 코드를 두드리기 시작하면 더 빨리 진전을 보일 것입니다. 그리고 잠시 휴식을 취하면 동료들이 작성한 고품질 코드를 읽으십시오! 요즘 역동적 인 오픈 소스 개발에서 배울 수있는 자유롭고 정교한 코드가 부족하지 않습니다!

그래서, 나는 당신이 "어느 정도까지"나의 작은 세 단어를 시도하고 그들이 당신을 데려 갈 수있는 좋은 방향으로 얼마나 멀리 있는지를 강력히 추천합니다!

"할 수 없다"고 말하는 사람.

제 생각에는 문제 해결에 관한 것입니다. 도구는 실제로 작업을 수행하는 것보다 관련성이 적어야합니다. MS-Access 또는 어셈블리 언어를 사용하여 문제를 해결해야한다면 시간과 비용 문제가 아니라 "수행 할 수 없습니다"라는 문제가 아닙니다.

경고 표시는 학업적이고 "적절한"일을하는 방식에 너무 집중되어 있고 일을 완수하는 데 초점이 맞지 않습니다.

그가 언어의 구문 만 알고 알고리즘의 기본 개념을 모른다면.

그들이 많은 화를 내지 만 아주 적은 양을 생산할 때.

! (똑똑하고 일을 끝내줍니다)

SOLID, DRY, OOP 등과 같은 원리를 모르는 사람들. 특정 기술을 알기보다는 프로그래밍 원칙과 기초를 잘 이해하는 것이 중요합니다. 탄탄한 기초를 가진 사람들은 새로운 주제를 쉽게 배울 수 있고 더 나은 코드를 만들 수있을 것입니다.

이해하지 못하는 임베디드 프로그래머는 인터럽트 나 멀티 태스킹을 잘 이해합니다. 비트 필드로 작업해야하지만 논리 연산과 시프트를 파악하지 못하는 프로그래머도 있습니다.

즉각적인 인식 신호는 "왜 작동하지 않는지 이해하지 못합니다. 모든 것을 올바르게했습니다."라고 말하는 사람이 있습니다.

나쁜 프로그래머와 초보자 프로그래머를 구별하는 한 가지는 자신이 좋아하는 시스템을 어떤 언어와 API로든 구현하려는 완고한 주장입니다.

이전 개발자가 Java로 대규모 사용자 정의 dbf 액세스 라이브러리 위에 계층화 된 Ashton Tate DBase III + API 세트를 다시 구현 한 시스템을 한 번 상속했습니다. Java 콜렉션 프레임 워크가 사용되지 않았습니다.

그래서 그는 DBase III + (또는 클리퍼) 앱처럼 보이고 작동하는 Java / 스윙 앱을 작성할 수있었습니다.

이 시스템에서 그가 작성한 앱에는 라이트 바 메뉴가 있으며 라이트 바를 옵션으로 탐색 할 때 맨 아래에 버튼 행이있는 전체 창 양식이 열립니다. 1980 년대의 작은 타임머신이었습니다.

남자는 분명히 숙련 된 개발자였습니다. 그는 프로젝트 전체의 기간 내에 전체 시스템을 직접 작성할 수 있음을 충분히 알고있었습니다. 또한 다른 내부 시스템에서도 재사용 할 수있었습니다.

그러나 그는 자신의 코드가 자신이 작업 한 시스템의 기능을 잘못 사용했기 때문에 끔찍한 프로그래머였습니다. 그는 Java / Swing / SQL을 배우는 것보다 모호한 혜택의 사용자 정의 라이브러리에 3 개월을 더 기꺼이 투자했습니다.