소프트웨어 산업에서 나쁜 프로그래밍 관행이 일반적입니까? [닫은]

방금 한 달 전에 소프트웨어 개발자로 첫 직장을 시작했습니다. OOP, SOLID , DRY , YAGNI, 디자인 패턴, SRP 등에 대해 배운 모든 것은 창 밖으로 던져 질 수 있습니다.

그들은 C # .NET Webforms를 사용하고 거의 객체가 아닌 외부 클래스가 거의없는 Code Behind 내의 거의 모든 것을 수행합니다. 사용자 지정 컨트롤을 사용하고 재사용합니다. 사용되는 유일한 개체는 Entity Framework 입니다. 각 고객에 대해 코드 숨김을 재사용합니다. 모든 유형의 작업을 수행하는 길이가 400 줄인 메소드가 있습니다. 새 클라이언트의 경우 aspx 및 aspx.cs를 가져 와서 클라이언트 코드를 제거하고 새 클라이언트 특정 코드를 추가하기 시작합니다.

첫 번째 변명은 추가 유지 보수를 추가하고 더 많은 코드가 더 많은 유지 보수라는 것입니다. 나 자신을 포함하여 세 명의 개발자로 구성된 소규모 상점입니다. 한 개발자는 30 년 이상의 경험이 있고 다른 개발자는 20 년 이상의 경험이 있습니다. 하나는 게임 개발자 였고 다른 하나는 항상 C와 C ++에서 일했습니다.

소프트웨어 산업에서 이것이 얼마나 흔합니까? OOP 및 관련 원칙을 준수하도록하려면 어떻게해야합니까? 나는 여가 시간에 연습을하고, OOP를 더 잘 배우기 위해 더 숙련 된 개발자와 함께 일해야한다고 생각합니다.

1. 당신이 당신의 질문에 인용 한 원칙은 바로 ... 원칙입니다. 명령, 법률 또는 명령이 아닙니다.
2. 이러한 원칙을 따르는 사람들은 매우 영리하지만 절대적인 권위는 아닙니다. 그들은 단지 통찰력과지도를 제공하는 사람들입니다 .
3. 프로그래밍하는 "올바른"방법은 없습니다. 이것은 우리가하는 "허용 된"방식이 시간이 지남에 따라 급격히 변화하고 계속 변화한다는 사실에 의해 입증됩니다.
4. 제품 배송은 종종 "올바른"방법보다 우선합니다. 이것은 기술 부채 라는 이름을 가진 일반적인 관행입니다 .

5. 일반적으로 사용되는 일부 소프트웨어 아키텍처는 적합하지 않습니다. 모범 사례는 대규모 단일 애플리케이션에서 느슨하게 결합 된 모듈 모음으로 발전하고 있습니다.

6. 상황이 중요합니다. 많은 건축 원칙은 대규모 프로그램이나 특정 도메인으로 작업 할 때만 가치를 입증 합니다. 예를 들어, 상속은 UI 계층 구조와 깊게 중첩되고 밀접하게 연결된 배열에서 이점을 얻는 기타 구조에 주로 유용합니다.

그렇다면 광야에서 나올 수 있도록 원칙적인 길인 "올바른"길을 어떻게 따르십니까?

1. 정확성보다는 적합성을 연구하십시오 . 소프트웨어 개발에서 무엇이든 할 수있는 "올바른"방법은 특정 요구 사항을 가장 효과적으로 충족시키는 방법입니다.
2. 장단점을 연구하십시오. 소프트웨어 개발의 모든 것은 절충입니다. 속도를 높이거나 메모리를 적게 사용 하시겠습니까? 실무자가 거의없는 표현력이 뛰어난 프로그래밍 언어 또는 많은 개발자가 알고있는 표현력이 적은 언어를 원하십니까?

3. 시대를 초월한 공부. 일부 원칙은 시간의 시험을 견뎌냈으며 항상 관련이 있습니다. 타입 시스템은 보편적입니다. 일류 기능은 보편적입니다. 데이터 구조는 보편적입니다.

4. 실용주의를 배우십시오. 실용적이 중요합니다. 배송 할 수없는 경우 수학적 순도, 수정 대성당 건축 및 상아탑 원리는 쓸모가 없습니다.

