PurchaseOrderForm 기본 로직 생성

[jieseob1]

No description provided.

[github-actions]

코드에 대한 간단한 리뷰는 다음과 같습니다:

1. 디버그 메시지:

   console.log("hihi mainroutes")

   • 디버그 목적으로 사용된 콘솔 로그는 배포 전에 제거하는 것이 좋습니다.

2. 경로 정리:

   • 파일 경로와 컴포넌트 경로가 혼용되어 있습니다.

   import PurchaseOrderForm from '@/components/PurchaseOrderForm';

   • 다른 임포트 문과 일관성을 유지하기 위해 상대 경로(../components/PurchaseOrderForm)를 사용하는 것이 나을 수 있습니다.

3. 라우팅 추가 검토:

   • 새로운 라우트 "/create-purchase-order"가 추가되었습니다. 이 경로가 실제 프로젝트 요구사항에 맞는지 확인할 필요가 있습니다.

4. 기타:

   • 전체적인 코드 구조는 크게 문제 없어 보입니다.

요약

• 불필요한 콘솔 로그 제거
• 임포트 경로 통일
• 신규 라우트 경로 점검

이러한 변경 사항을 반영하면 코드가 좀 더 깨끗하고 유지보수에 용이할 것입니다.

[github-actions]

코드 패치의 코드 리뷰를 다음과 같이 진행하겠습니다:

버그 위험:

1. createPurchaseOrder 함수에서 handleApiCall 함수가 반환값을 제대로 기다리지 않습니다. await 키워드를 추가해야 합니다.

   export const createPurchaseOrder = async (purchaseOrder: PurchaseOrder) => {
     await handleApiCall(api.post('/purchase-orders', purchaseOrder));
   };

개선 사항:

1. 통일된 경로 사용:

   • 다른 import 경로와 통일성을 유지하기 위해 ../types/receipt 대신에 @/types/receipt를 사용하는 것이 좋습니다.

2. 불필요한 await 제거:

   • getAllItems 함수에서 await는 필요 없습니다; handleApiCall 자체가 반환값을 Promise로 처리합니다.

   export const getAllItems = async (): Promise<Item[]> => {
     return handleApiCall(api.get('/items'));
   };

3. 파일 끝에 개행 문자 추가:

   • POSIX 표준을 따르기 위해 파일 끝에 개행 문자를 추가하는 것을 권장합니다.

수정된 코드 예시:

import { ExpectedReceipt } from "@/types/expectedReceipt";
import { PurchaseOrder } from "@/types/purchaseOrder";
import { Receipt } from "@/types/receipt";
import { Supplier } from "@/types/supplier";
import axios from "axios";
import { Item } from "@/types/item";

const api = axios.create({
  baseURL: process.env.BASE_URL || 'http://localhost:8080/api'
});

export const getReceipts = async (): Promise<Receipt[]> => {
  return handleApiCall(api.get<Receipt[]>('/receipts'));
};

// purchase order

export const createPurchaseOrder = async (purchaseOrder: PurchaseOrder) => {
  await handleApiCall(api.post('/purchase-orders', purchaseOrder));
};

export const getAllSuppliers = async (): Promise<Supplier[]> => {
  return handleApiCall(api.get<Supplier[]>('/suppliers'));
};

export const getAllItems = async (): Promise<Item[]> => {
  return handleApiCall(api.get('/items'));
};

export default api;

위 수정사항들을 반영하면 코드 안정성과 일관성이 향상될 것입니다.

[github-actions]

이 코드 패치에 대한 간단한 코드 리뷰는 다음과 같습니다:

버그 리스크:

1. 가격 데이터 타입: price가 string으로 지정되어 있습니다. 가격은 숫자형 데이터로 처리하는 것이 좋습니다. 예를 들어 계산이 필요한 경우 문자열로 설정하면 오류가 발생할 수 있습니다.

개선 사항:

1. 타입 변경: price의 데이터 타입을 number로 변경하는 것을 권장합니다.

   price: number;

2. POSIX 규격에 맞춘 파일 종료: 파일 끝에 새 줄 추가를 추천합니다. POSIX 표준에서는 파일이 새 줄로 끝나야 합니다.

