코드에 정서적 첨부 [닫기]

회사의 직원으로서 코드를 작성할 때 첨부 파일이 있다고 생각하십니까? 코드의 소유권이 있다고 생각하십니까? 아니면 다른 곳으로 옮긴 후에 무슨 일이 일어나는지 걱정하지 않고 완전히 분리하여 쓰십니까?

편집 : 나쁜 코드를 작성하고 실행하는 것에 대해 이야기하고 있지 않습니다 ...

계약자로서 30 년이 지난 후에는 혼합되어 있습니다.

1. 모두 일회용입니다. 나는 수백 명의 고객과 일해 왔습니다. 코드를 다시는 볼 수 없습니다. 왜 첨부됩니까? 소유권 감각이 없습니다.

2. 매우 잘 보입니다. 사내 코드보다 비싸므로 많은 조사가 필요합니다. 내가 그것을 유지하기 위해 주변에 없기 때문에, 그것은 매우 많은 조사를받습니다. 코드 연습과 핸드 오버는 매우 중요합니다. 장인 정신에 자부심이 있습니다. 그러나 소유권은 없습니다.

나의 기록은 17 년의 생산이다. 모든 종류의 유지 보수가 필요없는 그 해의 12 년.

전화를 받았기 때문에 알고 있습니다. 그들은 회계 시스템을 수정하고 몇 년 전에 내가 만든 영리한 비용 할당 알고리즘을 대체하는 방법을 알고 싶었습니다. 코드를 살펴본 결과 12 년 전 마지막 개선 이후 파일이 변경되지 않았습니다. (버그 수정이 아님, AFAIK)

내가 아는 바로 그 다음으로 가장 긴 기간은 7 년간의 완벽한 운영이었습니다. 그러나 Y2K에 심각한 문제가 있었으며 4 자리 연도의 파일 이름을 사용하기 위해 일부 재 작업이 필요했습니다. 내부 알고리즘은 모두 정확했지만 로그 파일이 잘못된 순서로 나타납니다.

다시 말하지만, 내가 마지막으로 릴리스 한 이후 파일이 수정되지 않았기 때문에 결함이 없다는 것을 알고 있습니다.

그렇습니다. 장인 정신에는 많은 자부심이 있습니다.

그러나 "소유권"은 없습니다. 내 코드가 아니라 코드입니다. 나는 단지 그것을 구축합니다.

다소 독창적 인 개발자로서, 내가 쓰는 것을 유지해야한다는 두려움은 끔찍한 코드를 쓰지 않으려는 주된 원인입니다.

직장에서 코드의 일부는 내 코드이며, 내가 앉아있는 의자가 내 코드와 비슷한 의미입니다. 나는 그것을 썼고, 내가 할 수있는 한 그것을 좋게 만들었고, 그것을 소유하고 있다고 느끼고, 사람들은 저에게 변화에 대해 물어볼 것이고, 사람들은 그것을 내 것으로 언급 할 것입니다. 그리고 의자와 마찬가지로 회사를 떠난 후에는 다시는 볼 수 없으며 더 이상 감정적 인 애착이 없습니다.

"광산"이라는 단어는 그 의미에 많은 변형이 있습니다. "나의 아내"와 "내 칫솔"은 완전히 평행하지 않습니다.

자신을 위해 코드를 작성하면 그것에 대한 감정을 가질 여유가 있습니다. 비즈니스 용 코드를 작성하는 경우 가능할 때마다 해당 감정을 악의적으로 제거해야합니다. 나는 훌륭한 프로그래머가 코드에 감정적으로 다가 가서 슬픔을 일으키는 횟수를 셀 수 없다.

"나는 그것을 만들었지 만, 그것은 좋았지 만 내 것이 아니고 더 많이 만들 수 있습니다." 당신 이 그것을 믿는 다면, 열등한 제품에 대한 영업 담당자가 상사에게 점심을 먹여 보스에게 BJ를 주었기 때문에 6 개월의 삶이 쓸모 없게되면, 당신은 그를 미치게하여 직장을 잃지 않습니다.

그들이 당신을 지불한다는 것을 기억하십시오. 우리 모두는 멋진 일을하고 싶어하지만, 그들이 구멍을 파기 위해 돈을 내고 다시 채우면, 그 특권입니다. 난 그냥 다음 끔찍한 다음 기능 개월을 포함 개월 동안 웹 응용 프로그램, 쓴 상황이 있었다 더 원래의 상태로 코딩. SVN 저장소에서 뽑은 마지막 2 주 분의 "작업"은 새 버전 번호로 다시 커밋되었습니다. 그리고 난 괜찮아

아니요,하지만 원래 작성한 코드에서 다른 사람들이 도입 한 버그를 수정해야하는 것이 정말 싫습니다. 변경 사항이 처음에 나에게 할당되면 더 행복 할 것입니다. 수정 프로그램이 원래 디자인과 완전히 다른 경우 (예 : 상위 레벨 모듈로 순환 종속성 작성) 더 싫어합니다.

예, 아니오

예-자동차 디자이너가 도로에서 디자인 한 자동차를 볼 때 자랑 스럽거나 창피한 것처럼 직접 만든 것이기 때문에 첨부 파일이 있습니다.

아니요-소유권이있는 한 일반적으로 회사에서 일하기 위해 지불받는 대가로이를 포기합니다. 자동차를 생산하는 공장 직원은 시간을 지불하기 때문에 전화를 끊는 사람마다 소유권을 갖지 못합니다.