5. 열성이 아닌 장인이 되십시오. 최고의 소프트웨어 개발자는 규칙을 알고있는 것이 타당 할 때 규칙을 어기는 방법을 알고있는 사람들입니다. 그들은 여전히 ​​문제를 해결하고 스스로 생각하는 방법을 알고있는 사람들입니다. 그들은 원칙을 사용하여 자신의 선택을 지시하고 지시하지 않고 정보를 제공하고 안내합니다.
6. 코드를 작성하십시오. 많이. 소프트웨어 설계 원칙은 많은 코드를 작성하고 올바르게 적용하는 방법에 대한 본능을 개발할 때까지 조기 최적화입니다.

드문 일이 아닙니다. 알아야 할 한 가지는 소프트웨어 산업이 엄청나게 다양하다는 것입니다. 일부 회사는 최첨단입니다. 4 대 갱과 같은 유수의 사람이나 그룹뿐만 아니라 유수의 대학과 혁신적인 소프트웨어 회사 (대부분의 실험실도 포함)는 일을하고 새로운 언어, 기계, 도구 및 패턴을 발명하는 일반적인 방법으로 발생하는 문제를 분석합니다. 새로운 회사, 종종 분사 또는 분할은 상업적으로 사용하려고 시도하며 때로는 놀라운 성공을 거두고 있습니다. 페이스 북이나 구글을 생각하십시오.

그러나 소프트웨어는 오늘날 거의 모든 곳에서 사용되며, 실제로는 실제로 소프트웨어 회사가 아닌 회사에서 주로 사용됩니다. 나는 주로 교통 산업 (자동차 및 철도)에서 일했으며 경험이 혼합되어 있습니다. 그러나 그들 중 어느 것도 "최첨단"가까이에 없었습니다. 때때로 그들은 할 수 없습니다. 안전 관련 소프트웨어는 검증 된 도구에 의존합니다 (현재 1990 년대에 검증 된 C ++ 컴파일러를 사용하고 있습니다). 때때로 그들은 적절한 사람들이 없습니다. 종종 소프트웨어는 소프트웨어가 점점 더 중요해 졌을 때 회사의 소프트웨어 개발에 착수 한 다른 분야의 엔지니어들에 의해 개발되었습니다. 소프트웨어 엔지니어링 원칙을 알거나 사용할 것으로 기대할 수는 없습니다.

고려해야 할 또 다른 사항은 실제 엔지니어가 중요한 것입니다. 종종 당면한 과제는 문자 그대로 로켓 과학이 아닙니다. 비 소프트웨어 회사의 빵과 버터 문제는 적당한 소프트웨어 수단으로 해결할 수 있습니다. 유용하고 아마도 훌륭한 소프트웨어 엔지니어를 만드는 것은 부분적으로 훌륭한 일반 엔지니어를 만드는 것입니다. 책임감있게 작업을 정리하고 문서화하십시오. 협조적이다. 적절한 비용 및 시간 추정을하십시오 (추정의 유효성은 실제 비용 및 시간보다 중요합니다). 할 수있는 것과 할 수없는 것을 이해하십시오. 여기서 "최신 도구 및 절차를 알고 사용하십시오"라는 내용이 눈에 띄게 없습니다. 당신이 설명하는 것은 도구 세트와 그에 맞는 프로세스를 확립 한 회사입니다. 아마 섹시하거나 특별한 것을 생산하지 않을 것입니다. 그러나 충분한 수익을 꾸준히 창출하기에 충분한 고객 요구를 충족시킵니다. 그것은 공학의 정의 일 수 있습니다 ;-).

예 : 대학에서 배우는 것은 실제로 많은 분야에서 일반적이지 않습니다.

위로 나 더 낙관적 인 메모를 추가하고 싶습니다. 배운 것을 창 밖으로 버려서는 안됩니다. 일을 방해하지 않는 일상 업무에 더 나은 원칙을 적용 할 수 있습니다. 아마도 새로운 도구 나 디자인 패턴을 소개 할 기회가있을 것입니다. 이전의 일을하는 방식이 동료에게 불쾌한 경우 또는 복잡성이나 유지 관리 문제 (혁신으로 해결되는 가장 치명적인 두 가지 문제)가 발생하는 경우가 가장 좋습니다. 기회가있을 때 개선 할 준비를하십시오. 긍정적 인 영향을 미치고 방법과 도구를 점진적으로 개선하십시오. 인정되는 곳에 지식을 전파하십시오.

