이 문서에서는 Java 개발자가 알아야 할 상위 10가지 계명에 대해 설명합니다. 참고할 수 있도록 모든 사람과 공유하세요. 세부정보는 다음과 같습니다.
Java 개발자로서 자신의 코드의 품질과 유지 관리성을 향상시키는 것은 끊임없는 주제입니다. 이 기사를 온라인에서 보고 이를 활용하여 스스로를 격려했습니다.
Java 개발자를 위한 많은 표준과 모범 사례가 있습니다. 이 문서에는 모든 개발자가 따라야 하는 10가지 기본 규칙이 나열되어 있습니다. 따를 수 있지만 따르지 않는 규칙이 있다면 매우 비극적인 결말로 이어질 것입니다.
1. 코드에 주석 추가
모두가 이것을 알고 있지만 왠지 그것을 따르는 것을 잊어버립니다. 주석을 추가하는 것을 "잊은" 적이 몇 번이나 있었나요? 사실입니다. 주석은 프로그램 기능에 실질적인 기여를 하지 않습니다. 하지만 2주 전에 작성한 코드를 계속해서, 어쩌면 평생 동안 다시 확인해야 하며, 코드가 왜 이렇게 동작하는지 기억하지 말아야 합니다. 이 코드가 귀하의 것이라면 비교적 운이 좋은 것입니다. 추억을 되살릴 수도 있기 때문이다. 그러나 안타깝게도 코드가 다른 사람의 것인 경우가 많으므로 그 사람이 회사를 떠날 가능성이 높습니다.
2. 일을 복잡하게 만들지 마세요
나도 전에 해본 적이 있고, 모두가 해봤을 것이라고 확신합니다. 개발자는 종종 간단한 문제에 대한 해결책을 생각해냅니다. 우리는 사용자가 5명뿐인 애플리케이션을 위해 EJB를 도입했습니다. 우리는 필요하지도 않은 애플리케이션을 위해 프레임워크를 사용합니다. 속성 파일, 객체 지향 솔루션 및 스레드를 애플리케이션에 추가했지만 전혀 필요하지 않았습니다. 우리는 왜 이런 일을 하는가? 우리 중 일부는 더 나은 방법을 모르기 때문에 그렇게 하지만, 일부는 새로운 지식을 배우고 응용 프로그램을 더 흥미롭게 만들기 위해 그렇게 합니다.
3． 기억하세요. “적을수록 좋다”는 것이 항상 좋은 것은 아닙니다.
코드 효율성은 좋은 일이지만, 많은 경우 코드 줄을 적게 작성한다고 해서 코드 효율성이 높아지는 것은 아닙니다. 간단한 예를 보여드리겠습니다.
if(newStatusCode.equals("SD") && (sellOffDate == null || todayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null && todayDate.compareTo(lastUsedDate)>0)) || (newStatusCode.equals ("OBS") && (OBSDate == null || todayDate.compareTo(OBSDate)<0))){ newStatusCode = "NYP";} 묻고 싶습니다. 위 코드의 if 조건이 무엇을 원하는지 쉽게 알 수 있습니까? 이제 이 코드를 작성한 사람이 첫 번째 규칙을 따르지 않았다고 가정해 보겠습니다. 코드에 주석을 추가하세요.
이 조건을 두 개의 별도 if 문으로 나누면 더 간단하지 않을까요? 이제 다음 수정된 코드를 고려해보세요.
if(newStatusCode.equals("SD") && (sellOffDate == null || todayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null && todayDate.compareTo(lastUsedDate)>0))){ newStatusCode = "NYP ";}else if(newStatusCode.equals("OBS") && (OBSDate == null || todayDate.compareTo(OBSDate)<0)){ newStatusCode = "NYP";}가독성이 더 좋지 않을까요? 예, 진술 조건을 반복했습니다. 예, 추가 "IF"와 두 개의 추가 괄호 쌍이 있습니다. 그러나 코드는 더 읽기 쉽고 이해하기 쉽습니다.
4. 하드 코드를 사용하지 마세요.
개발자들은 평소처럼 서두르기 때문에 의식적으로 이 규칙을 잊어버리거나 무시하는 경우가 많습니다. 이 규칙을 따르면 일정이 늦어질 수 있습니다. 우리는 현재 상태를 끝내지 못할 수도 있습니다. 하지만 정적 상수를 정의하는 추가 코드 줄을 작성하는 데 얼마나 많은 시간이 소요됩니까?
여기에 예가 있습니다.
공개 클래스 A { 공개 정적 최종 문자열 S_CONSTANT_ABC = "ABC"; 공개 부울 메소드A(String sParam1){ if(A.S_CONSTANT_ABC.equalsIgnoreCase(sParam1)){ return true } return false;이제 문자열 "ABC"를 일부 변수와 비교할 때마다 실제 코드가 무엇인지 기억하는 대신 S_CONSTANT_ABC만 참조하면 됩니다. 또한 모든 코드에서 상수를 찾는 대신 한 곳에서 상수를 더 쉽게 수정할 수 있다는 이점도 있습니다.
5. 자신만의 프레임워크를 만들지 마세요
수천 개의 프레임워크가 출시되었으며 대부분이 오픈 소스입니다. 이러한 프레임워크 중 다수는 탁월한 솔루션이며 수천 개의 애플리케이션에서 사용됩니다. 적어도 표면적으로는 이러한 새로운 프레임워크를 따라잡아야 합니다. 이러한 우수하고 널리 사용되는 프레임워크 중에서 가장 훌륭하고 직접적인 예 중 하나는 Struts입니다. 상상할 수 있는 모든 프레임워크 중에서 이 오픈 소스 웹 프레임워크는 웹 기반 애플리케이션을 위한 완벽한 후보입니다. 하지만 두 번째 규칙을 기억해야 합니다. 일을 복잡하게 만들지 마세요. 단 3개의 페이지로 애플리케이션을 개발하는 경우에는 Struts를 사용하지 마십시오. 이러한 애플리케이션에는 요청을 "제어"할 수 있는 방법이 없습니다.
6. 줄을 인쇄하고 문자열을 추가하지 마세요
나는 디버깅 목적을 위해 개발자들이 적합하다고 판단되는 모든 곳에 System.out.println을 추가하기를 원한다는 것을 알고 있으며 우리는 나중에 이 코드를 삭제할 것이라고 스스로에게 말합니다. 그러나 우리는 종종 이러한 코드 줄을 삭제하는 것을 잊어버리거나 단순히 삭제하고 싶지 않습니다. 테스트를 완료한 후에도 System.out.println을 사용하여 계속 액세스할 수 있는 이유는 무엇입니까? System.out.println으로 인한 피해를 과소평가했기 때문에 실제로 필요한 코드 줄을 삭제할 수 있습니다. 다음 코드를 고려해 보세요.
공개 클래스 BadCode { 공개 정적 무효 계산WithPrint(){ double someValue = 0D; for (int i = 0; i < 10000; i++) { System.out.println(someValue = someValue + i) } } 공개 정적 무효 계산WithOutPrint( ){ double someValue = 0D; for (int i = 0; i < 10000; i++) { someValue = someValue + i; } } public static void main(String [] n) { BadCode.calculationWithOutPrint();아래 표에서는 계산WithOutPrint() 메서드를 실행하는 데 0.001204초가 걸린 것을 확인할 수 있습니다. 이에 비해 CalculationWithPrint() 메서드를 실행하는 데는 무려 10.52초가 걸렸습니다.
(이와 같은 테이블을 얻는 방법을 모르는 경우 내 기사 "WSAD를 사용한 Java 프로파일링" WSAD를 사용한 Java 프로파일링을 참조하세요.)
이러한 CPU 낭비를 피하는 가장 좋은 방법은 다음과 같은 래퍼 메서드를 도입하는 것입니다.
공용 클래스 BadCode { 공용 정적 최종 int DEBUG_MODE = 1; 공용 정적 void 계산(int logMode){ double someValue = 0D for(int i = 0; i < 10000; i++) someValue + i; myPrintMethod(logMode, someValue) } } 공개 정적 무효 myPrintMethod(int logMode, double value) { if (logMode > BadCode.DEBUG_MODE) { return; } System.out.println(value) } public static void main(String [] n) { BadCode.calculationWithPrint(BadCode.PRODUCTION_MODE) ; }}아래 그림에서 StringBuffer를 사용한 메소드는 실행하는데 0.01초밖에 걸리지 않은 반면, 문자열 추가를 사용한 메소드는 실행하는데 0.08초가 걸린 것을 알 수 있습니다. 선택은 분명합니다.
7． GUI를 따르세요
아무리 우스꽝스럽게 들리더라도 저는 계속해서 말씀드리고 싶습니다. GUI는 비즈니스 고객에게 기능과 성능만큼 중요합니다. GUI는 성공적인 시스템의 필수적인 부분입니다. (그러나) IT 잡지에서는 GUI의 중요성을 간과하는 경향이 있습니다. 많은 조직에서는 "사용자 친화적인" GUI 설계에 대한 광범위한 경험을 가진 디자이너를 고용하지 않음으로써 비용을 절약합니다. Java 개발자는 HTML에 대한 자신의 지식에 의존해야 하지만 이 분야에 대한 지식은 매우 제한되어 있습니다. 저는 이와 같은 앱을 많이 보았습니다. 이 앱은 "사용자 친화적"이 아니라 "컴퓨터 친화적"입니다. 소프트웨어 개발과 GUI 개발 모두에 능숙한 개발자는 거의 볼 수 없습니다. 당신이 사용자 인터페이스 개발을 맡은 불운한 개발자라면 다음 세 가지 원칙을 따라야 합니다.
1. 바퀴를 재발명하지 마세요. 유사한 사용자 인터페이스 요구 사항을 가진 기존 시스템을 찾으십시오.
2. 먼저 프로토타입을 만듭니다. 이것은 매우 중요한 단계입니다. 고객은 자신이 무엇을 얻게 될지 보고 싶어합니다. 또한 전력을 다하기 전에 피드백을 받고 그들을 화나게 할 사용자 인터페이스를 만들기 때문에 당신에게도 좋습니다.
3. 사용자의 모자를 착용합니다. 즉, 사용자 관점에서 애플리케이션의 요구사항을 검토합니다. 예를 들어 요약 페이지의 페이지를 매겨야 하는지 여부입니다. 소프트웨어 개발자는 개발 복잡성이 줄어들기 때문에 시스템의 페이지 매김을 무시하는 경향이 있습니다. 그러나 요약된 데이터에는 수백 또는 수천 개의 행이 있으므로 이는 사용자 관점에서 볼 때 최선의 솔루션은 아닙니다.
8. 항상 문서화된 요구사항을 준비하세요.
모든 비즈니스 요구사항은 문서화되어야 합니다. 일부 동화에서는 그럴 수도 있지만 현실 세계에서는 불가능합니다. 개발 시간이 얼마나 빡빡하든, 배송 날짜가 곧 다가오든 상관없이 모든 비즈니스 요구 사항이 문서화되어 있다는 사실을 항상 알아야 합니다.
9. 단위 테스트, 단위 테스트, 단위 테스트
코드를 단위 테스트하는 가장 좋은 방법이 무엇인지 자세히 설명하지는 않겠습니다. 제가 말하려는 것은 단위 테스트가 이루어져야 한다는 것입니다. 이것이 프로그래밍의 가장 기본적인 규칙이다. 이것은 무시할 수 없는 위의 모든 법칙 중에서 가장 중요합니다. 코드에 대한 단위 테스트를 만들고 테스트할 수 있는 동료가 있다면 가장 좋습니다. 하지만 아무도 대신해 주지 않는다면 스스로 해야 합니다. 단위 테스트 계획을 세울 때 다음 규칙을 따르십시오.
1. 코드를 작성하기 전에 단위 테스트를 작성하세요.
2. 단위 테스트에 주석을 작성합니다.
3. "흥미로운" 기능을 수행하는 모든 공용 메소드를 테스트하십시오. ("흥미로운"이란 특별한 방법으로 set 및 get 메소드를 수행하지 않는 한 setter 또는 getter가 아닌 메소드를 의미합니다.)
10． 기억하세요 - 양이 아니라 품질입니다.
사무실에 너무 늦게 머물지 마십시오(꼭 그럴 필요가 없을 때). 때로는 제품 문제, 촉박한 마감 기한, 예상치 못한 사건으로 인해 정시에 퇴근하지 못할 수도 있다는 점을 이해합니다. 그러나 정상적인 상황에서 관리자는 너무 늦게 퇴근하는 직원에게 감사하거나 보상하지 않습니다. 그는 그들이 생산하는 제품의 품질 때문에 감사합니다. 위에서 제시한 규칙을 따르면 코드에 버그가 적고 유지 관리가 더 용이하다는 것을 알 수 있습니다. 그리고 그것은 당신의 직업에서 가장 중요한 부분입니다.
요약
이 기사에서는 Java 개발자를 위한 10가지 중요한 규칙을 제시합니다. 이러한 규칙을 아는 것뿐만 아니라 코딩 과정에서 이를 따르는 것도 중요합니다. 이 규칙이 우리가 더 나은 프로그래머와 전문가가 되는 데 도움이 되기를 바랍니다.
이 글이 Java 프로그래밍에 종사하는 모든 분들께 도움이 되기를 바랍니다.