콘텐츠
- 01. 코딩은 더 이상 자르지 마세요
- 폭과 깊이
- 02. 큰 경고
- 03. 인터넷이 말하는 것
- 매체 이해
- 04. 우리가 만드는 것
- 05. 데브 옵스
- 스택 이해
- 신비한 작업
- 편리한 도구
- 06. 개발자가 고칠 것입니다 ... 아마도
- 디버깅
- 07. 사용자가 원하는 것
- 경쟁 시장
- 08. 그리기 및 쓰기
- 09. 즐겨보세요
- 10. 날카로운 유지
- 마음에 드 셨나요? 읽어보세요!
개발자는 코드를 생성하는 지저분한 작업자 그 이상이되어야합니다. 우리는 더 많은 디지털 라이프를 기대하고 있으며이를 구축 한 사람은 바로이 사람들입니다. 그렇다면 최고의 개발자는 무엇을 알아야할까요? 너무 많은 개발자가 놓친 것 같습니다. 이것이 완전하지는 않지만 합리적인 코더를 놀라운 개발자로 만드는 것은 이러한 특성 때문입니다.
그러나 이것은 하나가 아니며 특히 XML을 구문 분석하거나 코드를 최적화하는 능력이 아닙니다. 코드 작성에 관한 책에서 가르치지 않는 놀라운 기술 모음입니다. 그들은 약간 여분의 것입니다.
왜 이렇게 배출합니까? 개발은 중요하지만 개발자는 항상 자신이 만드는 것이 아니라 다른 세계로 너무 자주 위탁되기 때문입니다. 이것은 작동하지 않습니다. 기술적 인 것이 든 개발은 코드 이상의 것을 이해하는 방법을 알고있는 사람들이 항상 번창합니다.
01. 코딩은 더 이상 자르지 마세요
우리는 코딩이 덜 인상적인 세상에 있습니다. 모든 사람이 사이트를 구축하고 일부는 코드를 작성하지만 그럴 필요는 없습니다. 사이트, 앱 및 기능을 만들 수있는 사람은 더 이상 괴짜 만이 아닙니다.
웹이 등장하고 사람들이 스스로 가르 칠 수 있었던 이래 독학적인 개발자가있었습니다. 하지만 졸업생들조차 위협을 받고 있습니다. 컴퓨터 공학 학위, AI 과정, 다양한 미디어 및 코딩을 가진 사람들과 함께 이력서를 얻지 만 여전히 뭔가 빠진 것이 있습니다. 때때로 많은 누락.
나는 이것을 처음으로 말하지 않습니다. '코딩은 더 이상 자르지 마세요'는 3 장의 제목입니다. 열정적 인 프로그래머, 다음과 같은 책과 함께 실용적인 사고와 학습 프로그래머가 코드 이상으로 자신을 개선하도록 촉구합니다. 팀의 책임감 있고 전적으로 인간 구성원이되는 것입니다.
폭과 깊이
개발자는 폭과 깊이라는 두 가지면에서 더 나아 져야합니다. 그들은 팀과 그들이 구축 한 것들과의 인간 상호 작용의 폭을 이해해야합니다. 작업중인 시스템의 깊이를 O / S까지 이해해야합니다.
이 내용을 읽어야하는 것은 개발자 만이 아닙니다. 개발자와 함께 작업하는 경우 더 많이 기대해야한다고 생각합니다. 그들이 말하는 내용을 스케치하게하세요. 그림, 사물 및 (작동하는) 컷 아웃으로 사람들이 시스템을 사용하는 인간에게 어떤 모습 일지 정확히 설명하도록합니다.
02. 큰 경고
개발자들에 대해서는 부정적으로 얘기 하겠지만 제가 하나이기 때문에 허락 된 것 같아요. 또한 여기서 제가 이야기하는 최소한 한 가지는 제가 만나는 많은 개발자들에게 사실이기 때문입니다. 그들의 작업은 훌륭하고 코드를 알고 있지만 시간은 경쟁적입니다. 우위가 필요하며 이것은 다음과 같습니다.
- 더 기술력이있다
과
- 있다 많은 더 인간
03. 인터넷이 말하는 것
'필수 웹 개발 기술'을 검색하면 기대할 수있는 내용이 표시됩니다. 프레임 워크 지식, x- 브라우저, CSS 및 JS. 여기에는 알아야 할 프레임 워크, 작성해야하는 플랫폼 및 주시해야 할 새로운 트렌드가 나열되어 있습니다.
이것이 우리의 미디어입니다. 그것들은 우리가 구축하는 것이지만 프로젝트 성공을 가져다주는 것은 아닙니다. 개발자는 시스템의 모든 세부 사항을 이해하고 API 및 새로운 CSS 기술의 모든 기능을 알려 주지만 여전히 사용할 수없는 것을 생성 할 수 있습니다.
매체 이해
개발자는 모든 사람과 마찬가지로 자신의 매체를 이해해야하지만 사용자, 팀 또는 다른 개발자와 같은 청중도 이해해야합니다. 그들은 자신의 매체가 세계 (즉, 프로덕션 환경)에 어떻게 적합한 지, 그것이 어떤 영향을 미치는지 (사람들이 어떻게 사용하는지) 이해해야합니다.
나는 이것이 '넓고 깊은'사람으로 묘사되는 것을 보았다. 넓습니다. 다른 인간과 함께 일하는 인간으로서 세상을 이해해야하기 때문입니다. 프로젝트에서 자신의 수준보다 낮은 수준의 철저한 기술 지식이 필요하기 때문입니다. 이러한 개발자는 프로젝트에 큰 도움을주고 프로젝트 속도를 변경합니다. 그렇지 않으면 기술 팀에서 넘쳐나는 지루한 세부 사항에 갇혀있는 비 기술 직원을 찾을 수 있습니다.
04. 우리가 만드는 것
나는 최근에 우리가 사이트를 구축하고, 호스팅을 관리하고, 작업을 수행하는 데 사용하는 모든 항목의 목록을 작성하여 참여하는 사람들이 처음 몇 주 동안 배울 수있는 기술 치트 시트를 가질 수 있도록했습니다. 우리는 사람들이 이러한 사실을 알고 있다는 것을 읽었 기 때문에 신입 사원에게 시작을 제공하기 위해 매일 사용하는 모든 것을 나열했습니다.
나는 6 개의 기술을 예상했지만 훨씬 더 많은 기술로 끝났다. 이 목록 ( '우리가 사용하는 것')에는 일반적인 CMS, 프로그래밍 언어 및 브라우저 기술뿐만 아니라 팀에서 자신이 사용했던 것을 기억하지 못했던 여러 도구도 포함됩니다. 그것은 모두 근육 기억이었습니다. 명령 줄에’git’,’phing’,’thor’를 입력해도 누군가가 아닐 수도 있다고 생각하지 않았습니다.
빌드 도구; CI; 버전 관리를위한 git은 당연한 것으로 받아 들여졌지만 CV를 되돌아 보면 거의 나타나지 않았습니다. 트렌디 한 것들이 나타날 것입니다 (그리고 특정 기관이 그들을 추가한다고 생각하는 것은 냉소적입니까?!). 그러나 종종 구체적인 경험이 없습니다.
이러한 도구는 프로젝트 개발을 가속화하는 데 중요하므로 언어, CMS 및 몇 가지 프레임 워크보다 훨씬 더 풍부한 도구 세트가 있는지 확인하십시오. 배포, 테스트, CI, 강력한 버전 제어 (자신이 아닌 팀 단위)가 필요하며 몇 가지 자습서가 아닌 이들의 핵심 개념을 이해해야합니다.
05. 데브 옵스
이러한 추가 도구와 트릭은 사람들이 'devops'라고 부르는 것에 깔끔하게 들어 맞습니다. Devops는 두 가지 전통적인 사일로에 직면 해 있습니다. 즉, 작업을 계속 실행하는 프로덕션과 새로운 작업을 만드는 개발 (종종 실행 중지)입니다. 사일로는 서로에 대한 동정심이 거의없는 두 개의 캠프로 이어집니다.
프로덕션 지식이없는 개발자는 프로덕션 스택에 아직없는 구성이나 기능을 사용하여 프로덕션에 적합하지 않은 코드를 생성하는 경우가 더 많습니다. 그들은 프로덕션 환경의 문제를 인식하지 못하기 때문에 프로덕션에 배포하는 대신 기능을 완성하도록 코딩합니다.
이러한 작은 세부 사항은 서버 관리를 해외로 보내는 추세로 인해 고통스러운 지연을 초래할 수 있습니다.
스택 이해
Devops는 그 자체로 지속적인 배포와 많은 자동화를 포함하는 거대한 분야입니다. 이것은 포괄적 인 요약이지만 개발자가 이해해야하는 핵심 사항은 실행중인 스택입니다. 이것을 서버 관리자에게 위임하는 것으로는 충분하지 않습니다. 플랫폼이 코드에 미치는 영향을 이해해야합니다.
Rails에서 작업하는 경우 Rails 코드를 읽고 Apache에서 Ruby를 실행하는 방법을 알아보세요. Java로 작업하는 경우 구성 옵션에 대해 알아 두십시오. 사용중인 Perl 인 경우 Perl 모듈을 설치하고 구성하는 방법을 이해하십시오.
신비한 작업
'우리가 사용하는 것'목록에는 이러한 항목이 많이 포함되어 있으며, 훌륭한 개발자는이 모든 신비한 작업이 어떻게 수행되는지 이해하기 위해이를 뛰어 넘습니다. 그리고 일단 확보하면 배포가 더 빨라지고 작업이 더 원활하게 배포되며 모두가 더 행복해집니다.
지속적인 배포 및 DevOps 관련 관행이 너무 표준이되어이를 실행하지 않는 개발자 또는 회사는 자신을 추월 할 수 있습니다. 다른 누군가가 시작하면 그들은 당신보다 빠를 것입니다.
편리한 도구
'devops'를 검색하면이 사람들이 사용하는 도구에 대한 아이디어를 얻을 수 있습니다. PHP와 MySQL 또는 Rails에 관한 것이 아닙니다. 소프트웨어를 제공하고 프로젝트의 위험한 부분을 위험없이 유지하는 것입니다. 배포, 자동화 및 개발자에서 프로덕션 환경으로의 파이프 라인을 최대한 빠르게 실행하는 데 집중합니다.
이러한 개발 스타일은 서로, 그리고 다른 부서 및 회사와 더 잘 협력하는 개발자를 제공한다는 것을 알게 될 것입니다. 타사의 API로 작업하는 경우 다른 쪽에서 발생할 수있는 문제를 이해하게됩니다. 서버 관리자와 함께 작업 할 때 필요한 항목을 이해하고 프로덕션 서버에서 소프트웨어 사이트를 어떻게 설치하는지 알게됩니다. 그 반대는 고통 스러울 수 있습니다 ...
06. 개발자가 고칠 것입니다 ... 아마도
'필수 웹 개발자 기술'에 대한 검색은 Quora의 Michael Greer (The Onion의 CTO)로부터 좋은 답변을 제공합니다.
- 게으름 : 어떤 일도 두 번 거부합니다 : 스크립트를 작성하거나 알고리즘을 작성합니다.
- Cowardice : 테스트 할 생각,로드 및 코드 영향에 대한 걱정
- 무모함 : 끊임없이 새로운 것을 시도하고 당일 아이디어를 내 놓습니다.
비겁함은 '세부 사항에주의'를 표현하는 좋은 방법입니다. 디버깅 및 테스트는 개발자가 W3Schools를 강타하거나 컴퓨팅 101 과정을 시작할 때 언급하지 않은 개발자 삶의 99 %입니다.
앱을 수정하려면 코드 디버깅뿐만 아니라 뛰어난 문제 해결 기술이 필요합니다. 때때로 사용자가 송장을 다운로드 할 수없는 경우 PDF를 생성하는 데 하루를 소비하는 대신 페이지를 인쇄 가능하게 만드는 것이 해결책입니다. 때로는 링크가 개발 일주일을 대체 할 수 있지만 개발자가 순전히 많은 줄의 코드를 작성하여 문제를 해결하는 경우에는 이러한 우아한 솔루션이 발생하지 않습니다.
많은 도구에도 불구하고 테스트는 많은 개발자에게 훌륭한 맹점입니다. xhprof와 같은 단위 테스트, 셀레늄, 부하 테스트 및 프로파일 링 도구를 사용합니다. New Relic과 같은 분석을 통해 앱의 설치 공간을 작게 유지합니다. 그리고이 모든 작업이 개발자의 작업의 일부라고 생각하세요. 그것은 여러분의 코드입니다. 의도 한대로 작동하는지 확인하세요.
디버깅
디버깅도 문제입니다. 디버거를 사용하는 방법이 아니라 문제를 디버깅하는 방법 – 그래서 Michael Greer의 목록에 추가하겠습니다.
- 성급함 : 실제 문제를 찾아 해결하기 위해 관련없는 정보를 공격적으로 무시합니다.
이것은 모든 디버깅 기술의 초석입니다. 무관 한 것을 무시하고 관련에서 의미를 찾습니다. 안타깝게도 많은 사람들이 몇 시간 또는 며칠 동안 관련없는 것을 슬쩍 망치고 같은 것을 10 번 시도하여 문제를 해결하는 경향이 있습니다.
디버깅에 대한 많은 책 (슬프게도 제가 출판사에게 발표 한 책이 아닙니다)이 있으며 모든 개발자는이 책을 모두 읽어야합니다. 정말 훌륭한 개발자는 코드 줄을 보지 않고도 시스템의 문제를 디버깅 할 수 있습니다.
07. 사용자가 원하는 것
주변 사람들이 무엇을하려고하는지 이해하십시오. 코드를 즐기십시오. CSS 파일을 완벽하게 들여 쓰기하거나 Rails 앱을 최적화하는 기술을 좋아합니다. 그러나이 모든 것이 목적임을 기억하십시오.
개발자는 비즈니스, 운영 및 비즈니스 프로세스를 이해할 필요가 있습니다. 이 지식을 가진 개발자는 사용자를 돕는 소프트웨어와 앱을 구축 할 수 있지만 종종 비정상적으로 생산적으로 보입니다. 이는 빠른 타이핑이나 스택에 대한 놀라운 지식 때문일 수 있지만 사용자가 원하는 것에 대한 지식 때문일 가능성이 높습니다.
경쟁 시장
원래의 요점으로 돌아가서, 개발이 더 쉬워지고 훌륭한 개발자를위한 시장은 더 경쟁력이 있습니다. 비즈니스 요구 사항을 이해하고이를 충족 할 수있는 우수한 것을 제공 할 수있는 개발자는 우위를 점할 것입니다. 시장과 고객을 이해하고 사람들이 돈을 떼어내는 이유가 모두 도움이됩니다.
데이터와 시간이 지남에 따라 변경되는 방식을 이해합니다. 개발자는 현재 직면하고 있거나 앞으로 올 것으로 예상되는 과제와 함께 새로운 기술을 정렬해야합니다. 이렇게하면 MD 또는 고객에게 멋진 새로운 아이디어를 제안 할 때 고객이 진정으로 원하는 것을 기반으로하고 이에 대한 예산 / 시간을 얻을 수 있습니다. (반대로, 목격해야 할 최악의 것은 개발자가 모든 질병에 대한 해결책으로 자신이 좋아하는 새로운 기술을 행하는 것입니다.)
개발자는 많은 제어 권한을 가지고 있습니다. 데이터베이스의 각 필드가 최종 사용자에게 무엇을 의미하는지 알아야합니까? 데이터를 변경하면 사용자는 무엇을 볼 수 있습니까? 사용자를 돕는 더 좋은 방법이 있습니까? 너무 자주 DB 관리자의 견해는 데이터베이스가 실제 세계를 잘못 표현하는 것이 아니라 데이터베이스를 잘못 반영한다는 것입니다. 세상은 엉망이고 놀랍게도 가장자리 케이스로 가득 차 있습니다. 그것을 처리하십시오, DB 관리자.
08. 그리기 및 쓰기
드로잉은 사물이 어떤 모습 일지 전달하는 가장 직접적인 방법입니다. 개발자는 화이트 보드, 종이 및 맥주 매트에 아이디어를 그릴 수 있어야합니다.
개발자는 의도를 전달하기 위해 종이에 프로토 타입을 만들고 스크린 샷을 인쇄하고 낙서 할 수 있어야합니다. 고개를 끄덕이는 개발자를 믿지 마세요. 그들이 이해하고 편집자를 열었다 고 말합니다.
저렴한 실패 : 최고의 코딩은 드로잉을 빠른 프로토 타입으로 시작하는 것입니다. 더 자주 실패하고 주변의 모든 개발자가 같은 방식으로 성공할 가능성이 높으므로 동일한 작업을 수행하도록합니다.
09. 즐겨보세요
그리고 링크를 움직여 문제를 해결하는 데 10 시간을 소비해야한다면 어떨까요? 일을 처리하는 것이 단지 도전 일지라도 즐기십시오.
개발자 (또는 누구)의 최악의 태도는 팀이 달성하려는 것에 대한 무관심입니다. 안타깝게도 개발자는 자신이 팀이 달성하는 것에서 벗어나 있다고 생각하기 때문에 일반적입니다. (열정적 인 프로그래머 "얼마나 더 재미있게 일할 수 있습니까?"라는 질문을 던집니다. 시도해보십시오.)
그리고 그 반대의 작업을 보여줄 준비를하세요. 'Ruby 경험'을 위해 Ruby에 대한 몇 가지 자습서를 시도한 후 확장하지 마십시오!
웹 및 앱 개발은 아직 젊은 직업이지만 개발자에게 정말 필요한 기술 세트가 확장되고 있습니다. 모든 사람들은 더 많은 개발자를 기대해야합니다. 왜냐하면 우리 모두가 험난한 뒷방에서 나오고 창의적인 과정에 더 빨리 참여할수록 결과가 더 좋아지기 때문입니다.
10. 날카로운 유지
이것을 좋은 라운드 10으로 만들기 위해 마지막으로 하나를 추가하겠습니다. 정신 차려. 경쟁을 찾으십시오. 최악의 경우는 고립 된 것입니다.
"당신이 속한 모든 밴드에서 항상 최악의 사람이 되십시오."
최악의 – 정말로, 아주 나쁜 – 프로그래머, 코더, 디자이너는 자신의 물건을 배우고 월계관에 안주합니다. 심박 조율기가 없으면 속도를 늦추기 쉽고 경쟁을 보지 않고 자신을 평균 이상으로 보는 것이 습관이됩니다.
따라서 더 나은 것을 찾아서 최악이 되십시오. 업무 외의 프로젝트에 참여하고, 피드백과 비판에 기여하고 구하십시오. 그들이 원하는 것이 무엇인지 더 잘 추측 할 때, 당신은 모두가 원하는 닌자 개발자입니다.
Dan Frost는 공식 AWS 파트너 인 풀 서비스 웹 회사 3EV의 기술 이사입니다. 그는 7 년 동안 CMS 및 웹 앱 개발 분야에서 일해 왔습니다.
마음에 드 셨나요? 읽어보세요!
- 앱 구축 방법
- 디자이너를위한 최고의 무료 웹 글꼴
- 증강 현실의 다음 단계 알아보기