그들은 C # .Net Webforms를 사용하고 외부 클래스가 거의없이 Code Behind 내의 거의 모든 것을 수행합니다.

거기에 당신의 설명이 있습니다. 알지 못하는 경우 기본적으로 제공되는 Web Forms 코드는 OOP, SOLID, DRY, YAGNI, Design Patterns, SRP 등과 정반대입니다 . 몇 년 전의 Microsoft 공식 사례조차도 오늘 당신이 울부 짖을 것입니다.

Web Forms는 제어 클릭 등에 의해 발생하는 일부 가짜 "이벤트"와 함께 절차 적 흐름으로 나아가고 있습니다. Web Forms를 수행하는 데 많은 시간을 소비 한 개발자는 일반적으로 페이지 라이프 사이클을 배우는 데 너무 많은 시간이 걸리고 동적으로 렌더링 된 컨트롤을 수행하여 지식을 버릴 수있는 방법을 배우기 때문에 일반적으로 Web Forms를 떠나기를 꺼려합니다. 더 새로운 / 더 나은 방법에 직면 해 있습니다. 침몰 비용 오류의 무의식적 버전. 이 개발자들은 웹 양식을 작성하는 방법을 배우는 데 수년을 보냈으며 이제는 해당 전문 지식에서 쉽게 벗어날 수 없으므로 "유지 관리"시간에 대해 이야기합니다.

그리고 이것은 .NET Web Forms 공간에서 매우 일반적입니다.

소프트웨어 산업에서 이것이 얼마나 흔합니까?

아주 흔한. 배관공이 배관을 파괴하는 것과 같은 공통점, 쓰레기를 배달하는 목수 또는 나쁜 양복을 만드는 싼 재단사. 즉, 그것은 모두 인간입니다.

이런 일이 발생하는 데는 합당한 이유가 있습니다. 실제로 훈련을받지 않았거나 열성적이지 않은 사람들은 압력을 받고 무언가를 구현해야합니다.

이러한 사람들의 문제는 아니지만 주로 해당 회사의 소프트웨어 개발을 둘러싼 구조에 대한 문제입니다. 예를 들어, 회사에 내부 소프트웨어를 개발하는 많은 인턴이있을 수 있습니다. 그러한 인턴들이 밝고 지식이 풍부하더라도 몇 주 또는 몇 달 동안 만있을 것이며 소유권은 자주 바뀔 것입니다.

또는 도메인에서는 훌륭하지만 프로그래머는 아닌 사람이 처음에는 꽤 쉬운 것처럼 보이기 때문에 VBA 등의 응용 프로그램을 함께 해킹 할 수 있습니다.

또는 잘 만들어진 응용 프로그램은 유지 보수 단계에서 끝나고 모든 훌륭한 개발자는 계속 움직이며 그에 대해 거의 알지 못하고 문서가없는 사람 (예 : 최악의 경우)에 의해 계속 개발됩니다.

OOP 및 관련 원칙을 준수하도록하려면 어떻게해야합니까? 나는 여가 시간에 연습을하고 OOP를 더 잘 배우기 위해 더 숙련 된 개발자와 함께 일해야한다고 생각합니다.

두 가지 가능한 답변이 있습니다.

• 어느 쪽이든 : 상사와상의하여 깨끗한 프로젝트를 시작하십시오. 가능하지 않으면 새 보스를 찾으십시오.
• 또는 스스로 책임을 져야합니다. 즉, 여가 시간이나 회사에서 할 수 있지만 가능하면 직접 운전해야합니다.

두 번째 답변이 너무 냉소적으로 들린다면 그렇지 않다는 것을 확신시켜 드리겠습니다. 집에서 목공 상점이있는 목수는 것입니다 가장 확실히하지 않는 것보다 더 좋은 목수합니다.

