품질 / 표준을 무시하는 소프트웨어 개발자는 회사에 더 적합합니까? [닫은]

코드 최적화, 표준 및 모범 사례를 최우선 순위로 두지 않기로 선택한 소프트웨어 개발자는 적시에 작업을 완료하는 것 이상의 최적화, 코딩 표준 구현 및 사례에 대해 걱정하고 싶은 개발자보다 유용한 코드를 생성합니까?

개별 성능 검토와 관련하여 이러한 방법론을 어떻게 비교합니까?

동료 리뷰에서 이러한 스타일을 어떻게 비교합니까?

SDLC 동안 더 많은 모범 사례를 구현하기 위해 팀에 영향을 미치는 가장 좋은 방법은 무엇입니까?

아니요, 프로젝트의 소유자 만 존중합니다.

그들은 다음 과 같이 몇 년 동안 쓰레기 를 버릴 것 입니다.

• 미래의 관리자
• 미래 테스터,
• 미래의 프로젝트 소유자,
• 미래의 관리자,
• 앞으로 코드베이스에 관련된 사람은 거의 없습니다.

그들은 다음과 같은 치료를받을 수도 있습니다.

• 현재 테스터
• 현재 기술 문서 작성자

거짓 이분법 : 자질은 직교입니다.

                고품질 저품질

수익성있는 멋진 스케치

수익성없는 Iffy FIRE FIRST

때문에 제 모범 사례는 최고 정의에 의해 , 그들이 그렇게 그들입니다 무시, 도로 아래로 빨리 modifcation으로, 짧은 시간에, 더 정확하게하는 프로젝트를 얻을 수 있도록 보장 이익을 감소. 물론 관리자는 자신 이 최선 이라고 생각 하지만 실제로는 그렇지 않다는 관행을 처방 하거나 고객이 지불 할 금액과 그렇지 않은 금액을 잘못 판단 할 수 있습니다.

코딩 표준은 더 까다 롭습니다. 코더에 너무 많은 세부 사항을 규정 할 수있어 효율성이 떨어집니다. 그러나 경험이 있으면 항문 보유 마이크로 관리에서 유용한 지침을 말하기가 매우 쉬워 지므로 실제 모범 사례는 항상 가치가 있고 의사 모범 사례는 항상 가치가 없습니다.

당신이하지 않은 코드 최적화는 일반적으로 일을 가치가되지 않습니다 측정 병목 현상이있는 것을 확인 최적화를 수행하는 것이 필요하다고과 측정 당신의 영리한 트릭 실제로의 preformance의 rquirement을 충족. 그렇지 않으면 (주로) 가치가 없으므로 최적이 아닙니다.

코드 최적화 및 실습에 관심이없는 개발자에게 동의합니까? 아니.

그들은해야 할 일을합니까? 예.

사업은 돈 버는 것에 관한 것이며 돈을 버는 유일한 방법은 제품을 출시하는 것입니다. 이것은 일반적으로 프로젝트에 엄격한 일정이 있다는 것을 의미합니다. 즉, 무언가를하는 가장 좋은 방법은 무언가를하는 가장 빠른 방법이 아닐 수 있습니다.

이러한 스타일의 개발에 동의하지는 않지만 제품이 출시되면 회사에서 존경받을만한 것으로 보일 수 있습니다.

아니, 나는 가장 빠른 경로를 찾아 낼 것입니다 멀리 그 악을 높이 평가했다 회사로부터.

예, 아니오. 약간 소망스러운 워시이지만 최선의 연습이며 완벽한 연습은 아닙니다. 이상적으로는 지속적으로 따라야하지만 항상 비즈니스가 제품 요구보다 먼저 요구를하는 상황이 발생합니다.

당신은 관리자에 의해 미워하지만 상사에 의해 사랑받을 것입니다.

모범 사례는 다소 상식과 비슷합니다. 모든 사람은 두 사람이 자세히 논의하기 시작할 때까지 모든 사람이이를 알아야한다는 데 동의합니다. 두 사람이 정의에 완전히 동의하지 않으며 모든 상황에 적용되는 논리적 진리의 원천이 없습니다.

우주 위성에 대한 안내 시스템을 작성하고 있습니까? 그렇다면 이런 종류의 작업에서 나쁜 품질 / 성능 코드는 결코 용납되지 않습니다.

