티스토리 뷰

자동이라는것은 간단하지 않다

@성훈 2019. 12. 13. 18:31

 

 

자동의 특

여러분들도 "여기랑 여기는 자동으로 설정 해버리면 되지 않을까요"와 같은 의견을 마주치는 장면은 자주 있을 것 같아요.지금까지 A와 B와 C를 설정했지만 한에 다 자동적으로 설정하고 버리는 식입니다.확실히 그때는 당연한 의견으로 들려서 "확실히 그렇구나"라고 생각됩니다.> 하지만 그때 에 걸쳐서 "여기"의 설정만으로 읽고 있는지는 좀처럼 생각하지 않는 법입니다.그 역이 함정이라고 해 입니다. 자동이라는 것은 "여기"와 같은 수동으로 복회 조작하고 있던 것을 한 번에 깨우게 하는한 조작의 생력화 기능이라고 할 수 있습니다.조작이 줄어들 뿐이지 기본적으로는 원의 (수동의) 기능이 적어서 좋다는 것이 아닙니다. 원 원 수동의 기능은 요건에서 도출된 "하고 싶은 것"일 테니까요. 예를 들면 디카로 를 찍었을 때 카메라가 섀터 스피드나 노출이나 색같은 파라메타를 자동으로 설정해 주기도 합니다.그러나 그렇다고 해서 샤타 스피드라든지 노출이라든지 하는 기능이 필요 없게 돼는 아닙니다.역시 수동으로 세세하게 설정하고 싶다는 니즈는생깁니다. 이 이상한 수동과 자동 사이의계성에서 다음의어려움이생깁니다.

자동으로 하는 모범어려움

하나는 어디까지를 자동으로 해야 하는지에 대한 판입니다. 도망치는 사람으로서 수동의 기능을 준비하고 있었다고 해도 대부분이 수동으로 조작하는 것 같지는 자동을 사포한 의미가 없습니다. 유자는 근소한 생력화에 새로운 기능, 조작을 조작할 수 있는 일은 하지 않는 것입니다.대의 용도에 있어서는 자동으로되는 것 같지 않으면 모처럼 준비해도 사용되지 않습니다. 사양적으로 그 값이 어느 정도인지를 적절히 가늠할 필요가 있다는 것입니다. 평소 릴리스 후에 거의 요망이 받아들여지지 않는한 사양의 수준이 달성출나고 있다면 특별히 어려운 이야기는 아닐 것 같습니다.그러나 릴리스 직후부터 요망이 바뀌어 도 바 존업을 피할 수 없게 되는 레벨로는 어려울지도 모릅니다.만약 디카의 경우에 자동사양을 맑을때만 잘찍을 수 있는 로릭으로 릴리스 했다면, 분명 즉시 " 흐릴때도 해주세요"라는 말을 들을것입니다.그리고 흐릴때의 를 하면 이번에는 "밤에도 해주세요" 라는 요망이 있는데 "일어디까지 해야 다리를 얻을수 있나..."라는 이야기가 되어 갑니다.이것은 처음에 맑을 때 밖에을 하지 않았기 때문에 유자가 "사용할 수 없다"라고 생각해 버렸기 때문입니다. 책는 처음부터 정확도는 별도로 하고 사의 범으로서는 맑음에서도 흐림에도 찍을 수 있게 되어있어야 했습니다.

만들기의 어려움

또 하나는 만들기의 어려움입니다. 지금 말해온 것처럼 만들면서 수동있는 방식으로 자동을 생각한다면 좋겠지만, 그게 아니라 눈앞의 자동화에 사로잡혀 기능을 만들어 버리면 후한 어려움에 빠집니다.예를 들어 요망의 가 대이 된다든지, 수동의 기능과의 부정합이 발생하여 "자동적으로 밖에 나오지 않는 기능" 이 나타나거나 합니다. 한가지 예를 들겠습니다. Excel에서 셀에 데이타를 입력하면 카솔이 아래로 갑니다.특별히 자동과 상관없다고 생각할지도 모르지만 그렇지는 않습니다.이것은 Excel이 데이타 입력 후에 "자동"으로 카솔을 이동시키고 있다고 생각됩니다.그것이 에 옵션으로 입력 후의 카솔의 이동은 설정할 수 있고, 이동시키지 않는다는 것도 나옵니다.

 

 

