должен хоть примерно понимать что где. В том, что код может часто отличаться от спецификации, в том, что ты можешь прийти новый на проект. Начинается увлекательная игра когда кож доказывает что там как в спецификации, а у тебя не фига ни так. В том что и абапер может быть относительно новеньким. А какой смысл писать хитровывернутый код, который кроме тебя и к5 никто не понимает? Обосновать свою необходимость на проекте? Была картинка про троллейбус из хлеба, мне кажется она сюда применима.
принцип KISS никто не отменял. но повторюсь, конс не должен понимать конструкции языка. только результаты его выполнения и общую структуру ПО. и то отчасти. А вот понятность кода для абаперов фильтруется на уровне кодревью. Либо ревьюверу все понятно, либо возникает спор - тогда привлекается третий человек для его разрешения
Я снова и снова сталкиваюсь с тем, что люди стараются использовать технические инструменты для решения социальных и коммуникативных задач Давайте разложу по полочкам - конс не должен лезть в код. У него не должно быть на это причин. Есть тз, есть фидбек, есть движение информации вверх и вниз, а главное - есть приемочное тестирование. Если приемка прошла - значит ок. Если возникли потом вопросы - не надо тратить свое время на анализ непонятного кода, не надо тратить время программиста на анализ сложных процессов - сядьте вместе и за 5 минут разберитесь - программист не обязан знать процессы на уровне конса. Конечно, знать домен обязательно, но не более того. Не нужно знать всех шагов и всех требований к данным, которые нужны в процессе. Сядьте с консом и разберитесь за 5 минут - молодой абапер, молодой конс - для этого есть старшие коллеги, архитекторы, тим/тех лиды и т.п. Кроме того, код сам по себе не обязан быть таким или сяким. Да, хорошо, когда код в команде объединен общими подходами, чтобы любому члену команды было легко его читать и изменять, но уж точно не консу - вопрос о том, что в спецификации так, а разраб сделал не так, и все такое - решается построением высокоуровневой архитектуры до того, как отдавать на реализацию людям с небольшим опытом Прописать интерфейсы (условно) и требования к приемке - и тут уж как ни пиши, а что надо сделаешь. А в большинстве случаев требования худо-бедно описаны, а расписать приемку лень, и сидишь над этим ТЗ и думаешь, "а что автор хотел сказать?"
Обсуждают сегодня