잘못을 저질렀다[하]

본문은 최초로 primalskill.blog/mistakes-were-made-part-2에 발표되었다
만약 당신이 아직 읽지 않았다면, 새로운 탭에서 그것을 열고, 먼저 한 번 읽어 보세요.

이 시리즈의 두 번째 부분을 계속해서 응용 프로그램 단계에서 어떤 오류를 피해야 하는지 살펴봅시다.

적용 수준 오류

버전 제어를 사용하지 않음

유일한 개발자라도 Git나 Mercurial 등 버전 제어를 진정으로 배우고 사용해야 합니다.
간단하게 말하면 여러 개의 파일을 편집하려면 코드에 대해 버전 설정을 해야 한다.
분산된 버전 제어 시스템(예를 들어 Git)의 장점은 코드 라이브러리를 고도로 사용할 수 있고 뚜렷한 파일 변경 역사를 가지며 많은 다른 시스템에서 반전할 수 있다는 것이다.
실제 코드 관리 서비스는 Github이지만, 당신도 Gitlab 또는 Bitbucket을 사용할 수 있습니다.

메시지 제출 지연

만약 당신이 한 팀에서 일하고 버전 제어를 사용한다면 개발 과정의 모든 단계에서 협업과 소통을 개선하기 위해 노력해야 한다.
나는 새로운 개발자(또는 팀의 초보자)가 범한 오류 중 하나가 버전 제어를 자신의 개인 코드인 리포로 사용하는 것을 보았는데, 같은 리포를 사용하고 서로의 코드, 특히 코드 변경을 이해해야 하는 다른 팀원들을 무시했다.
이것들은 내가 자주 보는 약속들이다.

이런 유형의 제출 소식은 다른 팀원들에게 진정으로 어떤 변화가 생겼는지 알려주지 않는다.팀원들은 파일 변경을 확인해야 한다. 이런 변경은 개발 시간과 자원을 소모하고 좋은 협업이나 심사를 추진하지 못한다.
제출하기 전에 반드시 심사숙고한 후에 필요하면 제출을 함께 수정하고 변경하는 것이 관련이 있다.
좋은 코드를 만드는 데는 실천이 필요하다. 이 자원들은 좋은 제출 메시지를 작성하는 데 도움이 될 것이다.

How to Write Good Commit Messages: A Practical Git Guide

Writing good commit messages

테스트 안 쓰기

시험 볼 시간 없어요, 그렇죠?또 다른 측면에서 볼 때, 컴파일링 테스트의 장점은 장기적으로 보면, 실제로는 개발 시간을 절약할 수 있다는 것이다.
테스트를 작성하는 데 많은 시간이 걸릴 수 있습니다. 이것은 어느 정도 정확하지만, 복구할 시간이 필요 없는 버그를 더 적게 도입함으로써 '손실' 을 얻을 수 있습니다.
쓰기 테스트는 반드시 프로젝트 평가에 포함되어야 하며 프로젝트 매니저는 테스트의 장점에 대한 교육을 받아야 한다.
서로 다른 유형의 테스트 전략이 있는데 가장 유행하는 것은 unit testing이다.기타 테스트 유형은 functional testing, 종단(E2E) 또는 integration testing입니다.
개발자들은 명명된 약속의 전화를 자주 끊는다. "당신은 그것을 단원이나 집적이라고 어떻게 부릅니까? 아니요! 기능 테스트".
비록 모든 유형의 테스트 전략은 장단점이 있지만, 나의 프로그래밍 경험은 이것이 적어도 코드의 관건적인 부분에 대해 테스트를 작성하기만 한다면, 이것은 당신이 왜, 단원, 집적, 기능 또는 무엇이든 상관없다는 환영받지 못할 관점일 수도 있다는 것을 알려주었다.
훌륭한 집적 테스트와 쓸모없는 단원 테스트를 작성할 수 있다. 반대로도 마찬가지다.

통일된 인코딩 스타일과 기준을 결정하지 못했다

아니오, 인코딩 스타일은 탭과 빈칸만 있는 것이 아닙니다.
한 팀에서 일하는 것은 큰 이익을 가져왔고 희생도 없었다. 그 중 하나는 당신이 싫어하는 인코딩 스타일이었다.
인코딩 스타일을 사용하는 것은 코드의 수명과 관리성에 매우 중요하다. 만약에 이미 확립된 업무 방식이 있다면 새로운 팀원들은 프로젝트에 쉽게 소개될 수 있다.
어디서부터 시작할지 모르면 다른 사람이 어떻게 하는지 보는 게 좋을 거야 바퀴를 재발명할 필요 없어😊

Google Style Guide - C++에서 JavaScript까지의 설명서 포함

AirBnB Style Guide - JavaScript 인코딩 스타일 자세히 살펴보기

Github Style Guide - 브랜드, 디자인, Ruby 및 JavaScript 가이드

PHP-FIG Coding Standards-PHP-FIG는 광범위한 코딩 스타일과 other PHP coding standards

Coding Conventions - 서로 다른 프로그래밍 언어의 다양한 스타일

IDE 도구는 코딩 표준을 준수하는 데 도움이 됩니다.

ESLint - JavaScript의 문제 해결

W3C Validator - HTML/CSS 코드 검증

Prettier - 프런트엔드 코드

의 독선적인 포맷 프로그램

카우보이 코드

다음 코드를 보십시오...

<?php
for ($i=1; $i <= $info['Docs']; $i++) {
?><img src="/prev/<?= alphaID($args['Docs']) ?>/<?= $i ?>?en"
    style="max-width: 100%; max-height: 100%"><br><?php
}

