"소프트웨어 엔지니어링"이 아닌 "소프트웨어 기술"이라고 할 수있는 특정 사례는 무엇입니까? [닫은]

새로운 아이디어는 아니지만 지난 몇 년 동안 소프트웨어 기술에 대한 관심이 크게 증가한 것으로 보입니다 (특히 Clean Code의 전체 제목은 Clean Code : Handbook of Agile Software Craftsmanship ).

개인적으로 저는 소프트웨어 장인 정신이 최종 소프트웨어가 최종 사용자와 함께 일하는 즐거움 (최종 사용자와 소프트웨어를 관리하는 사람)의 즐거움을 보장하는 데 관심이있는 우수한 소프트웨어 엔지니어링으로보고 있습니다. 높은 수준의 프로세스보다

유추하기 위해-50 대와 60 대에는 매우 현대적인 스타일로 건축 된 건물이 많았으며, 그 건물에 사는 사람들이나 그 건물이 시간이 지남에 따라 노화되는 방식을 거의 고려하지 않았습니다. 이 건물들 중 다수는 빈민가로 빠르게 발전하거나 예상 수명이 끝나기 오래 전에 철거되었습니다. 몇 년 동안 벨트를 사용하는 대부분의 개발자는 비슷한 코드베이스를 경험했을 것입니다.

소프트웨어 장인이 소프트웨어 엔지니어 (아마도 나쁜 사람)가하지 않을 수있는 구체적인 일은 무엇입니까?

나는 전문가와 장인의 유일한 차이점은에 약간의 열정을 섞어 돌보는 것이라고 말합니다 . 하나를 장인으로 분류하는 구체적이고 관찰 가능한 관행이 아니라 오히려 자질의 집합입니다.

• 장인은 지각 된 품질뿐만 아니라 그의 작품의 실제 품질에 관심을 갖습니다.
• 장인은 직무를 수행하는 것 이상의 기술에 관심이 있으며 자연스럽게 자신의 기술에 중점을 둡니다.
• 장인은 자신의 직업에 관심을 갖고, 자신의 기술 을 향상시키고 경력을 발전시킬뿐 아니라 갈망합니다 .
• 장인은 유급 근무 시간 외에 (소량의 시간이더라도) 자신의 공예품으로 무언가를하고 토론, 학습 또는 생각하기까지 시간을 보냅니다.
• 장인은 그가 실제로 아는 바가 거의 없다는 것을 알고 그에 의해 겸손 해집니다.
• 장인은 기꺼이 배우고 자하는 사람들을 가르치고,지도를 구하는 사람들을지도하며, 필요할 때 스스로 찾게됩니다.

약간의 열정은 땀을 흘리지 않고 이러한 모든 것을 다룹니다.

개인적으로 저는 소프트웨어 장인 정신이 최종 소프트웨어가 최종 사용자와 함께 일하는 즐거움 (최종 사용자와 소프트웨어를 관리하는 사람)의 즐거움을 보장하는 데 관심이있는 우수한 소프트웨어 엔지니어링으로보고 있습니다. 높은 수준의 프로세스보다

내 교수는 한 번 말했다.

소프트웨어 장인이 소프트웨어 엔지니어 (아마도 나쁜 사람)가하지 않을 수있는 구체적인 일은 무엇입니까?

아무것도 아닙니다-엔지니어는 장인입니다 ...하지만 더 있습니다. 공학은 장인 정신을 바탕으로합니다.

장인과 엔지니어로서 교육과 경험의 조합을 통해 숙련 된 개인입니다. 정해진 절차를 따릅니다. 당신은 또한 실용적이며 무엇이 깨졌으며 더 나은 것이 필요하다는 것을 깨닫습니다.

그러나 엔지니어는 경제, 이론 및 과학에 대한 우려를 추가합니다. 최저 비용으로 최대의 이익을 얻는 데 관심이 있습니다. 심리학, 사회학, 관리, 인간-컴퓨터 상호 작용 및 컴퓨터 과학의 이론을 적용하여 문제 (대인 및 기술적)를 해결하려고합니다. 그리고 당신은 확실히 당신의 경험을 백업하기 위해 교육을했습니다.

소프트웨어 직종 운동은 오늘날 일부 개발자의 부주의와 함께 실패한 "전통적인"소프트웨어 엔지니어링의 결과에 대한 불만과 만족스럽지 못한 결과로 이해 관계자 및 사용자로부터 우리의 직업에 대한 불신을 초래합니다.

목표는 프로그래머에 대한 신뢰 회복과 그렇게하기 위해 소프트웨어 품질 및 개발자 기술의 기준을 높이는 것입니다.

SW 장인 정신은 다음과 같은 기술 관행을 장려합니다.

• SOLID 설계 원리
• 디자인 패턴
• TDD ( "이중 엔트리 회계"은유)
• ...

그리고 팀 / 조직 관행 :

• 페어 프로그래밍
• 멘토링
• 코드 카타
• Dojos / 코드 후퇴
• ...

