매일 꾸준히, 더 깊이

본격적인 포스팅의 앞서 참고자료의 링크 내용을 번역했다는 점을 우선 밝힙니다. 의역과 오역이 있을 수 있습니다. 댓글로 지적해주시면 수정하겠습니다. 선배 엔지니어에게 '얼마정도 진행됐습니까?'나 '왜 이 작업에 이만큼의 시간이 걸린건가요?'라고 듣는 경우가 있지 않나요? 또한, 작업 견적이나 업무 분할을 제대로 하지 않고, 코드를 쓰기 시작하는 경우도 있다고 생각한다. 이로인해 결국 마음대로 코드를 쓰기 시작해 결국 거의 1부터 코드를 고치는 경험도 있을 것이라고 생각한다. 나의 경우는 업무 방식을 제대로 주입받았지만, 주의에 얘기를 들어보니 업무 방식을 어떻게 업무를 해야하는지 잘 모르는 사람들이 있는 것 같아 이 포스팅을 작성하게 됐다. 또한 엔지니어를 위해서 작성하였지만, 어떤 일에도 보편적으로 적..

일본어 발음 뜻 プロパー 특히 IT업계에서는 협력 기업이나 하청 회사 등의 스태프와 구별하기 위해, 자사 사원을 'プロパー社員' 이라고 부른다. 特にIT業界では、協力企業や下請け会社などのスタッフと区別する際、自社社員のことを「プロパー社員」と呼びます。 アサイン (assign) 일반적으로 'アサイン'은 '어떤 업무에 대한 인재를 할당하다'라는 뉘앙스로 사용된다. 一般的には「アサイン」は、「ある業務に対して人材を割り当てる」というニュアンスで使用します。 アジャイル アジャイルとは『すばやい』『俊敏な』という意味で、反復 (イテレーション) と呼ばれる短い開発期間単位を採用することで、リスクを最小化しようとする開発手法の一つです。アジャイル型開発手法にはいろいろなバリエーションがありますが、例えば次のような進め方で開発をします。 1. 顧客とエンジニアが..

1. 상사나 고객에 사용하면 실례가 되는 말·표현 15선 동료나 후배에 대해 사용해도 문제없지만, 상사에게 사용하지 않는 것이 좋은 말과 표현에 대해 소개하도록 하겠다. 1) ご苦労さまです 후배에게 사용하는 말로 'お疲れ様です。'가 적당한 표현이다. 2) 了解しました。 ’承知いたしました。’나’かしこまりました。’를 사용하도록 하자. 3) しばらくぶりです。 ’しばらくです’는 동료나 후배에게 사용하는 표현이다. 예를 들어 ’お久しぶりです’라고 말하는 경우, 상대의 위치를 고려하지 않고 사용하는 표현이므로 실례까지는 아니다. 그러나, 경의를 표현하고 싶은 경우 'ご無沙汰しておりました'를 이용하는 것이 좋다. 4) いつもお世話様です。 ’お世話様です。’는 ’ご苦労様です。’와 같은 사용법으로 본인보다 위의 위치에 있..

1. 질문 하는 법 1) 제대로 질문한다. 단순히, '움직이지 않는다.'라고 하는 학생이 있다. 그러면 '그렇나요? 움직이지 않나요?'라는 대답밖에 들을 수 없다. 이것은 '엄마, 화장실'과 같은 레벨이다. 2) 소프트웨어 질문의 대전제 (1) 환경 (OS, ROOT의 버전 등) 을 전달한다. (2) 증상을 전달한다. (3) 에러나 출력을 전부 전달한다 (의역, 변경, 생략하지 않는다.) (4) 문제가 발생하는 부분의 최소 코드를 전달한다. (수 백 행에 이르는 코드는 누구도 읽어주지 않는다.) (5) 시도한 것이 있다면 전달한다. (상대도 같은 수고를 하지 않도록 한다.) 2. 잘못된 질문의 예 「ROOT 기동이 되지 않아요. 무슨 에러가 나와서.....」 이렇게 질문해버리면 상대방으로부터 다음과 같은..

기술이나 제품의 조사 보고서는 결론부터 간단히! 조사 보고서는 대상 기술이나 제품이 시스템에 이용 가능한지 아닌지의 여부를 보고하는 것이다. 읽는 쪽 혹은 고객도 그것을 바란다. 조사 보고서를 작성할 때는 보고자(쓰는 사람)가 쉽게 해버리는 실수가 조사의 이유, 조사의 경위나 조사에 있어서 자신이 실행한 것 등 조사와 관련된 사항을 처음부터 순서대로 자세히 기술하는 것이다. 보고하는 쪽에 있어서는 조사를 제대로한 것을 표현하고 싶거나 전체 내용을 제대로 제공하면 안 된다고 생각해, 조사 내용을 시간의 흐름에 따라 모든걸 기록해버리고 만다. 그러나 고객의, 특히 상급관리자나 경영자가 필요한 것은 조사의 요점이다. 조사 보고서에서 중요한 것만을 간략히 기술하지 않으면 안 된다. 1. 형식에 따라 쓰면 좋다...

1. 테스트 ​프로그램 코딩을 완료하고 릴리즈 전 실시하는 테스트 오류 발생은 주로 요건 정의나 설계 단계에서 나타나며, 검출은 수용 테스트나 릴리즈 후에 실제 환경에서 많이 나타난다. 테스트를 소홀히 하면, 릴리즈 후 발생한 오류에 대해 유저에게 사과를 하거나 환불이 필요하다. 그리고 한 기업으로 손실, 신뢰가 없어지는 결과가 생긴다. 미리 계획이나 대책을 생각하고 테스트를 경시하지 말 것. 오류에 대한 비용을 생각해 볼 때, 릴리즈 후의 오류 비용은 단체 테스트의 오류 비용의 수백배의 비용이 든다. ​1. 단체 테스트 (単体テスト) 2. 결합 테스트 (結合テスト) 3. 기능 테스트 (機能テスト) 4. 시스템 테스트 (システムテスト)(부하 테스트, 볼륨 테스트, 보안 테스트 등) 5. 시나리오 테스트 ..

1. 단체 테스트 (単体テスト) 단체 테스트란 클래스나 함수 단위의 프로그램 템스트이다. 주로 설계한 대로 그들이 움직이는지 테스트하고, 논리구조가 적절한지 확인한다. 1) 기능확인 테스트 (機能確認テスト) 하나의 모듈이 설계서나 사양서대로 동작하는지 확인하는 테스트 2) 제어 흐름 테스트 (制御フローテスト) 프로그램의 논리구성에 따라, 명령이나 분기 등이 실행되는지 확인하는 테스트 3) 데이터 흐름 테스트 (データフローテスト) 데이터나 변수가 '정의', '사용', '소멸'의 순서대로 실행되는가를 확인하는 테스트 2. 결합 테스트 (結合テスト) 결합테스트란 단체 테스트로 검증한 프로그램을 조합하여 실행하는 테스트이다. 1) 상태전이테스트 (機能確認テスト) 상태전이도나 상태전이표를 토대로 동작을 확인하는 ..