Search

반응형

'Software/개발자이야기'에 해당되는 글 21건

  1. 2022.05.08 프로그래밍은 어떻게 하나요? 1탄
  2. 2022.01.02 개발자라면 한 번 읽어보세요. SI 프로젝트
반응형

안녕하세요. 신기한 연구소입니다.

장거리 출퇴근을 하면서 많은 생각을 하는데요.

프로그래머가 되고 싶은 분들이 어떻게 하면 쉽게 이해하고 배울 수 있을까?

더 쉽게 설명해 주려면 어떤 방식이 좋을까?

이런 생각을 많이 한답니다.

 

변수를 어떻게 설명할까?

많은 책과 사이트를 찾아 보고 읽어보면 대부분 비슷하게 구성되어 있고

설명을 하고 있더군요.

개발자인 경우는 그 설명을 읽으면 이해도 되고 업무에 활용도 할 수 있지만

이제 개발자의 꿈을 갖고 있는 사람들이나

새내기 프로그래머들은 사실 그런 설명도 이해하기 힘들어하는 경우도 있더군요.

그래서 내가 아는 수준으로 설명을 하는 경우

초보 개발자 분들은 어려워 할 수도 있겠다는 생각을 하게 되었답니다.

"도대체 그래서 이걸 어떻게 어느 시점에 사용을 하라는 거지?"

"보면 이해 되는데 막상 개발할 때는 어떻게 활용하는 것일까?"

이런 의문들을 갖게 되는 것은 당연한 것이고

이런 의문들을 쉽고 이해할 수 있게 설명해 주는 것이 선배 개발자의 배려가 아닐까 싶네요.

 

여러분이 키오스크 프로젝트에 투입 되었습니다.

주문 결제에 대한 프로그래밍을 한다고 가정하고 중간 과정에 대해 설명을 해볼까 합니다.

메뉴가 화면에 펼쳐지고 이제 구매자는 원하는 메뉴를 터치하게 됩니다.

그러면 그 메뉴는 구매 목록 또는 장바구니에 담깁니다.

이때 메뉴판에서 터치해서 선택하는 순간 해당 메뉴의 유일한 구분 값인 메뉴 ID를 어딘가 담아서

장바구니 쪽에 전달해줘야 합니다.

값은 화면에 뿌려질 때 이미 가지고 있고 선택한 메뉴에 대해서만 장바구니로 이동해야 하는데

이때 값을 담아서 이동할 때 사용하는 것을 보통 변수라고 합니다.

변수?

변하는 수?

 영어로 Variables라고 합니다.

메뉴를 선택할 때 이벤트가 발생하고

해당 이벤트는 선택된 메뉴 ID를 건네줍니다.

그럼 변수에 담아 가져 가면 되는데

변수는 이름을 지정해야 합니다.

이유는 프로그램을 하다 보면 많은 변수를 사용하게 되고

그 해당 변수들은 각자의 독립적인 중복되지 않는 이름을 가져야 합니다.

중복된 변수명이 가능하다면 어떤 변수의 값을 사용할지 혼란스럽게 될 테니깐요.

우리는 메뉴 ID이기 때문에 이름을 menuId라고 만들어보겠습니다.

이제 menuId에 선택한 메뉴 ID를 담아두면 됩니다.

선택한 메뉴는 짜장면이고 메뉴 ID는 가정해서 "M00010"이라고 해볼게요.

menuId = "M00010";

보통 이런 구조로 변수에 값이 담기게 됩니다.

이것을 할당이라고 부릅니다.

할당은 "=" 기호를 사용하는데 수학에서는 "는" 또는 equal(같다)라는 개념으로 사용하는데

이 부분을 혼동해서는 안됩니다.

프로그래밍에서는 같다는 "=="로 2개를 사용하고 "="는 값을 넣어주는 할당의 개념으로 사용하거든요.

이제 menuId를 장바구니 목록으로 옮겨야 합니다.

목록이니 여러 개의 값을 담을 수 있는 배열이나 리스트를 사용하겠지요?

첫 주문 메뉴라면 해당 장바구니 첫 번째 공간에 선택된 menuId 값이 할당되게 하면 되겠네요.

배열이라고 했을 경우 basket[0] = menuId; 로 할당하면 되겠네요.

basket[0]에는 menuId라는 글자가 할당되는 것이 아니고 menuId에 할당된 값인 "M00010"이 할당됩니다.

menuId에 문자열을 나타내는 ""로 감싸져 있지 않기 때문에 변수로 인식됩니다. "menuId"라고 감싸서 할당했다면

basket[0]에는 menuId의 값인 "M00010"이 아닌 "menuId" 이 글자 자체가 값으로 인식되어 할당되게 됩니다.

basket[0] = menuId;로 변수 할당을 했기 때문에 basket[0]값을 출력한다면 "M00010"이 출력될 것입니다.

회원 가입이 필요합니다.

우리는 보통 아이디, 성명, 비밀번호, 연락처 등의 정보를 입력한 뒤 가입을 시도하게 됩니다.

이때 아이디, 성명 등의 값을 화면의 Input 박스에 타이핑해서 넣고

가입하기를 누르면 해당 입력값들이 전송되고 가입신청이 완료됨을 알 수 있습니다.

이때도 변수가 필요한데요.

바로 아이디, 성명, 비밀번호 등의 화면에서 사용자가 입력한 값을 가지고

서버 쪽에 전송해서 입력한 데이터를 저장을 하게 되는데요.

이 값들을 변수를 만들고(이름 짓기, 초기화 등) 입력한 값을 할당해서

서버까지 값이 이동할 수 있게 해 준답니다.

 