일회성 마케팅 푸시를위한 끔찍한 웹 사이트를 작성하고 있습니까? 그렇다면 네, 마감일을 맞추는 데 필요한 수단을 통해 보풀을 제거하십시오. 차기 마케팅 이사는 아마도 다른 회사와 다른 일을 할 것입니다. 예술이나 과학이 아닌 것은 유료입니다.

그 사이의 모든 것 : 협상 할 수있는 것, 특히 개발자가 초기 지원을 받기 위해 필요한 경우.

당신이 선호하는 성품이 다시 올 때까지 그리고 그 / 그 / 그녀가 개발 관행을 기적적인 방식으로 정의 할 때까지, 삶과 죽음의 결정에 직접적인 책임이없는 어떤 프로젝트에 대해서도 논쟁의 여지가 많이 생길 것입니다 일회용이 아니기 때문에

생명에 중요한 레이블이있는 모범 사례 이외의 모든 것은 일반적으로 회사 정책, 고객 사양 또는 개인 의견과 유사합니다. 그들 중 다수는 현재 많은 사람들이 동의하는 개인적인 의견이지만 모든 상황에 대한 불변의 가이드는 아닙니다.

그들이 회사를 위해 얼마나 많은 돈을 벌 수 있는지는 논쟁의 여지가 있습니다. 문제의 코드를 다시 방문하는 수준이 있다면 유지 관리 비용이 상승하고 누군가가 행복하지 않을 것입니다. 장기 유지 보수 비용이 높으면 올바르게 수행하는 것보다 비용이 많이 듭니다.

그들이받는 존중의 정도는 사례마다 다를 수 있습니다. 그러나 어느 시점에서 누군가가 알아 차릴 것입니다.

이러한 것들에 신경 쓰지 않으면 단기적으로 회사에 더 많은 돈을 벌 수 있지만 더 많은 버그 수정 및 유지 보수 코딩으로 회사에 더 많은 비용 이들 수 있습니다.

경쟁사와 유사한 제품을 동시에 시장에 출시하기 위해 서두를 필요가있는 경우, 때로는 더 빠르고 더러운 작업이 필요할 수 있지만, 그러한 조치의 향후 비용은 신중하게 고려해야합니다.

그것은 모두 고객에 달려 있습니다.

빠르고 더럽고 (그리고 일반적으로 더 싼) 것을 좋아하는 고객은 앞으로 문제가 발생할지 걱정하지 않습니다.

캐비닛 구성을 생각하십시오.

일부는 양질의 맞춤형 캐비닛을 지불하고 높이 평가합니다. 그들은 나무 서랍과 최고급 하드웨어의 추가 비용을 신경 쓰지 않습니다. 그들은 물건을 짓고 설치하는 데 1 주일 또는 몇 달이 걸릴 것이라고 걱정하지 않습니다.

많은 사람들은 그렇지 않습니다. 많은 사람들이 큰 상자 상점에서 얻는 저렴한 파티클 보드 대량 생산 재료를 선택합니다. 그들은 2 일 안에 설치하기를 원합니다. 여기에 작은 간격이 있으며 완벽하게 수용 가능합니다. 그들은 10 년 후에 헤어질 것이라고 걱정하지 않습니다.

따라서 관리자가 빠르고 더러운 작업을 수행하는 개발자를 칭찬하는 경우 고객은 고품질을 원하지 않거나 관리자가 고객에게 거짓말을합니다.

단지 시간이 말해 줄 것이다. 관리자가 원하는 것을하거나 다른 직업을 찾으십시오.

아뇨. IMO 코드 최적화, 모범 사례, 실제 장인 정신 은 코드베이스에서 가장 중요합니다. 그것 없이는 모든 것이 슬러지가되고 덕트 테이프와 함께 유지됩니다. 지속 불가능한 디자인입니다. 그것은 작고 건강하기 때문에 종양을 무시하는 것과 같습니다. 당신은 지금 건강하지만 길 아래로 몇 년 동안 그것을 오랫동안 무시했기 때문에 터미널이됩니다.

난 단지를하지 아니 이런 것들에 대해 걱정하지 않는다 개발자들과 동의하지만, 나는이 제로 존중 부팅에 대한합니다. 내가 얼마나 짧은 시간을가더라도 조직을 떠나도록 고려할 수있는 확실한 방법은 내가 관심을 가지는 유일한 사람 (회사 전체에서 유일한 사람이 아닌 경우) 인 팀으로 둘러 쌓는 것입니다. 적절한 소프트웨어 엔지니어링 개념에 대해