3. 추가 주석 제거: 불필요한 주석 (// inventories: Inventory[];)은 정리해서 필요하지 않은 코드나 주석을 제거하는 것이 좋습니다.

개선된 코드는 다음과 같습니다:

export interface Item {
  id: number;
  name: string;
  specification: string;
  unit: string;
  category: string;
  barcode: string;
  image: string;
  price: number; // 가격을 숫자로 변경
  stockAlertLevel?: number;
}

위와 같은 수정 사항을 적용하면 코드의 가독성과 유지보수성이 크게 향상될 것입니다.

[github-actions]

여기에 대한 코드 리뷰는 다음과 같습니다:

1. 타입 안정성 및 데이터 일관성:

   • orderDate와 dueDate를 Date 타입으로 변경한 것은 긍정적입니다. 이는 날짜와 관련된 작업을 더 쉽고 안전하게 처리할 수 있게 합니다.

2. 옵셔널 속성 처리:

   • items와 supplier가 모두 옵셔널(?)로 지정되어 있습니다. 이를 사용할 때 해당 값이 존재하지 않을 가능성을 항상 염두에 두고 처리해야 합니다. 이를 위해 기본값을 설정하거나 null 체크 등을 고려하면 좋습니다.

3. 상태 관리:

   • status의 타입이 string으로 되어 있는데, 가능한 상태값들을 제한하는 Enum을 사용하여 잘못된 상태값 입력을 방지할 수 있습니다. 예를 들어:

     export enum OrderStatus {
       Pending = "Pending",
       Shipped = "Shipped",
       Delivered = "Delivered",
       Canceled = "Canceled"
     }

4. 신규 줄 추가 여부:

   • 파일의 마지막에 \ No newline at end of file이라고 나와 있듯이, 파일의 마지막에 새 줄을 추가하는 것이 좋습니다. 이는 일부 도구에서 파일 끝의 줄바꿈 유무로 문제를 일으킬 수 있기 때문입니다.

5. 댓글 명확성:

   • 주석(//)은 도움이 되지만, 더 명확하게 하거나 필요 없는 부분은 제거해도 됩니다. 특히 주석 중복이나 한글로만 설명된 부분을 영어로 병기할 수 있습니다.

수정된 버전의 제안:

import { PurchaseOrderItem } from "./purchaseOrderItem";
import { Supplier } from "./supplier";

export enum OrderStatus {
  Pending = "Pending",
  Shipped = "Shipped",
  Delivered = "Delivered",
  Canceled = "Canceled"
}

export interface PurchaseOrder {
  orderNumber: string;
  orderDate: Date; // Changed from LocalDate to Date type
  dueDate: Date; // Changed from LocalDate to Date type
  status: OrderStatus; // Restrict status values using Enum
  items?: PurchaseOrderItem[]; // One purchase order can have multiple items
  supplier?: Supplier; // Multiple purchase orders can be issued to one supplier
}

• 또한 파일 끝에 반드시 새 줄을 추가하세요.

[github-actions]

코드 패치에 대한 리뷰를 아래와 같이 진행하겠습니다:

버그 리스크:

1. 타입 명확성: productCode는 일반적으로 문자열로 표현되는 경우가 많습니다. 타입을 확인해서 필요 시 string으로 변경하는 것이 좋습니다.

   productCode: string;

개선 제안:

1. 끝에 줄바꿈 추가: 이 파일은 끝에 줄바꿈이 없습니다. 파일 끝에 줄바꿈을 추가하는 것이 일반적인 컨벤션입니다.

   +}
   +```

2. 타입 안전성 강화: 워크플로우에서 예상되는 오류를 감소시키기 위해 모든 필드를 선택 사항으로 하는 대신, 반드시 필요한 항목들을 명시합니다.

수정된 코드 예시는 다음과 같습니다:

import { Item } from "./item";
import { PurchaseOrder } from "./purchaseOrder";

export interface PurchaseOrderItem {
  id: number;
  productCode: string; // 타입 재확인 후 업데이트
  quantity: number;
  unitPrice: number;
  purchaseOrder: PurchaseOrder;
  item: Item;
}

이상의 사항들을 고려해 수정하면 더 나은 코드 품질을 유지할 수 있습니다.

[github-actions]

1. 주소 타입:

   • address 필드의 타입이 String으로 되어 있는데, 일반적으로 소문자 string을 사용합니다.

   address: string;

2. 열거형 사용:

   • 'supplierType'의 주석에 따라 enum 타입으로 변경할 수 있습니다.

   export enum SupplierType {
       Manufacturer,
       Distributor,
       Wholesaler,
       Retailer
   }
   
   supplierType: SupplierType;

3. 끝 라인 개행:

   • 파일 끝에 줄 바꿈이 없습니다. POSIX 표준에 따르면, 파일 끝에 개행 문자가 있어야 합니다.

4. 타입 안정성 및 명확성:

   • PurchaseOrder[] 대신 ReadonlyArray 같은 것을 사용할 수도 있습니다.

   purchaseOrder: ReadonlyArray<PurchaseOrder>;

위와 같이 수정하면 가독성과 유지보수성이 향상될 것입니다.