예를 들어, 그것은 절대적으로 가능하고, 많은 사람들을위한 재미는, 예를 들어, 루비와 같은 새로운 언어로 파고 구문뿐만 아니라 그 언어를 심층적으로 다룬 특별 OO 측면뿐만 아니라 배우, 정말 깊은 다이빙. 작업에 연결하지 않고도 여가 시간에 모두 사용할 수 있습니다. 그것은 단지 취미 일 것이지만, 당신이 훈련받은 전문가라면, 일부 주요 개발자 옆에 앉아서 그들이하는 일을 따르려고 노력하는 것만큼이나 효과적 일 수 있습니다. 이것은 당신의 개인적인 발전과 당신의 재미를 위해 엄격하게 될 것입니다. 당신이 이것을하는 것이 재미 없거나, 당신이 단순히 이해를 할 수 없다는 것을 알게되면, 그것을 긁어서 첫 번째 답으로 돌아가십시오.

당신이 훈련하는지 리드 개발자했다 매우 가능성이 정확히 이런 식으로 그 물건을 배웠습니다 ...

스페인에서는 개발자가 회사에서 수년을 지났을 때 일반적으로 분석 및 프로젝트 관리와 같은 더 많은 관리 영역으로 승진하기 때문에 스페인에서는 일정하다고 생각합니다. 결과적으로 동료 검토가 수행되지 않으며 일반적으로 경험이 적은 사람들이 코드를 작성합니다.

이 숙련 된 사람들의 실패는 결코 시정되지 않습니다. 대신에 그들의 일에 집중하는 유일한 초점입니다. 결과적으로 코드에 점점 더 많은 잘못된 관행이 축적됩니다.

결국 일부 똑똑한 엉덩이는 가장 좋은 "솔루션"은보다 깨끗하고 유지 보수가 가능한 코드를 생성하여 새로운 애플리케이션을 만드는 새로운 기술로 변경하는 것이라고 말합니다. 마치 기술 자체만으로도 가능합니다.

다시 한 번, 경험이없는 프로그래머는이 새로운 기술을 사용하게됩니다. 아무도 코드를 검토하지 않으며 서클은 다시 닫힙니다.

학교에서 배우는 "모범 사례"중 일부는 실제 프로젝트에서 실용적이지 않거나 비용 효과적이지 않습니다. 내가 주목 한 가장 큰 변화 중 하나는 형식과 주석이었습니다. 대부분의 교수님은 코드를 광범위하게 문서화하는 것이 중요하다는 사실을 강조했지만 실제로는 좋은 코드가 자명 한 경우가 많습니다 (항상 그런 것은 아닙니다!). 코멘트.

때로는 품질 솔루션보다 보일러 플레이트가 덜 필요한 바로 가기 및 안티 패턴을 사용하여 시간을 압박하는 프로그래머를 보게 될 것입니다.

그러나 많은 팀과 프로젝트에서 발견 한 가장 큰 문제 중 하나는 새로운 것을 배우려는 의지가 없다는 것입니다. 내가 이야기했던 많은 오래된 프로그래머들은 자격이 시작되고 코드를 작성하려는 의지로 끝났을 때 '와일드 웨스트'소프트웨어 엔지니어링 시대에 경력을 쌓았다. 그들은 종종 완전히 다른 분야를 전공했고, 기회가 생겼을 때 공식 교육이 거의 없거나 전혀없는 프로그래밍에 뛰어 들었습니다 (예 : 고용주에게는 프로그래머가 없었으며 사내 소프트웨어를 구축하기 위해 배우는 사람이 필요했습니다). 이 구식 독학 프로그래머 중 일부는 현대의 코딩 실습을 배우려고 노력하지 않으며 수십 년 전에 배운 거의 모든 스타일로 코딩을 계속합니다. 선임으로 인해 새 프로젝트를 담당하게되면 프로젝트를 보류하고 전체 코드 품질을 해치는 경향이 있습니다.