좋은 읽을 거리 : http://www.joelonsoftware.com/items/2009/09/23.html

그러나 IMHO, 한 사람의 모범 사례는 다른 사람의 악몽입니다. 그리고 사소한 모든 코드 기반은 외부인에게 악몽이 될 것입니다.

당신이 어떻게 생각하든 그것에 대해 바보가되지 마십시오.

편집 : 나는 양쪽에 기댈 수있는 작업에 따라 어떤 직책도 변호하지 않습니다.

회사에 더 좋습니까? 때에 따라 다르지.

제한된 자금을 가진 신생 기업의 경우, 자금을 조달하고 밖으로 나가십시오. 지저분한 것이 든 상관없이 나중에 더 많은 자원이있을 때 고칠 수 있습니다.

소프트웨어의 품질에 의존하는 사용자가 많은 성숙한 제품의 경우 모든 것이 "적절하게"수행되어야합니다.

개별 개발자에게 더 좋습니까? 실제로는 관련이 없습니다. 동료들이하는 일과 똑같이하고 경영진이 낙진을 처리하게하십시오. 그것은 당신의 일이 아닙니다. 당신이 항상 다른 사람들의 쓰레기를 고치면, 당신은 느리게 보일 것입니다. 그리고 당신은 다른 사람들이 당신 위로 승진하는 동안 여전히 거기에있는 사람이 될 것입니다. 프로그램에 참여하거나 그렇게 나쁘다면 가능한 한 나가십시오.

개발자와 프로젝트 / 상황에 따라 다릅니다.

특별한 시간에는 특별한 조치가 필요합니다.

따라서 지금 제공 해야하는 것이 있고 누군가가 최신 버즈 워드 프레임 워크를 14 개 이상 사용하는 엔터프라이즈 급 Java 응용 프로그램을 과도하게 엔지니어링하는 경우 간단한 파이썬 스크립트가 작업을 수행하는 것은 모서리를 자르고 생각하는 개발자만큼 나쁩니다. 버그가있는 코드는 정상적인 시간에 수행됩니다.

개발자가되는 부분은 유연합니다. 도구의 노예가되어서는 안되며 맹목적으로 관행을 따라야합니다. 항상 실패 할 경우가 있습니다. 규칙을 어 기고 구부릴시기를 아는 것은 많은 경험과 함께 제공되는 가치 중 하나입니다.

귀하의 경우-속도가 중요하기 때문에 그가 당신보다 더 많은 가치를 제공한다면, 도로에서 유지 보수 비용 증가를 고려한 후에도 더 나은 보상을받을 자격이 있습니다. 다른 한편으로-당신이 그의 혼란을 청소하는 데 붙어 있다면-경영진과의 의사 소통 문제가 있습니다.

경우에 따라 다릅니다. 코딩 스타일을 제외하고는 변명의 여지가 없습니다.

죄송하지만이 질문에 대한 대부분의 답변에 동의하지 않으면 안됩니다 (상단 답변 제외).

소프트웨어의 주요 가치는 유연하다는 것입니다.

이유없이 다른 사람들의 코드를 다시 작성해야한다고 생각하지 않습니다. 기능을 구현하기 위해 어떤 이유로 든 모듈을 변경해야하는 경우 이제 해당 모듈의 소유자가 더 좋거나 더 나쁩니다. 변경하고 일부를 다시 작성하고 모두 다시 작성하십시오.

유연성면에서 결코 낮은 품질을 생산하지 마십시오. 소프트웨어에 아무것도 버리지 않는 것은 없습니다. 고객이 일시적인 말을하고 특정 날짜 이후에 필요하지 않고 품질에 관심이없는 경우 "나쁘다"라고 말하거나 코드를 한 번만 사용자 나 다른 프로그래머가 변경하지 않을 것이라고 서면으로 작성하십시오. 프로덕션 환경에 배포되거나 소송을 제기 할 권리가 있습니다.

이 답변 중 일부에서 가장 나쁜 가정은 어떤 깨끗한 코드가 어떻게 든 개발 속도를 줄인다는 것입니다. 어떤 물질 (6 시간 이상의 작업)의 프로젝트에 대해서도 깨끗한 코드는 장기적으로 (1 주일 이상) 개발 속도를 높입니다. 나는 그것을 몇 번이고 또 다시 보았다.

품질이 좋지 않은 코드는 직업과 동료에게 무례합니다. 미안하지만 사실입니다.

따라서 유연성 측면에서 품질이 떨어지는 것은 아닙니다!