소프트웨어 게시자 사이에 이상한 현상이 나타났습니다. 사람들은 무엇이 고품질 제품을 더 좋게 만드는지에 대한 자신의 이해를 뒤집는 경향이 있는 것으로 보입니다. 적어도 마케팅을 수행하는 사람들에게는 이것이 사실입니다.
"그들의 제품에는 백만 줄의 코드가 있지만 우리 제품에는 200만 줄이 있으므로 우리 제품은 더 좋아야 합니다."
"많을수록 좋다"는 사고방식이 어디서 유래했는지는 아무도 모릅니다. 당시에는 모두가 "적을수록 좋다"는 철학을 만들기 위해 열심히 노력하고 있었습니다.
아마도 그것은 소비자 수준의 저널리즘에서 시작된 것 같습니다. 많은 작가들이 큰 숫자를 인용하여 청중에게 깊은 인상을 주려고 하기 때문입니다. 대부분의 경우 이것이 작동합니다. 이 작은 플래시 드라이브는 200테라바이트의 데이터를 저장하고 CPU는 초당 48억 개의 명령을 처리할 수 있으며, 작성자는 소스 코드에도 동일한 내용이 적용되지 않는다는 것을 이해할 만큼 기술적으로 항상 능숙하지는 않습니다.
그러나 코딩 효율성은 엄격한 알고리즘을 만드는 것만이 아닙니다. 또한 폐기물을 줄일 수 있다는 것입니다. 즉, 문제 해결에 소요되는 시간, 컴퓨터 리소스를 너무 많이 소비하는 낭비, 심지어 주가 끝날 때까지 팀원들이 사무실에 쌓아 놓은 피자 상자 수를 낭비하는 것을 의미합니다. 이상적으로는이 모든 것을 줄이려고합니다.
8가지 간단한 단계로 코딩 효율성을 향상시키는 방법
이 기사에서 살펴볼 것은 효율성을 높이고 생산성을 높이기 위해 할 수있는 일입니다.
1. 유익한 작업 환경 구축
모든 코더는 고유 한 환경에서 작업하고 있으며 독자는 매우 다양하므로 일부 사용자는 다른 사용자보다 이러한 제안을 쉽게 구현할 수 있습니다.
프리랜서 인 경우 축하합니다. 이미 자신의 업무 환경을 마스터했기 때문입니다. 물론 그것은 고객을 방문하고 현장에서 일해야 할 때 바뀔 것이지만, 성공할 수 있다면 여전히 좋은 위치입니다.
개발 팀의 관리자 인 경우 이러한 제안을 통해 팀의 효율성을 극대화 할 수 있습니다. 또는 개발 팀의 직원 인 경우 이러한 아이디어 중 일부를 관리자에게 제안하거나 최소한이 페이지에 대한 링크를 보내 최고의 결과를 기대할 수 있습니다.
팀원이 재택 근무하도록 허용
프로그래밍은 부분적으로는 논리 연습이지만 훨씬 더 창의적인 도전입니다. 최고의 프로그래머는 모든 작업에 두뇌의 양쪽을 동일하게 사용할 수 있습니다.
과학은 창의적인 사람들이 밤에 최선을 다한다는 사실을 오랫동안 인정해 왔으며 이는 우리 모두가 경험해 본 일입니다. 그렇다면 대부분의 관리자가 전통적인 9시부터 5시까지 근무하는 루틴을 고집하는 이유는 무엇입니까?
사실, 우리는 이미 그에 대한 답을 알고 있습니다. 그것은 부분적으로 통제에 관한 것이고 부분적으로는 비즈니스 관점 (또는 최소한 관리 측면에서)을보다 편리하게 만드는 것에 관한 것입니다. 그러나 일상과 위치에 대한 주장은 팀의 효율성과 생산성을 떨어 뜨리고 있습니다.
당신이 깨달아야 할 것은 당신의 코더들이 최신 게임을 시험하기 위해 밤새도록 깨어 있었을 수도 있고, 파티에 갔거나, 단순히 가족과 어울려야 했을 수도 있다는 것입니다.
이는 그들이 월요일 아침에 출근할 때 최고의 생산성 수준을 달성하지 못할 뿐만 아니라 이미 에너지가 고갈되고 지쳐 있다는 것을 의미합니다.
근로자에게 근무 시간과 이상적인 장소를 선택하는 것은 생산성과 사기를 향상시키는 훌륭한 방법입니다. 그들이 일을 끝내고 우수한 품질의 결과를 얻는 한, 그들이 언제, 어디서, 어떻게 달성하는지는 신경 쓰지 않아야합니다.
긴밀한 협력이 필요한 경우는 예외이지만 실제로 대부분의 코더는 자신만의 방식으로 작업을 수행하도록 남겨둘 때 더 잘 수행하며 긴밀한 협력이 필요한 경우는 드뭅니다.
사무실에 들어갈 수 있는 옵션은 여전히 존재해야 하지만 일급 비밀 군사 프로젝트에 참여하지 않는 한 사무실에 들어갈 수 있는 현실적인 이유는 없습니다.
프리랜서로서 여기서 중요한 점은 밤에 실제 코딩 작업의 대부분을 수행하면 더 많은 작업을 수행 할 수 있다는 것입니다. 밤 늦게 산만하지 않고 조용하며 더 창의적입니다.
음악을 피하십시오
우리는 모두 초초 지저분한 überhacker가 헤드폰과 잼을 죽음의 금속에 걸고 숨을 쉬지 않고도 화면의 코드를 쉽게 넘겨주는 미친 영화 고정 관념을 보았습니다. 그리고 실제로 현실 세계에서 코딩하는 우리 모두는 그 이미지가 얼마나 우스운 지 알고 있습니다.
하지만 일하면서 음악을 듣는다면 조심하세요. 자신의 일 대신 음악에 대해 생각하기가 매우 쉽고, 어떤 종류의 음악은 수면 효과를 가질 수 있습니다.
체육관에서 운동하러 갈 때 적절한 종류의 음악을 들으면 더 많은 횟수를 반복할 수 있도록 영감을 줄 수 있습니다. 그러나 세미콜론이 누락된 행을 찾도록 영감을 주거나 for 루프 또는 while 루프 사용 중에서 올바른 선택을 하도록 영감을 주는 음악을 만든 사람은 아무도 없습니다. 우리가 이에 가장 근접한 것은 Electric Dreams입니다.
깔끔하게 유지하십시오
클러 터는 이상하게 위로 할 수 있지만 속도가 느려질 수도 있습니다. 엉망으로 잃어버린 물건을 찾기 위해 20 분을 쉽게 잃을 수 있으며, 왜 처음에 그것을 원했는지 잊어 버릴 수 있습니다.
그렇다면 그것이 초래하는 모든 불편에도 불구하고 우리 중 적어도 일부는 어수선함에 중독된 이유는 무엇일까요? 조직 전문가이자 작가인 Julie Morgenstern은 이러한 것들이 우리를 과거와 연결하고 우리의 정체성을 정의하는 역할을 하기 때문이라고 주장합니다.
뉴욕시에서 활동하는 교사이자 무대 연출가인 마커스 게둘드는 "멸균된" 환경보다 지저분함이 더 바람직하기 때문에 그렇다고 주장하며, 지저분함의 혼돈을 자유와 창의성에 대한 확신에 비유합니다.
그러나 어수선함을 줄이는 것이 산만함과 혼란을 피하는 데 도움이 된다는 것은 의심의 여지가 없습니다. 따라서 달성할 가치가 있는 목표입니다.
물론, 기분을 좋게 하고 스트레스를 덜 받게 해주는 몇 가지 신성한 물건을 주변에 두세요. 하지만 과하지 마세요. 정리는 대부분의 사람들에게 가장 어려운 일 중 하나이며, 정리해야 할 것은 물리적 데스크탑뿐만 아니라 종종 컴퓨터 데스크탑도 있습니다.
이 문제로 정말 어려움을 겪고 있다면 Fluxbox와 같은 최소한의 DTE를 사용해 볼 수 있습니다. 이는 실제로 혼란을 허용하지 않습니다.
그러나이 모든 정리 중에는 배 밖으로 나가지 마십시오. 환경에 약간의 혼란이 실제로 창의성에 도움이 될 수 있음을 시사하는 좋은 과학이 많이 있습니다. 이에 대한 가장 자주 인용되는 연구 중 하나는 Vohs, Redden & Rahinel (미네소타 대학교)의 심리학 과학 저널입니다. 신체적 질서가 건강한 선택, 관대함, 관습을 만들어내는 반면, 장애는 창의성을 낳는다. 아마도 이것이 신문 기자들이 집착하는 이유는“… 무질서한 방에있는 참가자가 질서 정연한 방에있는 참가자보다 더 창의적이었다”고 분명히 결론을 내리기 때문일 것입니다.
훨씬 덜 인기있는 의견은 반대 의견입니다. 환경 장애로 인한 자체 규제 실패 (Chaye & Zhu, 2014), 소비자 연구 저널에 발표. 이 연구는 무질서한 환경에서 일하는 사람들이 업무 수행 능력이 손상되었음을 발견했습니다.
이게 어디로 떠나나요? 혼돈이나 무균 상태에서 일해야합니까? 대답은 당신이 영감을 유지할만큼 혼란 스러울 수있는 균형을 찾는 것 같지만, 산만 해 지거나 물건을 찾는 데 어려움을 겪지는 않습니다.
생각을 펼칠 수있는 공간을 남겨주세요
숙고 할 때 방황 할 공간을 충분히 확보하는 것이 좋습니다. 역사상 가장 훌륭한 제독과 장군들은 전투 전략을 계획하는 동안 갑판에 대한 간격을 넓히는 데 오랜 시간 동안 유명했습니다.
싸우는 사람 만이이 관행을 따르는 것이 아닙니다. 많은 불교 승려들도“걷는 명상”을 옹호하며 그것이 마음의 명확성을 증진시키는 데 도움이된다고 믿습니다. 특히 풀어야 할 결점이있는 프로그래밍 문제가있을 때마다 갑판 주위를 명상하면서 산책하면서 다리를 약간 펴는 것이 도움이 될 수 있습니다. 분명히 여기서도 혼란이 없으면 병원에 가지 않고도 이것을 할 수 있습니다.
상사로서 창의적 노력에 대한 비판에 신중하게 접근하십시오.
건설적인 비판에는 아무런 문제가 없지만, 올바른 순간을 선택하고 올바른 방식으로 접근해야합니다. 그렇지 않으면 직원의 생산성을 떨어 뜨려 미래에 역효과를 낳을 수 있습니다. 그들에게 영감을주고 통찰력을 제공하는 대신, 실제로 위험을 감수하는 것을 두려워하게 만들 수도 있습니다. 이는 창의성을 파괴하는 좋은 방법입니다. 마리 케 로스 케스 창의적 성과를 도우거나 방해하는 제약 : 동기 부여 접근법, 창의적 근로자의 동기를 다루는 방법에 대한 프레임 워크를 제공하고 특히 의도하지 않은 방식으로 동기를 유발하지 않도록하는 방법을 제공합니다 (Creativity & Innovation Management, Vol 24, Iss 2, 2015).
2. 좋은 SOP 수립
비즈니스 관리 및 프로그래밍 절차에는 실용적으로 드러난 것보다 이론적으로 훨씬 더 현명하게 들리는 많은 경향이 있습니다. 특정 접근 방식이 귀하에게 적합한 지 여부는 귀하의 목표와 개인적으로 성공적인 결과라고 생각하는 것에 달려 있습니다.
제가 근무했던 회사에서 시도했지만 빠르게 중단한 방법론의 한 예는 쌍 프로그래밍(PEAR 프로그래밍과 혼동하지 마세요)입니다.
일부 사람들은 이 작업 방법론을 정말로 존경하고 애자일 개발 패러다임에서 그 위치를 칭찬하지만 우리는 이것이 매우 비효율적이라는 것을 발견했습니다.
처음에는 모든 워크스테이션에 두 명의 프로그래머가 필요했기 때문에 실제 개발 작업을 줄이면서 두 배의 비용을 지불하게 되었습니다. 또한 잦은 중지/시작 흐름과 불필요한 대화 경향으로 인해 이 방식으로 작업하는 것이 훨씬 더 느리다는 것을 발견했습니다.
페어 프로그래밍의 장점은보다 자연스러운 문서화와보다 엄격한 문서화로 이어졌다는 것입니다. 또한 버그를보다 쉽게 발견 할 수 있었고 알고리즘 강화에 대한 제안을 할 수있었습니다. 그러나 때로는 조정과 조정이 실제로 필요하지 않았기 때문에 동일한 장점으로 인해 문제가 발생했습니다.
이 접근법의 또 다른 위험은 프로그래머가 수정하기를 원하지 않기 때문에 시도하는 것을 주저 할 수있는 Roskes에 의해 식별 된 효과를 얻을 수 있다는 것입니다. 한 개발자가 매우 현명하고 전통적인 곳에서 성격 충돌이 발생할 수 있지만 다른 개발자는 더 창의적이고 자발적입니다.
프로그래머는 종종 페어 프로그래밍을 선호한다고 말합니다. 그것이 그들이 제공하는 사회적 상호 작용을 즐기기 때문일 수 있지만 이것은 사기 부스터를 제외하고는 생산의 효율성에 아무런 영향을 미치지 않습니다.
따라서 설정해야 할 것은 개발자에게 실제로 작동하는 것과 그렇지 않은 것입니다. 작동하지 않는 것들의 경우, 인기가 급상승하는 관행이라하더라도 폐기하는 것이 좋습니다. 팀이 빠르게 발전하는 데 도움이되는 것은 좋은 일입니다. 그러나 그들이 자신의 스타일에 맞지 않는 방법론으로 무게가 나가면 결국 문제를 일으킬 것입니다.
3. 자세한 문서를 장려
자세한 표시가 비 효율성을 증가시키는 것처럼 보일 수 있지만, 의견을보다 상세하고 정확하게 작성하는 데 걸리는 적은 시간은 프로젝트가 진행되거나 수정 될 때 많은 문제를 줄일 수 있습니다.
4. 불필요한 서류를 삼가십시오
잘 작성된 코드는 종종 자체 문서화입니다. 주어진 이름에서 함수가 어떤 역할을하는지 분명하다면 (거의 항상 그렇습니다), 더 많은 설명을 추가하는 것은 불필요한 것입니다. 변수 이름과 반환 값도 마찬가지입니다. 그들이하는 일의 이름을 분명히해야하며, 그렇게 할 수없는 경우에는 그 설명을 의견에 포함시켜야합니다.
5. 공백은 당신의 친구입니다
코드에서 공백을 적절하게 사용하면 코드를보다 쉽게 읽고, 검토하고, 이해하는 데 도움이됩니다. 좋은 문서화 및 자체 문서화 코드 작성과 함께 사용됩니다. 숙련 된 프로그래머 또는 프로그래머가 아닌 사람도 소스 코드의 복사본을 선택하고 각 함수의 목적과 작동 방식을 즉시 이해할 수 있어야합니다. 이상적으로, 누군가는 잘 작성된 코드를 공부하는 것 이상으로 프로그래밍하는 법을 배울 수 있어야합니다.
6. 복잡성보다 단순성을 선호
코드를 복잡하게 만들수록 코드를 풀기가 더 어려워집니다. 아이러니하게도 이것은 단축 조건을 전체적으로 작성하는 대신 사용하는 것과 같은 프로그래밍 단축키에 적용됩니다. 글쓰기에 시간을 절약 할 수 있지만, 경험이 적은 프로그래머가 나중에 코드를 검토 할 때 의도를 이해하지 못할 수 있습니다.
7. 철저한 테스트
코드는 점진적으로 자주 테스트해야합니다. 배포하기 전에 첫 번째 릴리스가 Alpha로 지정 되더라도 가능한 한 많은 사내 테스트를 수행해야합니다.
8. 버전 관리 사용
주요 프로젝트에서 버전 관리를 사용하지 않는 것은 미쳐야합니다. 그것 없이는, 당신은 당신 자신의 사소한 실수로부터 보호받지 못하며, 다른 팀원이 당신을 원하지 않는 무언가로 코드를 덮어 써서 실수로 (또는 의도적으로) 방해하기 쉽습니다.
결론
이러한 8가지 핵심 제안을 고려하면 귀하와 함께 일하는 모든 팀원을 위해 최대의 효율성을 이끌어내기 위한 자신만의 전략을 개발할 수 있습니다.
이들 모두를 반드시 적용할 필요는 없으며 일부는 실용적이지 않을 수도 있지만, 이들의 조합을 사용하면 번거로움을 덜고 작업을 완료할 수 있습니다. 보다 생산적인 작업 흐름은 단지 스트레스를 줄이고 자신을 위한 더 많은 시간을 제공하는 측면에서라도 시간이 지남에 따라 그 가치를 발휘할 것입니다. 그것은 노력할 가치가 있는 목표입니다.
코멘트 0 응답