내가 작성한 코드에 대해 매우 독점적이라고 생각합니다. 그것은 주어진 문제를 해결하는 방법에 대한 결정을 나타내므로 문제를 합리적으로 생각하고 논리적이고 희망적으로 우아한 해결책을 고안하는 나의 능력을 반영합니다. 즉, 회사 시간에 내가 쓰는 모든 것은 회사에 속합니다. 나는 그 중 어느 것도 나를 물지 않기를 희망하며, 내 자신의 코드를 수정하라는 요청을 받고 싶지만 그렇지 않은 경우에는 그렇지 않습니다. (그리고 3 개월 전에 코드를 작성하고 소스 제어에 내 이름을 넣은 사람은 바보라고 덧붙일 수 있습니다).

전혀. 체크인 한 후에는 더 이상 "광산"이 아닙니다. 당연히 유지 보수 및 문제 해결을위한 사람이 될 것이지만, 그것에 대한 소유권은 없습니다.

나는 코드에 대해 독점적 이라고 생각하는 사람들 이 누군가가 버그를 수정하거나 먼저 버그를 수정하지 않고 버그를 수정하면 짜증을내는 지점까지 알고있었습니다. 나는 그렇게 느낀 적이 없다. 내가 묻는 것은 코드에서 문제를 찾아서 고치면 문제가 무엇인지, 어떻게 해결되었는지 알려 주면 앞으로도 같은 실수를 저 지르지 않을 것입니다.

나는 내가 쓰는 코드를 좋아한다. 나는 그들을 이해하고 다른 사람들도 그렇게 할 수 있도록 조정합니다. 사람들이 내게 다가와 "Dude, 우리는 여전히 우리를 위해 작성한 스크립트를 사용하고 있습니다. 매우 안정적이고 이식 가능합니다"라고 말하면서, 나는 그 자부심과 소유권의 느낌을 좋아합니다.

어디에서 끝날지 알 수 있다면 코드에 첨부되는 데 아무런 해가 없습니다. 즉, 모든 것이 사내이고 누가 또는 무엇을 프로그래밍하고 있는지 알고 있다면 실제로 얻는 것이 좋습니다. 첨부. Coz는 더 많은 광채를 만드는 것을 좋아할 것입니다.

반면에 코드가 클라이언트의 속성으로 끝날 경우 (@ S.Lott의 말을 반복 할 수 있음을 완전히 알고 있음), 감정을 이해하는 데 아무런 의미가 없습니다. 친구가 휴가를 갈 때 강아지를 돌보는 것과 같습니다. :-/

코드를 다시 보지 못할 수도있는 계약자 및 컨설턴트는 코드에 정서적으로 연결되는 이상적인 후보가 아닐 수 있습니다. 그것을 계속 "버려야"하는 것은 아마도 빈약 한 컨설턴트를 창의적 드라이브를 무너 뜨릴 것이다.

계약자가 아닌 직원의 관점에서 보면 모든 팀원이 작성한 코드와 생성 된 모든 것에 대해 소유권을 느끼기를 원합니다. 이 소유권과 자부심은 팀 전체로 확대되어야합니다. 자부심과 소유권을 느끼면 문제의 제품에 대한 애착이 생겨 팀 구성원의 업무에 의미와 감각이 추가됩니다. 나는 이것이 소규모 팀에서 대규모 팀으로 성능을 크게 향상시키는 것을 보았습니다.

피해야 할 것과 싫어하는 것은 그들이 작성한 특정 코드 줄에 감정적으로 붙어있는 것처럼 보이고 그것을 무덤에 지키는 사람들입니다. 그들은 변화를 원치 않으며, 변화 나 개선에 대한 아이디어를 내려다보고 거절하며 믿을만한 말로 정당화하려고 노력합니다. 이것이 내 경험으로 볼 때 자주 나타나는 것은 변화에 대한 두려움과 미지의 것에 대한 두려움입니다. 실제로 문제가되는 이전 코드 줄을 포기하지는 않습니다. 대신, 때로는 자신이 직접 작성하지 않은 새로운 무언가를 가져와야하며 실패하지 않을까 두려워합니다.

이런 종류의 "병에 걸린"코드 첨부는 내가 막기 위해 열심히 노력한 것입니다. 그러나 제품에 대한 "건강한"정서적 연결과 확장 된 서면 코드는 제가 권장하는 것입니다.

이것은 흥미로운 질문이며 위의 게시물 중 하나에 동의합니다. 예 및 아니요-그러나 다른 이유로.

코드에 첨부되어 있습니까? 분명하게 예입니다. 그러나 코드 자체가 아니라 전체 아키텍처 및 응용 프로그램 이라고 생각합니다 . 일반적으로 IDE를 작성하지 않는 한 재귀에 갇히지 않으면 비즈니스 사람들이 원하는 것을 실제로 코드에 포함시키기 전에 많은 도메인 특정 연구를 수행해야합니다.

반면에 : 코드베이스의 쓸모없는 부분을 버리는 것보다 내가 좋아하는 것은 많지 않습니다. 글쓰기가 아무리 어려워도 여행은 제품보다 훨씬 중요합니다 (적어도 자아에게는 물론 제품 자체도 작동해야 함).

소유권 감각이 있습니까? 프로젝트 상황에 따라 다릅니다. 코드를 다시 볼 수 없을 때 (프로젝트의 일부가 끝났고 계속 진행하고 있기 때문에) 왜 물건에 대해 낭만적입니까? 그러나 (어떤 방식 으로든) 계속 지원한다면 애착감이 좋습니다! 당신이 만들고있는 제품에 대해 관심을 가질 때, 기회는 매우 높습니다.

그래서 저는 제가 작성한 코드로 실용적인 "관계"를 채택하려고합니다.

지옥 네, 한 번 동료를 두들겨서 몇 가지 변수의 이름을 바꿀 정도로 거만했습니다.

아니 정말. 소프트웨어 개발에 대한 대가를받습니다. 인정하지만 다른 개발자가 내 코드에 버그 수정을하는 것은 자아에 영향을 미칩니다.