소프트웨어 개발에 적용된 전쟁 기술

소프트웨어 산업에서 일하는 경우 기본적으로 문제를 두 개 이상의 하위 문제( divide )로 재귀적으로 분할하여 직접 해결할 수 있을 정도로 단순해질 때까지 구성하는 분할 정복 설계 패러다임에 대해 들어보았을 것입니다. ( 정복 ) .

당신이 모를 수도 있는 것은 이 패러다임이 오래된 정치 전략(이름은 라틴어의 Divide et Impera 에서 파생됨)에서 비롯되었다는 것입니다. 이 전략은 부하 직원이나 신하 사이에 반대 의견을 조장하여 통제력을 유지할 수 있음을 시사합니다.

이 전략은 Julius Caesar(갈리아 전쟁 동안 군사적으로 강한 갈리아인을 물리치기 위해 사용)와 Napoleon(프랑스 포병 전문가가 적군을 분할하여 더 강한 부분이 없도록 적군을 분할하는 데 사용)과 같은 역사를 통해 수많은 정치인과 군사 지도자에 의해 사용되었습니다. 자신의 군대보다 통신을 방해하여 공격을 조정하고 실행하려는 적의 노력을 방해합니다.

전쟁의 기술: 개발에 적용된 고대 원칙

그러나 소프트웨어 개발에 적용할 수 있는 정치적 전략은 분할 정복 의 법칙만이 아니다. 정치와 전쟁은 소프트웨어 개발과 거의 관련이 없지만 정치인 및 장군과 마찬가지로 개발자는 부하를 이끌고 팀 간의 노력을 조정하고 문제를 해결하기 위한 최상의 전략을 찾고 리소스를 관리해야 합니다.

Art of War 는 기원전 5세기에 쓰여진 고대 군사 논문으로 고대 중국의 군사 전략가인 손자(Sun Tzu)가 쓴 이론으로 동양 철학과 서양 철학 모두에 지대한 영향을 미쳤습니다.

오랜 세월이 흘렀음에도 불구하고 이 텍스트는 여전히 동아시아의 많은 사관학교 강의 계획서에 포함되어 있으며 서구의 일부 사관학교에서는 권장 읽을거리로 등재되어 있습니다. 이 텍스트는 13개의 챕터로 나뉘며 각 챕터는 전쟁의 다른 측면을 다루고 있습니다.

그러나 전쟁 외에도 Sun Tzu의 원칙과 가르침은 정치, 비즈니스, 스포츠, 그리고 믿거나 말거나 소프트웨어 개발에 실제 적용됩니다. 사실, 당신은 그 기원조차 모른 채 이러한 원칙 중 일부를 일상 생활에 적용할 수 있습니다.

아래에서 Art of War에서 설명하는 기본 전술과 팁에 대한 간략한 목록을 찾을 수 있습니다. 소프트웨어 산업 또는 기타 여러 산업 분야에 적용할 수 있습니다.

시간은 모든 캠페인에서 중요합니다.

2장 2절

실제 전투에 임할 때 승리가 오래 걸리면 사람의 무기가 둔해지고 의욕이 꺾입니다.

이 원칙은 일반적으로 개발 주기의 길이와 개발자의 사기 사이의 관계를 설명하는 소프트웨어 개발에 적용될 수 있습니다.

개발자 그룹이 명확한 목표나 끝이 보이지 않고 같은 프로젝트에서 몇 달 동안 작업하면 좌절감을 느끼고 생산성이 떨어질 수 있습니다.

소프트웨어 개발은 ​​지적 노력이므로 동기 부여가 생산성의 주요 연료입니다. 당신의 일이 실제 결과를 낳고 있다는 것을 인식하지 못한 채 매일 일하는 것은 매우 의욕을 잃을 수 있습니다.

일부 애자일 방법론에서 알 수 있듯이 개발 로드맵은 팀이 짧은 시간 내에 달성할 수 있는 몇 가지 목표와 이정표로 나누어야 하며 진행 상황과 성취감을 줄 것입니다.

2장 18절

그러므로 전쟁에서 당신의 위대한 목표가 승리하게 하십시오.

이 문구는 두 가지 방식으로 해석될 수 있습니다.

첫째, 유닉스 철학의 선구자로 볼 수 있습니다. 한 가지만 잘하는 프로그램을 작성하십시오 . 소프트웨어를 개발할 때 항상 프로그램의 주요 목적, 프로그램이 제공하는 주요 기능 또는 프로그램이 해결하는 가장 큰 문제를 염두에 두고 적절한 구현을 보장해야 합니다.

때때로 영감을 받아 추가할 정말 멋진 기능이 생각날 수 있지만 자주 사용하지 않는 기능이 많이 포함된 응용 프로그램에는 욕설을 부르는 이름이 있다는 것을 잊지 마십시오. bloatware .