물론 위의 내용이 모든 구형 프로그래머에게 적용되는 것은 아니며 최신 코더도 유죄 일 수 있습니다. 나는 많은 젊은 프로그래머들과 함께 대학에서 새로 나온 몇 가지 도구와 라이브러리를 집어 들고 완전히 배우기를 중단했습니다. IDE 또는 라이브러리를 한 번 다운로드 한 후 회사에서 요구하지 않는 한 업데이트하지 않습니다 (프로그래머가 라이브러리가 얼마나 오래된 지에 따라 몇 년을 졸업했는지 추측 할 수 있습니다). 그들은 선택한 언어로 새로운 기능을 유지하지 않으며 새로운 언어를 배우지 않습니다. 그들은 새로운 프로그래밍 전략을 배우지 않으며, 더 적절한 대안을 모르기 때문에 패턴이나 패러다임을 오용 할 수 있습니다 (오 MVC, 얼마나 많은 학대를 받았는지). 시간이 지남에 따라 워크 플로는 점점 구식이되어 자산보다 더 많은 책임을지게됩니다.

요약하자면, 지저분한 코드베이스의 가장 큰 원인 중 두 가지는 마감일과 프로그래머가 구식이거나 불완전한 지식을 가지고 있기 때문입니다. 불행히도 두 문제에 대한 책임은 상사 나 CTO에 크게 영향을 줄 수 있으며, 마감일이 현실적이고 직원이 자신의 지식과 기술을 최신 상태로 유지하도록해야합니다. 상사가 좋은 프로그래밍 관행에 대해 아무것도 모르는 경우 변경 사항을 제안하고 변경 사항이 제안에 개방되기를 바랍니다. 불행히도 OOP를 이해하지 못하고 10,000 개의 라인 클래스를 작성하는 것을 선호하는 상급 프로그래머의 말을 신뢰하는 경향이 있습니다.

나쁜 프로그래밍 관행 중 일부는 수십 년 전에 처음 개발을 시작한 레거시 소프트웨어로 작업해야했기 때문에 발생합니다. 거대한 복잡한 소프트웨어가 있다면 모든 것을 다시 작성하는 것이 옵션이 아닐 수도 있습니다. 코드가 실제로 수행하는 모든 것을 이해하는 것은 매우 어려울 수도 있습니다. 가장 좋은 방법은 작동하는 것을 복사하면서 더 나은 프로그래밍 방법을 통합하려고 시도하는 것입니다.

나는 단지 틀린 말을하는 것이 아니라 모든 옳고 그른 이유 를 아는 것이 중요하다고 생각합니다 . 이유를 알면 결과를 예측할 수 있습니다. 왜이 원리 나 원리를 책에 묘사 한 것이 아니라, 그것이 어떻게 도움이되는지, 그것을 깨뜨려야 정확히 어떻게되는지 알고 있기 때문 입니다. 언제 어떤 일이 발생하는지 알고 있다면 장단점을 측정하고 결정을 내릴 수 있습니다. 이것은 또한 매번 당신의 입장을 주장하는 데 도움이 될 것입니다. SOLID 및 OOP는 잘 사용하면 유지 관리를 줄일 수 있습니다.

SOLID를 너무 독단적으로 사용하면 너무 많은 클래스와 메소드가 생겨서 그다지 좋지는 않습니다. 과용하지 마십시오. 이것은 교과서와 튜토리얼에서 종종 정당화없이 아이디어를 홍보하려고 시도 할 때 큰 문제입니다. OOP에도 단점이 있습니다. 많은 원칙과 패러다임이 서로 모순됩니다. 당신은 정상에있을 필요가 없습니다, 당신은 모든 것을 합리적, 정당화, 우아하고 단순하게 만들어야합니다.

또한 이것이 첫 번째 작업이므로 프로그래머가 숙련되지 않을 가능성이 있습니다. 그러나 다시 말하지만, 그들은 숙련되지 않은 저렴한 코더들에 의해 많은 기술없이 그리고 낮은 급여를 위해 수행 될 수있는 매우 어려운 일들을 신뢰하고있을 것입니다. 이것은 경제학이 작동하는 방식입니다. 직장마다 다릅니다.

나는 당신이 어떻게 느끼는지 이해합니다. 당황하지 마십시오 . 당신은 당신이 아는 것을 필요할 것입니다. 아마 즉시는 아니지만 그것은 당신을 도울 것입니다. 다른 직장이나 어쩌면 어떤 경우에는 앞으로 나아갈 시간이 있습니다.