영어를 잘 모르거나 영어울렁증 있는 분들도 해당되는거 같네요 길고 복잡한 영어로 된 코드 수십개의 클래스들 보자마자 한숨 나오는 분들요. 그래서 코딩에서 영어는 필수적이고 영어 울렁증은 당연히 없어야 하고 영독해 능력과 코딩 필수 단어들 암기 정도는 있어야 한다고 봅니다.
솔직히 이제 국비교육 막 졸업한 새내기 입장에서 스파게티코드 쓰는 사람의 심정을 알기에 더욱 안타까운... 클린코드를 “잘 돌아가는데 굳이?“ 하면서 귀찮아서 안쓰는 사람도 있는 반면에, 나처럼 무식하게 때려넣는 방법 외에 아는게 없어서 그래도 깔끔하게 짜고싶어서 이것저것 시도해보면 오류가 자꾸 나서 그냥 원래 알던 무식한 방법으로 작성하는 경우도 있는 것 같음... 그럴 때 누군가 옆에서 효율적으로 쓸 메소드나 함수 알려준다면 진짜 편할텐데...
주석만 달아놔도 문제가 해결이 되는 경우가 있긴한데 중소기업정도 되는 곳은 그런 주석도 없고 문서화도 안되어 있어서 진짜 한땀한땀 다 뜯어봐야하는 경우가 있긴합니다. 게다가 리펙토링 하는 과정에서 이상하게 참조되어있는 함수들 때문에 프로그램이 뻗어 버리는 경우도 허다하구요.. 정말 시간이 많이 걸리더라도 문서화 작업 혹은 시간이 너무 없다하시면 주석이라도 달아 놓는게 나중에 내가 다시 봐도 이해하기 쉽고 남들한테 이게 뭔하는 변수 혹은 함수인지 설명안해도 되는 길인 것 같습니다. 그마저도 모르겠다 못하겠다하면 포기해야죠.
그런 놈들 특징이 어디서 주워들은건 있어서 "주석은 최대한 안 다는게 좋다. 주석은 초보들이나 다는거다" 이딴 소리 하고 다님 ㅋㅋㅋ 주석을 안 다는거 좋지 ㅋㅋㅋ 근데 그건 니가 함수 이름과 파라미터가 문서를 대체할 수 있을만큼 명확하게 구현했을 때나 해당되는 거라고 ㅋㅋㅋㅋㅋ
웹이나 서비스 부분이면 적용할만한데 몇십억 짜리 장비에 들어가는 건들지도 못함... 사전에 테스트 코드로 시뮬레이션 해도 실제로 적용해서 뻑나면 코드 부터 시작해서 기구물까지 잘못된거 찾기 전까지는 다 내 잘못임. 막상 문제 원인 찾아보면 고객사가 설명서 안보고 마음대로 조작하다가 사고난게 대부분...
함수 하나에 500줄 넘어가는 코드를 보신 적 있나요? 시간만 투자하면 읽을 수야 있겠지만 그런 쓰레기 코드들 보고 있으면 진짜 현타 오지게 옵니다. 당장 옆에 이 코드 짠 사람 있으면 이 함수가 어떤 점에서 문제인지, 왜 500줄이 넘어가게 됐는지 조목조목 설명할 수 있을 정도로 엉망인 코드인데 이런거 몇 번 당하면 진짜 회의감 옵니다. 심지어 그런 코드가 몇 년 전에 짜여진 코드도 아니고 실시간으류 PR 로 날라온다면 진짜 ㅋㅋㅋㅋ 저도 처음에는 코드리뷰에 한 3시간씩 쓰면서 고쳐보려고 했는데 이제는 포기했습니다. 내 업무 할 시간도 부족한데 고쳐지지도 않는거 뭐하는거지 싶어서 걍 LGTM 치고 머지하네요
루프를 모르는 개발자는 없음. 그거 보다는 코드가 읽기 힘들어지는 이유를 제대로 이해해야하는데 대부분은 기능 개발에만 집중하고 클린 코드에 대한 이해가 너무 부족해서 더러운 코드가 나오는거. 함수 역할 분리는 개나 줘버리고 그 코드 짠 자신도 그 함수가 어떤 역할을 한다고 명확한 설명을 할 수 없으니 당연히 함수 이름, 파라미터/리턴 타입도 그지같이 만들어지고, 함수가 명확하지 않으니 재사용성도 같이 떨어지고 그냥 악순환의 반복 ㅋㅋ
확실히 코드 말고도 기획에서나 마케팅 등 문해력 부족한 사람들이 점점 늘어나더라고요. 저도 고등학교 때, 언어가 그렇게 좋지 못했는데, 이게 일을 하면서 제가 살기 위해 하다보니 되더라고요. 무엇보다 문해력이 떨어지면 업무 파악부터 자신이 하는 업무의 기획서나 문서 작성 등 모든 부분에서 시간이 그만큼 들어가니 비효율적이기도하죠. 사실 별거 아니지만 글의 요지나 문맥만 제대로 알아도 쓸데없이 싸울 일 없는데, 댓글도 마찬가지구요 ㅎㅎ 오늘도 좋은 정보 감사합니다 ❤
@@sgggggw 방법 따로 없어요. 저는 이전에 통과한 사업 계획서나 발표자료 달달 보면서 외웠어요. 근데 한가지 팁이라면 사업 발주 기관에서 어떤 기준으로 뽑을까? 이걸 보고 내가 작성하는 글의 특징과 특성을 파악하고 있어야 된다? 는 것이죠. 기획의 경우에 나를 모르는 기관에서 나의 아이템이나 사업을 선정해주도록 뽑아야하는데, 결국 있는 것 잘 포장해서 설명하는 자리거든요. 그리고 국가기관의 경우에 서식을 중요하게 보니까 그러한 것도 맞추고요. 결국 이러한 일을 잘하려면 글을 잘 읽고, 글에서 요구하는 것을 파악하는 게 잘 되야하는데 그 도움이라는게 한두가지가 아니라서요. 신문, 논문 등 다양한 글을 처음부터 끝까지 보면서 핵심을 요약하는 것도 중요하고요. 뉴스, 신문에서 내가 좋아하는 글이 아니라 경제나 정치, it기술 등 정보를 보되, 넓게 보는 자세로 보기도 하는것도 필요해요. (이건 뭐 좁게 보는건 누구나 다 하죠. 댓글 보면 난리 치는게 이 좁은 것만 보고 이야기하는 것인데) 그래서 정치적인 부분이 어떻게 우리 사업에 영향을 미치고, 경제적인 것이 앞으로 어떤 부분에 미칠까를 개인적인 추측이 아니라 타당한 근거 자료들(어디 사이트에서 긁어오는 것이 아니라 저명한 언론이라던지, 기관 등) 가져와서 짦게 요약한다던지 등 다양한 방법도 했던 것 같아요. 솔직히 인공지능 추천으로 보고 싶은 것만 보는데, 이게 올바른 사고를 못하게 합니다. 그래서 언론사도 메이져로 한두개씩 보면서 다른 논리가 있으면 비교도 하고 그렇고요. 정답이 되셨으면 좋겠는데, 어디까지 개인적인 부분이라 안맞을 수도 있어요.
까놓고 말해서 인수인계 받은 프로그램이라면 그냥 디버깅 돌리면서 한 줄씩 확인하면 됩니다. 어떤 데이터가 들어오고 어떻게 처리하며 무엇이 return 되는지 하나씩 확인하면 아무리 긴 코드라도 파악됩니다. 그리고 한 줄씩 주석을 달아놓으면 이해에 더 도움이 되겠죠. 개발자라면 디버그 돌리는 거에 익숙해져야합니다. 킹치만 귀찮아서 안 하게 되는 건 안 비밀.
추가적인 문법 규칙도 생소하고 펑션콜 제한등이 빡빡한 우주/항공/차량용 C코드는 더더욱 복창 터집니다. 특히 개나소나 다 만드는 차량용은 끔찍한 혼종의 세상이죠. C파일 하나에 펑션도 몇 개 없는데 수십만 라인의 코드... 불러올 때 이미 IDE부터 괴성을 질러요. 그 판에서 10년 굴러먹었더니 문해력까지는 모르겠는데 문해지구력은 우주 최강이 되었습니다.