둘째, 이 진술은 린 소프트웨어 개발 원칙 중 하나의 선구자로 간주될 수도 있습니다. 가능한 한 빨리 전달하십시오 .

큰 결함이 없는 소프트웨어를 더 빨리 제공할수록 클라이언트로부터 더 빨리 피드백을 받고 다음 반복에 변경 사항을 통합할 수 있습니다.

반면에 작동하지 않는 소프트웨어를 제공하면 클라이언트가 제대로 테스트할 기회를 얻지 못하기 때문에 귀중한 피드백을 놓칠 수 있습니다. 이것은 다음 반복이 고객 피드백에 의존하는 상황에서 다음 개발 단계를 더 어렵게 만들거나 불가능하게 만듭니다.

리더십도 없고 결과도 없다

3장 11절

이제 장군은 국가의 보루입니다. 방벽이 모든 지점에서 완성되면 국가는 강해질 것입니다. 방벽에 결함이 있으면 국가가 약할 것입니다.

이 인용문은 개발 팀에서 관리자 역할의 중요성을 설명합니다. 프로젝트의 성공은 관련된 모든 사람들 의 힘에 달려 있으며 관리자는 프로젝트의 보루입니다. 책임은 위에서부터 시작됩니다.

개발자들이 종종 혼자 작업하지만(각각 컴퓨터 뒤에 앉아 동료와 제한된 의사소통을 함), 그렇다고 해서 좋은 리더십이 필요하지 않다는 의미는 아닙니다. 프로젝트 관리자는 팀을 계속 순조롭게 유지하고 효과적인 의사 소통 및 분쟁 해결을 보장하며 리더는 분명히 프로젝트의 우선 순위(다른 작업 중에서)를 정의하므로 그들의 역할이 과소평가되어서는 안 됩니다. 일이 잘못되면 그들의 책임도 지지 않습니다. 부대가 전장에서 임무를 수행하지 못한 군대 지도자에게 어떤 일이 일어날지 상상해 보십시오.

팀은 개발 위치에 나쁜 사과가 몇 개 있더라도 훌륭한 소프트웨어를 생산할 수 있지만 프로젝트 관리자가 나쁜 사과 라면 팀에 얼마나 많은 락스타 개발자가 있더라도 그런 일은 일어나지 않을 것입니다.

제6장 28절

당신에게 한 번의 승리를 안겨준 전술을 반복하지 말고, 당신의 방법이 무한한 다양한 상황에 의해 규제되도록 하십시오.

때로는 프로젝트를 시작할 때 이전에 성공한 프로젝트에서 사용한 것과 동일한 기술 집합(동일한 프로그래밍 언어, 동일한 라이브러리, 동일한 서버 등)을 사용하고 싶을 때가 있습니다. 그러나 새 프로젝트의 요구 사항이 이전 프로젝트의 요구 사항과 완전히 동일 하지 않은 경우 이는 잘못된 접근 방식일 수 있습니다.

프로그래밍에서는 대부분의 영역에서와 마찬가지로 만병 통치약(모든 질병을 치료할 수 있는 것으로 추정되는 치료법)이 존재하지 않습니다. 모든 문제를 해결하는 데 사용할 수 있는 단일 기술 조합은 없습니다. 각 기술에는 장단점이 있습니다.

물론 새로운 프로그래밍 언어를 배우거나 알려지지 않은 API를 사용하는 것은 처음에는 비용이 많이 들 수 있지만 장기적으로는 소프트웨어의 품질이 더 우수하고 더 나은 개발자가 될 것입니다.

13장 27절

그러므로 군대의 최고 지능을 간첩에 사용하는 것은 깨달은 군주와 현명한 장군만이 할 수 있고, 그리하여 그들은 큰 성과를 얻을 수 있다. 스파이는 군대의 이동 능력에 달려 있기 때문에 전쟁에서 가장 중요한 요소입니다.

이 문구는 유지 관리 단계에서 모니터링 도구 및 로깅 라이브러리 사용의 중요성으로 해석될 수 있습니다.

클라이언트가 그렇게 생각하지 않을 수도 있지만 안정적이고 완전히 테스트된 릴리스를 얻을 때 개발이 끝나지 않습니다. 소프트웨어는 버그를 수정하거나, 새로운 기능을 추가하거나, 효율성을 개선함으로써 항상 진화하고 있습니다.

그리고 스파이가 프로덕션 환경에서 소프트웨어를 모니터링하여 가장 많이 사용되는 기능, 가장 일반적인 오류 및 가장 긴 작업을 확인하는 것보다 변경 사항을 파악하는 데 더 좋은 정보 소스는 없습니다.