if ($this->app->client['Domain'] == 'example.com') {
    ?><script src="/js/jquery-2.2.3.min.js"></script><?php
} else {
    ?><script src="//ajax.googleapis.com/ajax/libs/jquery/2.2.2/jquery.min.js"></script><?php
}
?>
<script type="text/javascript">
$(window).on("load", function() {
    window.print();
    parent.printLoad();
});
</script>
<?php
$this->log->log([
    'Type' => 'Doc',
    'Action' => 'Print',
    'Relevant' => $info['UUID']
]);
?>

...이것이 당신이 기억하고 싶은 방식입니까?만약 다른 개발자들이 이 코드를 본다면, 나는 그들이 살인자를 생각할 것이라고 확신하기 때문이다.
Cowboy-coding 또는 spaghetti code은 개발자가 코드를 작성하는 불안정성을 가리키며 인코딩 스타일을 무시한다("이 줄에 추가하자...").개발 환경("생산 환경에 이 줄을 추가하자...").
코드를 작성하는 과정은 프로그래밍 과정의 10% 정도를 차지하고 나머지 90%는 문제 해결, 임무 배정, 구조 결정, 코드 심사와 심사에 대한 사고 해결 방안으로 구성된다.
모든 개발자는 적당한 관리 프레임워크를 가지고 이 프레임워크에서 일을 할 수 있으며 서로 다른 장면에서 명확하게 정의된 절차를 가져야 한다.
그럼 개발자는 왜 이러는 거예요?스트레스, 경험, 게으름 관리도 작용했기 때문이다.
개발자는 특정한 프로그래밍 문제에 대해 고집을 부리지 말고 10분 동안 그들이 제시한 해결 방안과 프로젝트 구조 전체와 얼마나 부합되는지 진정으로 생각하는 것을 배워야 한다.
관리 스트레스에 관해서 나는 이렇게 말해서 미안하지만, 이것은 완전히 나쁜 관리자의 잘못이다.나는 아직 한 고객을 만난 적이 없다. 그는 문자 코드를 작성하기 전에 해야 할 프로젝트 관리 결정을 고려하지 않고 특성을 원한다.

종속성 업데이트 안 함

기사의 '유지보수 부족' 부분에서 언급한 바와 같이 정기적인 업데이트 주기는 매주, 2주마다, 적어도 매달 한 번씩 실행되어야 한다.
전단 개발은 고도로 동적이며 유행하는 자바스크립트 모듈은 매일 업데이트되고 돌파적인 변경을 자주 도입한다.이것이 바로 의존항을 정기적으로 갱신하는 것을 건의하는 이유다.
정기적으로 업데이트하면 빈틈과 안전 빈틈을 줄일 수 있다.가능한 최신 패키지 버전을 사용하십시오.

방어성 프로그래밍 사용하지 않음

소프트웨어 개발에서'방어적 프로그래밍'이라는 용어가 있는데 Wikipedia에 따르면 다음과 같다.

Defensive programming is a form of defensive design intended to ensure the continuing function of a piece of software under unforeseen circumstances. Defensive programming practices are often used where high availability, safety, or security is needed.

이것은 단지 간단하게 말하자면 개발자는 예견할 수 없는 장면을 처리할 수 있는 프로그램을 시종일관 만들어야 한다. 예를 들어 제3자 서비스의 오프라인, 네트워크 요청 소모 시간 등이다.
만약에 웹 응용 프로그램이 Twilio와 같은 제3자 API 서비스에 의존하여 오프라인 상태가 된다면 이 웹 응용 프로그램은 이 오류를 처리할 수 있습니까?
만약 요청이 어떤 이유로 너무 오래 걸리면, 프로그램은 요청 시간 초과를 실현하고 오류를 되돌려 장시간 실행된 요청을 끊거나 처리합니까?
API가 오류를 반환하는 경우 프런트엔드 코드는 재시도 요청입니까? 아니면 표시 오류를 아예 포기하거나 아무 것도 표시하지 않습니까?
이것들은 모두 간단한 문제들로 복잡한 답안이 있고 심지어는 더욱 복잡한 실현도 있다.어쨌든 소프트웨어 개발자는 코드를 개선하기 위해 가능한 한 방어적인 프로그래밍을 해야 한다.

배포 전에 체크리스트 없음

개발자들은 배치 전에 코드를 검사하는 것을 자주 잊어버려서 오류, 즉각적인 복구와 재배치를 초래한다.😅
내가 보기에 이 임무는 CI/CD를 통해 자동화되어야 하지만 항상 가능하거나 작은 프로젝트에 의미가 있기 때문에 수동으로 완성하는 것이 가장 좋다.
API 및 프런트엔드 코드의 경우 항상 다음과 같은 두 가지 훌륭한 리소스를 사용합니다.

API Security Checklist

The Front-End Checklist

결론

소프트웨어 개발은 고도의 동태적인 업무 분야로 소프트웨어 응용 프로그램을 만드는 새로운 방법을 끊임없이 발전시키고 발명한다.
You don't have to be a super developer은 좋은 개발자입니다.
좋은 개발자는 우선 시종일관해야 하고, 그 다음은 부지런해야 한다.
상술한 방법은 주로 경험에서 나온다.내가 잘못을 저질렀으니 그것들을 적어라. 그러면 너는 그 속에서 교훈을 얻고 새로운 잘못을 저지를 수 있지만, 이런 잘못은 아니다.😁
나는 네가 이 글을 좋아하길 바란다. 평론하고 공유를 고려해 주십시오.만약 당신에게 문제가 있다면, 이곳의 평론이나 위에서 나에게 연락할 수 있습니다.