이기 때문에 데이터 입력과 카솔 이동은 기능으로는 서있고, 그것을 자동으로 맞춰서 하고 있다고 생각됩니다. 물론 안에 있는 작물이 보여 아니면 아니니까 어디까지나 추측입니다.다만 여기서는 그 옳음이 문제가 아니므로 그 정으로 이야기를 진행하겠습니다. 즉 처음에 이 옵션 설정 없이 자동 내놓아 입력 후에 모기솔을 아래로 이동한다는 준비라고 한(한 기능을 고정적으로 만들어그리고 버렸더라면 그 뒤은 어떻게 될까요라는 말입니다. 만약 처음에 그렇게 만들어그리고 있으면 다음에는 "모기솔을 오른쪽으로 움직이고 싶은 파타 맨체스터도 있대"다는 말이 되고, 또한 다음에는 "아니 원래 카마솔을 움직이지 않는 파타빚도 있대"라는 말이 됩니다.그때마다 "입력 후에 아래"라는 고정적인 코드를 수정해서 어떻게 해나가게 될까 그래서 점점 코드가 더러워져 갑니다, 책 은 층이 헤어져 있고 아래 기본적인 층에 데 타 입력과 카 솔 이동이 있어서 그 상위층에 "데 타 입력 + 카 솔 이동"이라는 자동 기능이 있어야 합니다.

 

 

자동은 어디까지나 사용하기 편리한 기능일뿐더러 UI적인 기능일뿐입니다. 그래서 "시스템의 추천"에서 조금 밝혀에 UI부분이 아니라 책부분의 기능이야말로 책의 기능으로서 사포해야 하는 것입니다.즉, 책의 기능은 아래층의 기본적인 데이터 입력과 카솔 이동이라는 것이 됩니다. 이것은 설계의 범용성 이야기와 가까운 것이 있습니다.설계에 있어서 범용성이란"입력 후 가솔 하"라고 할까용 기능으로 만들어 버리는 것이 아니라 보다 범용적인 데타 입력과 가솔 이동으로 분리해서 만들 필요가 있다는 것입니다.'이기 때문에 "설계에 있어서 범용성이란"에서 말한 것과 같은 어려움이 뒤따라요.
그 밖의 예
비슷한 이야기는 도처에서 찾을 수 있습니다. 예를 들어 Windows에 디폴트로 들어 있다, 상을 표시하는 포토뷰어라는 소프트웨어가 있습니다.

 

이것은 매우 심플하고 카우 솔의 좌우에서 디렉토리 위의 화상 파일을 앞, 다음과 바꿔서 표시만 하는 것입니다.그 외의 기능으로는 슬라이드 쇼가 있습니다.이 슬라이드 쇼 등도 자동으로 볼 수 있습니다.왜냐하면 슬라이드 쇼는 "전면+상전환"이기 때문입니다.이 기능을 적절히 설계한다면, Excel 때와 마찬가지로 기본적인 기능과 자동과의 두 층으로 나누어져 있으며, 하위의 기본적인 기능에는 면 사이즈로 하는 블록과 상 전환 블록이 있는 것 같은 형태가 될 것으로 생각됩니다.

 

 

만약 이 에 설계되었다면, 향후 "전면+수동으로 상전환" 같은 사양을 추가하려고 한 경우도 무리없이 출하게 됩니다.(현재는 자동으로 상이 바뀌는 사양밖에 없습니다)

자동으로하는 법

결국 자동 함정이라는 것은 이하의 이매 지에 집약할 수 있을지도 모릅니다.

 

 

위쪽 에 자동만의 기능으로 만들어 버리면 뒤 다른 하고싶은 일이 나와서 하기 힘들어집니다.아래쪽에 기본적인 기능을 정리해서 그것들을 쌓아올린 위에 자동을 구현해야 비로소 도 편안해집니다.그의 파워는 사탕에서 준에 이매지한 견적보다는만큼 많이 소요됩니다.그 차이는 이대로 위는 막대기를 세울 만한 양으로하고 아래는 산을 쌓을래에야도 포함한 양이 됩니다. 이번에 밝힌 예는 다른 사랑도 없는 것이므로 물론 이렇게 거창한 논의는 필요없지만, 자동이라는 것에는 규모에 어긋나지 않고 항상 이런 주의점이 있다는 것입니다.예를 들면 요즘은 흔히 자동차 자동운의 화제가 뉴스가 되는데 그런 것이라도 마찬가지입니다.수동 위에 자동을 쌓을 필요가 있습니다.뉴스를 보면 각사는 완전 자동운 즉 인간이 일절 운을 하지 않아도 된다는 자동운을 지향하고 있는 것 같은데, 아마도 "인간이 운 안 한다"는 것은 "인간은 운 못 한다"는 말이 아닐 것입니다.만약 그게 아니라 인간이 운하는 기능이 사포토 되지 않는 거라면 그건 무모하다고 해도 될 정도로 하달러가 비싼 걸로 보입니다.비행기에든 배로든 자동운은요에 나타나있는데 수동으로 운이 안된다는 얘기는 들어본적이 없습니다.디카 모두 디카 동 자동으로 할 수 없는 사태가 되면 인간이 수동으로 조작합니다.수동을 제공하지 않고 모든 것을 자동으로한다는 것은 지극히 큰 일입니다.
댓글