오류 보고서, 로깅 항목 및 사용 데이터는 제어된 테스트 환경에서 동일한 조건을 재현하는 것이 항상 가능한 것은 아니기 때문에 버그를 감지하고 병목 현상 및 기타 문제를 식별하는 데 필수적입니다.

팀워크와 동기 부여

10장 24절

명성을 구하지 않고 전진하는 자, 비난을 피하지 않고 후퇴하는 자, 백성을 보호하고 군주를 섬기는 것이 한 가지 목적인 자, 그 남자는 왕국의 보석이다.

기본적으로 이것은 고대 중국어 버전인 "나는 팀에 없다" 입니다. 개인의 이익을 추구하기보다 다른 사람들과 함께 일하는 것이 더 중요합니다.

소프트웨어 개발은 ​​개발자가 팀으로 효과적으로 작업해야 하는 복잡한 활동입니다. 좋은 개발자는 가장 많은 버그를 수정하거나, 가장 많은 기능을 구현하거나, 일정보다 빨리 할당을 완료하는 사람이 아닙니다. 좋은 개발자는 팀이 목표를 달성하도록 돕는 사람입니다.

자신이 한 모든 일에 대해 공로를 주장하고, 자신의 오류를 인식하지 않거나 다른 사람을 비난하거나, 자신을 코드 닌자 라고 부르는 것은 경험이 부족한 관리자를 속일 수 있고 급여 인상을 받을 수도 있지만 팀의 비생산적인 구성원이 될 것입니다.

7장 21절

움직이기 전에 숙고하고 숙고하십시오.

이 문구는 애자일 방법론에서 제안하는 것과 같은 팀 개발 회의의 중요성을 나타냅니다.

팀에서 작업할 때 주요 변경 사항을 구현하기 전에 논의하는 것이 중요합니다. 당신이 팀 리더이든, 그 주제에 대해 가장 많은 경험을 가진 사람이든 상관없이 항상 나머지 팀과 이야기하거나 최소한 알려야 합니다.

다른 개발자가 소프트웨어에 익숙하지 않은 부분에 대한 통찰력을 제공할 수 있음을 기억하십시오. 즉, 해당 변경의 영향을 완전히 인식할 수 있기 때문에 예상보다 빠르게 변경 구현을 시작할 수 있습니다.

10장 25절

당신의 병사들을 당신의 자녀로 여기십시오. 그러면 그들은 당신을 따라 가장 깊은 계곡으로 들어갈 것입니다. 그들을 여러분 자신의 사랑하는 아들로 여기십시오. 그러면 그들은 죽기까지 여러분 곁에 서 있을 것입니다.

이 인용문은 때때로 관리자와 팀 리더가 잊어 버리는 경영 원칙 인 동기 부여의 중요성을 나타냅니다. 동기가 부여된 개발자는 더 나은 코드를 작성하고, 더 빠르게 작업하고, 더 적은 오류를 저지르고, 더 많은 시간을 기꺼이 투자할 것입니다.

동기 부여는 부하 직원에게 진정한 관심을 갖고, 그들의 말을 경청하고, 일과 삶의 균형에 관심을 갖고, 긍정적인 작업 환경을 구축하고, 그들의 경력 경로에 관심을 둠으로써 관리자가 생성해야 합니다.

또한 동기 부여를 보수로 착각해서는 안 됩니다. 최근 연구에 따르면 돈은 대부분의 근로자에게 동기를 부여하지 않으며, 돈은 대부분 직원을 유치하고 유지하는 데는 좋지만 직업에 대해 만족하지 않는 것으로 나타났습니다. 따라서 인상과 승진은 동기 부여 도구로 간주되어서는 안됩니다.

틀을 깨고 생각하라

제5장, 7, 8, 9항

5개 이하의 음표가 있지만 이 5개 음의 조합은 지금까지 들을 수 있는 것보다 더 많은 멜로디를 생성합니다.

5가지 이상의 기본 색상이 없지만 조합하여 볼 수 있는 것보다 더 많은 색조를 생성합니다.

기본 맛은 5가지가 넘지 않지만 이들의 조합은 이제까지 맛볼 수 있는 것보다 더 많은 맛을 냅니다.

프로그래밍의 좋은 점 중 하나는 가능성이 무한하다는 것입니다. 기본적으로 원하는 곳 어디에서나 개발할 수 있습니다(적어도 NP-완전한 문제가 아닌 한).

모바일 앱, 웹사이트, 게임, 데스크톱 애플리케이션… 프로그래밍을 알고 있다면 모두 손이 닿는 곳에 있습니다.

3장 1절