다음 편으로...

반응형
반응형

안녕하세요. 신기한 연구소입니다.

어느 순간 2021년은 사라지고 

새로운 2022년이 나타났습니다.

21년도는 시작부터 힘들었던 기억이 있습니다.

좋은 일을 한다는 사명감으로 시작했지만

난관도 많았고 힘든 시간도 많았지만

제일 중요한 것은 사람이 어렵다는 것을 한 번 더 실감하게 된 한 해였다고 생각되네요.

모래성처럼 겨우 겨우 아슬아슬하게 만들어 가던 프로젝트를

관리자가 눈앞의 수익만 보고 발로 뻥 차 버려서 잠시 동안 좌절했던 21년 초.

수익 계산에 끌려가서 평범한 개발만 재미있게 하고 왔던 프로젝트.

정말 다사다난했던 한 해였답니다.

그 한 해를 보내면서 여러 개발자 친구들을 만났습니다.

그 친구들을 보면서 느낀 것은

다들 서로 생각이 많이 다르다는 것을 알게 되었네요.

그럼 요즘 젊은 개발자 친구들은 어떤 생각을 하면서 프로그래머의 길을 걷는지 잠깐 살펴보겠습니다.

 

몇 가지 유형으로 나눠보겠는데요.

그렇다고 이 유형이 전체를 말하지는 않습니다.

직접 만나 본 친구들을 기준으로 나눈 유형이거든요.

 

SI 프로젝트를 좋아하는 친구가 있습니다.

지금까지는 유지보수만 해서 SI에 도전해 보고 싶어 했고

앞으로도 SI를 하고 싶어하는 친구랍니다.

열정도 대단하고 준비도 많이 한 친구거든요.

설계 문제점도 재빠르게 파악하고 건의도 합니다.

프런트, 백을 구별하지 않고 다양하게 접근을 시도하며

또한 새로운 기술에 대한 열정도 대단하더군요.

한 가지만 수정한다면

멋진 개발자가 될 거라 확신합니다.

수정할 부분은 판단에 대한 자존심이 강합니다.

누군가 본인의 업무에 대해 이상하거나 잘못된 부분을 지적하면

수긍하고 다시 확인 후 조정이 필요하다면 협의해서 진행하면 최상의 상황이라 보는데

이 친구는 그 부분에 대해 승부욕을 붙여서 이상한 변명을 하더군요.

결국 그렇게 진행하다 보면 고집쟁이로 불릴 수밖에 없답니다.

발전하고 싶다면 상대의 의견을 듣고 다시 확인하는 습관이 필요해 보입니다.

또 다른 친구가 있습니다.

일은 꼼꼼하게 잘 합니다.

불평은 있지만 묵묵히 자기 업무를 처리합니다.

하지만 대화가 부족하다는 의견이 있습니다.

말 수가 적기 때문에 그런 의견이 있어 보입니다.

개발자가 개발만 잘하면 좋겠지만 혼자 하는 일이 아니기에

본인의 의견도 잘 표현하는 것이 중요하다 생각되는 친구랍니다.

 

자신감이 넘치는 친구가 있습니다.

하지만 기초가 부족합니다.

그 약점을 본인이 빨리 알고 채워 나가면 좋겠지요.

개발하다가 오랜 시간 오류를 수정하지 못하고 있더군요.

그래서 옆에서 같이 확인해 보니 시야가 좁았습니다.

오류가 발생하면 오류 발생 위치부터 역으로 추적하면서

왜 오류가 발생했는지 조사를 해야 합니다.

하지만 이 친구는 오류가 난 부분에만 집중을 합니다.

몇 시간을 지나도 당연 해결이 안 되겠지요.

이런 경우는 대부분 경험이 부족해서 나타나는 현상입니다.

다양한 경험을 한 선배, 사수, 멘토와 함께 일을 한다면

금방 멋지게 성장할 수 있는 멋진 프로그래머랍니다.

 

일에 대한 중요한 순서를 망각하는 친구도 있습니다.

리더가 우선순위를 지정해도

잘못된 본인의 판단으로 다른 업무를 진행하고

원래 지시받은 업무는 소홀하게 되는 상황이 발생합니다.

이런 경우는 빨리 본인의 잘못된 습관을 고쳐야 합니다.

프로젝트는 혼자 하는 업무가 아닙니다.

리더가 있고

리더는 큰 그림으로 일정을 관리하고

개발자에게 업무를 지시하게 됩니다.

서로의 신뢰 속에서 프로젝트가 진행되어야

효율적으로 시간 관리도 가능하겠지요?

리더의 지시를 어기고 다른 업무를 하게 된다면

서로 간 신뢰가 깨지고

업무 진행에 차질이 발생할 수 있습니다.

이런 상황이 지속적으로 발생된다면

리더는 그 개발자를 신뢰할 수 없기에

업무를 배정할 수 없게 됩니다.

 

결론적으로 보면

개발자는 자기 계발에 충분한 시간과 노력을 들여야 합니다.

그리고 팀원으로 리더를 존중하고

특별한 문제가 없다면 리더의 길을 따라줘야 합니다.

지고 이기는 게임이 아닙니다.

같이 협업해서 가는 공통 업무이므로

절대 고집과 변명은 삼가야 합니다.

 

리더의 지시를 잘 따르고

자신의 업무에 최선을 다하며

프로가 되기 위해 지속적인 자기 계발(공부)을 해야 하며

선배들의 장점을 잘 보고 배워서

효율적으로 개발할 수 있는 프로그래머가 돼야겠습니다.

 

즐거운 프로그래머의 한 해가 되시길 바랍니다.

 

 

 

반응형