저는 Babel ES6로 코딩하는 선임 개발자입니다. 우리 앱의 일부는 API 호출을 만들고 API 호출에서 가져온 데이터 모델을 기반으로 특정 양식을 작성해야합니다.
이러한 양식은 이중 연결 목록에 저장됩니다 (백엔드에서 일부 데이터가 유효하지 않다고 표시하는 경우 사용자가 엉망인 한 페이지로 신속하게 돌아온 다음 대상을 다시 수정하면됩니다. 명부.)
어쨌든 페이지를 추가하는 데 사용되는 많은 기능이 있으며, 내가 너무 영리한지 궁금합니다. 이것은 기본적인 개요 일뿐입니다. 실제 알고리즘은 페이지와 페이지 유형이 다양하기 때문에 훨씬 더 복잡하지만 이에 대한 예를 제공합니다.
이것이 초보자 프로그래머가 처리하는 방법이라고 생각합니다.
export const addPages = (apiData) => {
let pagesList = new PagesList();
if(apiData.pages.foo){
pagesList.add('foo', apiData.pages.foo){
}
if (apiData.pages.arrayOfBars){
let bars = apiData.pages.arrayOfBars;
bars.forEach((bar) => {
pagesList.add(bar.name, bar.data);
})
}
if (apiData.pages.customBazes) {
let bazes = apiData.pages.customBazes;
bazes.forEach((baz) => {
pagesList.add(customBazParser(baz));
})
}
return pagesList;
}더 테스트하기 위해 모든 if 문을 가져 와서 분리하고 독립형 함수로 만든 다음 그 위에 매핑합니다.
이제 테스트 가능한 것이 한 가지이지만 읽을 수 있으므로 여기서 읽을 수없는 부분이 있는지 궁금합니다.
// file: '../util/functor.js'
export const Identity = (x) => ({
value: x,
map: (f) => Identity(f(x)),
})
// file 'addPages.js'
import { Identity } from '../util/functor';
export const parseFoo = (data) => (list) => {
list.add('foo', data);
}
export const parseBar = (data) => (list) => {
data.forEach((bar) => {
list.add(bar.name, bar.data)
});
return list;
}
export const parseBaz = (data) => (list) => {
data.forEach((baz) => {
list.add(customBazParser(baz));
})
return list;
}
export const addPages = (apiData) => {
let pagesList = new PagesList();
let { foo, arrayOfBars: bars, customBazes: bazes } = apiData.pages;
let pages = Identity(pagesList);
return pages.map(foo ? parseFoo(foo) : x => x)
.map(bars ? parseBar(bars) : x => x)
.map(bazes ? parseBaz(bazes) : x => x)
.value
}여기 내 관심사가 있습니다. 에 나 바닥이 더 조직이다. 코드 자체는 작은 테스트 단위로 분리되어 테스트 할 수 있습니다. 그러나 나는 생각하고있다 : 나는 신원 펑터, 카레 또는 삼진 진술을 사용하는 것과 같은 개념에 익숙하지 않은 주니어 개발자로서 그것을 읽어야한다면 후자의 해결책이 무엇을하는지 이해할 수 있을까? 때때로 "잘못되고 쉬운"방법을 사용하는 것이 더 낫습니까?
OMG-1999 년부터 업계에서 활동했으며 1983 년부터 코딩을 해왔으며 가장 해로운 개발자입니다. "영리한"이라고 생각하는 것은 실제로 "비싸고", "유지하기 어렵다"및 "버그의 원인"이라고하며 비즈니스 환경에는 존재하지 않습니다. 첫 번째 예는 간단하고 이해하기 쉬우 며 작동 하는 반면 두 번째 예는 복잡하고 이해하기 어렵고 아마도 정확하지 않습니다. 이런 종류의 일을 중단하십시오. 실제 세계에 적용되지 않는 학문적 의미를 제외하고는 더 좋지 않습니다.
—
user1068
브라이언 커닝 한 (Brian Kerninghan)은 다음과 같이 인용하고 싶습니다. "처음에는 프로그램을 작성하는 것보다 디버깅이 두 배나 어렵다는 것을 알고 있습니다. " - en.wikiquote.org/wiki/Brian_Kernighan , 제 2 판, 2 장 / "프로그래밍 스타일의 요소"
—
MarkusSchaber
@Logister Coolness는 단순성 이상의 주요 목표가 아닙니다. 여기서 반대 의견은 무의미한 복잡성에 관한 것으로, 이는 코드가 추론하기 어렵고 예상치 못한 코너 케이스를 포함 할 가능성이 높기 때문에 정확성의 적입니다 (확실히 주요 관심사). 실제로 테스트하기가 더 쉽다는 주장에 대한 회의론을 감안할 때, 나는이 스타일에 대해 설득력있는 주장을 보지 못했습니다. 최소 권한 wrt 보안 규칙과 유사하게 간단한 언어 기능을 사용하여 간단한 작업을 수행하는 것에주의해야한다는 경험 법칙이있을 수 있습니다.
—
sdenham
코드는 주니어 코드처럼 보입니다. 나는 선배가 첫 번째 예를 쓸 것으로 기대합니다.
—
sed
Babel ES6