실제 전쟁 기술에서 가장 좋은 것은 적의 나라를 온전하고 온전하게 취하는 것입니다. 부수고 파괴하는 것은 좋지 않습니다. 따라서 역시 군대를 파괴하는 것보다 군대 전체를 점령하는 것이, 연대, 파견대 또는 중대를 파괴하는 것보다 점령하는 것이 좋습니다.

대규모 코드 기반이 있는 프로젝트에서 작업할 때 나쁜 습관으로 구현되었거나 더 이상 사용되지 않는 라이브러리를 사용하여 구현된 모듈 또는 코드 섹션을 찾는 것이 일반적입니다. 이 코드를 지우고(또는 파기) 하고 싶은 마음이 들 수도 있지만 다음과 같은 몇 가지 이유로 최선의 방법이 아닐 수 있습니다.

• 레거시 코드가 반드시 나쁜 것은 아니며 때로는 다른 방법론과 기술이 고려되었을 때 작성된 좋은 코드입니다. 그러나 오래되었다고 해서 작동하지 않는 것은 아닙니다.

• 코드의 더 중요한 다른 부분을 수정하는 데 집중하는 대신 여전히 작동하는 코드를 수정하는 데 시간을 낭비할 수 있습니다.

• 수행 중인 작업에 대해 확신이 없는 경우 작동하는 코드 섹션을 교체하면 새로운 오류나 버그가 발생할 위험이 있습니다.

이것은 "고장 나지 않으면 고치지 마십시오" 라는 문구가 좋은 전략이라는 것을 의미하는 것이 아니라 모든 프로젝트에 우선 순위, 목표 및 시간 제약이 있음을 의미합니다. 따라서 개선할 수 있는 코드를 찾으면 나머지 팀이나 프로젝트 관리자와 논의하여 언제 최적화해야 하는지 파악하십시오.

8장 3절

따라가면 안 되는 길, 공격해서는 안 되는 군대, 포위되어서는 안 되는 성읍, 다투면 안 되는 위치, 복종해서는 안 되는 군주의 명령이 있습니다.

직접적으로 말하지는 않더라도 이 원칙은 안티패턴을 피하기 위한 경고로 해석할 수 있습니다.

안티 패턴을 사용하면 단기적인 문제를 해결할 수 있지만 장기적으로는 역효과를 낳을 수 있다는 점을 기억해야 합니다. 따라서 얼마나 많은 시간을 절약하든, 얼마나 많은 버그를 수정하든, 얼마나 편리하게 사용하든, 피하십시오.

그래도 시간이 더 있을 때 적절한 수정을 구현하겠다고 스스로에게 약속하면서 긴급한 작업을 해결하기 위해 안티 패턴을 사용하고 싶은 유혹이 있을 수 있지만 머피의 법칙 중 하나를 기억하십시오. 모든 빠른 수정은 영구적인 변경이 됩니다.

결론

소프트웨어 개발은 ​​전쟁에서 군인을 지휘하거나 국가를 이끄는 것과는 다르지만 팀워크, 우수한 리더십, 효율성 및 장기적인 솔루션이 필요한 문제를 해결해야 합니다.

그러나 Art of War 만이 소프트웨어 개발에 적용될 수 있는 원칙을 담고 있는 유일한 책은 아닙니다. 니콜로 마키아벨리의 <왕자 >가 대표적이다.

사실, 다음은 여전히 ​​관련성이 있는 마키아벨리의 인용문 목록입니다. 소프트웨어 개발의 세계에서 해당 원칙이 무엇인지 추측해 보십시오.

1. 사자는 덫으로부터 자신을 보호할 수 없고 여우는 늑대로부터 자신을 보호할 수 없습니다. 그러므로 덫을 알아보려면 여우가 되어야 하고 늑대를 놀라게 하려면 사자가 되어야 합니다.
2. 속임수로 얻을 수 있는 것을 강제로 얻으려고 하지 마십시오.
3. 위험 없이 위대한 것은 결코 성취되지 않았습니다.
4. 지속적인 성공을 원하는 사람은 시대에 따라 행동을 바꿔야 합니다.
5. 일반적으로 남자는 현실보다 외모로 판단합니다. 모든 사람은 눈을 가지고 있지만 침투의 재능을 가진 사람은 거의 없습니다.
6. 순종하고자 하는 사람은 명령할 줄을 알아야 합니다.
7. 지혜는 문제의 본질을 구별하는 방법을 아는 것과 덜 악한 것을 선택하는 것으로 구성됩니다.
8. 전쟁을 피하는 것은 없습니다. 적에게 유리하도록 연기할 수 있습니다.
9. 자연은 용감한 사람을 거의 만들지 않습니다. 산업과 훈련은 많은 것을 만듭니다.