소프트웨어 장인 정신은 소프트웨어 엔지니어링이 40 년 이상 존재했던 문제의 상당 부분을 해결하려고 노력하고 있습니다.

http://manifesto.softwarecraftsmanship.org/로 가면 다음을 얻을 것입니다.

장인은 "엔지니어"에 대한 전통적인 인식과 다릅니다.

• 그들은 요구 사항을 충족시키는 것이 아니라 가치에 중점을 둡니다.
• 그들은 요구 사항을 충족시키는 것이 아니라 코드 스타일에서도 품질에 중점을 둡니다.
• 직장뿐만 아니라 광범위한 소프트웨어 개발 커뮤니티에도 참여합니다.
• 그들은 오늘날의 최첨단 기술이 내일의 쓰레기라는 것을 이해하지 못하고, 한 수준에서 다른 수준으로 가져 오는 데 적극적입니다.
• 그것은 그들이 누구, 단지 일이 아니다 있습니다 .

Bob 아저씨는 프로그래밍이 아직 정부에서 인정하는 안정적인 법률이나 규칙을 가지고 있지 않은 아주 어린 학문이라고 암시했습니다 (또는 Frederick Brooks입니까?). 나는 여기에 구두 인용을하지 않습니다.

과실로 인해 프로그램 허가를 철회 할 수 없습니다. 프로그래밍에는 "직업"을 준수하는 법률로 법적으로 시행되는 것보다 법과 규칙이 부족합니다. 의사는 무능함으로 인해 환자를 죽이고 의사의 직책 또는 허가를받을 위험이 있습니다.

프로그래머는 버그가있는 프로그램을 만들거나 무능함으로 인해 프로젝트가 실패하고 프로그래밍을 계속할 수 있습니다.

나는 그것이 프로그래밍을 공예로 만드는 것의 대부분이라고 생각합니다. 항아리 제작자는 두 개의 동일한 냄비를 만들지 않습니다. 결함이있는 냄비를 리콜해야하는 점토 냄비 제조업체에 대해 들어 본 적이 없습니다. 프로그래밍은 여전히 ​​매우 수동적이고 개인적인 작업입니다. 때로는 코드 스타일로 판단하는 코드를 작성한 사람을 알 수도 있습니다.

패턴 리팩토링.

즉, 소프트웨어 요구 사항의 90 %를 충족시키는 것을 구축 한 다음 전체 프로젝트를 깨끗하고 우아한 디자인으로 리팩토링하십시오.

일반적으로 소프트웨어 엔지니어링은 요구 사항의 90 %를 충족한다는 것은 소프트웨어가 고객에게 충분한 비즈니스 가치를 가져서 중요한 방식으로 수정해서는 안된다는 것을 의미하기 때문에 우선 순위가 높은 버그 수정은 제외합니다.

소프트웨어 엔지니어링은 이 시점에서 소프트웨어 를 안정화 하도록 권장합니다 .

또한 프로젝트가 처음부터 우아한 디자인으로 시작하지 않으면 소프트웨어 엔지니어링에 따르면 프로젝트의 결과에 관계없이 제대로 실행 되지 않은 프로젝트 로 간주됩니다 .

스파이크 솔루션.

일반적인 소프트웨어 엔지니어링 방법론에 따르면 스파이크 솔루션에서 영감을 얻은 디자인은 일반적으로 허용되지 않습니다.

어떤 이유로 든 더 이상 사용되지 않습니다 .

소프트웨어 엔지니어링에서 모든 종류의 지원 중단은 소프트웨어 시스템의 수명주기가 끝날 때만 가능합니다. 이것은 SDLC의 일부로 계획되어야합니다.

실제로, 몇 년 동안 소프트웨어 인터페이스의 특정 부분의 단점이 생산 과정에서 발견되고 해당 소프트웨어의 나머지 부분을 무효화하지 않고 수명주기 중간에 특정 부분이 더 이상 사용되지 않을 수 있습니다. 소프트웨어 엔지니어링에 따르면, 지원 중단 후 전체 소프트웨어 시스템의 재 인증이 필요했을 것입니다.

결국, 소프트웨어 장인 정신은 개인의 훌륭한 판단을위한 개인적인 노력 인 반면, 소프트웨어 공학은 보수적 인 지식 체계입니다. 프로젝트의 의사 결정에 대한 올바른 판단을 허용하는 것은 소프트웨어 기술과 소프트웨어 엔지니어링을 분리하는 것입니다.

코드의 100 %를 다루는 단위 테스트를 사용하는 것이 좋습니다. 그것은 여분의 물건을 제거 할 수 있습니다.

때로는 소프트웨어 개발을 조각과 비교합니다. 추가 한 것이 아니라 빼앗아 간 것입니다.

분명히 당신은 너무 멀리 걸릴 수 있습니다. 작고 반짝이는 조약돌이 좋은 조각품이라고 말하는 사람은 아무도 없습니다.