169 похожих чатов

Смысл в том, что чтобы описать доработку крупного приложения, Конс

должен хоть примерно понимать что где. В том, что код может часто отличаться от спецификации, в том, что ты можешь прийти новый на проект. Начинается увлекательная игра когда кож доказывает что там как в спецификации, а у тебя не фига ни так. В том что и абапер может быть относительно новеньким. А какой смысл писать хитровывернутый код, который кроме тебя и к5 никто не понимает? Обосновать свою необходимость на проекте? Была картинка про троллейбус из хлеба, мне кажется она сюда применима.

2 ответов

15 просмотров

принцип KISS никто не отменял. но повторюсь, конс не должен понимать конструкции языка. только результаты его выполнения и общую структуру ПО. и то отчасти. А вот понятность кода для абаперов фильтруется на уровне кодревью. Либо ревьюверу все понятно, либо возникает спор - тогда привлекается третий человек для его разрешения

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

Похожие вопросы

Обсуждают сегодня

Господа, а что сейчас вообще с рынком труда на делфи происходит? Какова ситуация?
Rꙮman Yankꙮvsky
29
А вообще, что может смущать в самой Julia - бы сказал, что нет единого стандартного подхода по многим моментам, поэтому многое выглядит как "хаки" и произвол. Короче говоря, с...
Viktor G.
2
30500 за редактор? )
Владимир
47
а через ESC-код ?
Alexey Kulakov
29
Чёт не понял, я ж правильной функцией воспользовался чтобы вывести отладочную информацию? но что-то она не ловится
notme
18
У меня есть функция где происходит это: write_bit(buffer, 1); write_bit(buffer, 0); write_bit(buffer, 1); write_bit(buffer, 1); write_bit(buffer, 1); w...
~
14
Добрый день! Скажите пожалуйста, а какие программы вы бы рекомендовали написать для того, чтобы научиться управлять памятью? Можно написать динамический массив, можно связный ...
Филипп
7
Недавно Google Project Zero нашёл багу в SQLite с помощью LLM, о чём достаточно было шумно в определённых интернетах, которые сопровождались рассказами, что скоро всех "ибешни...
Alex Sherbakov
5
Ребят в СИ можно реализовать ООП?
Николай
33
https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_h_common.erl#L174 https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_olp.erl#L76 15 лет назад...
Maksim Lapshin
20
Карта сайта