Re[5]: Может ли хороший программист, пройти фильтр плохого,
От: mgu  
Дата: 21.07.21 13:18
Оценка: :)
Здравствуйте, B0FEE664, Вы писали:

vsb>>Для тех, кто его будет читать и модифицировать в будущем.

BFE>Так. Где мой хрустальный магический шар предсказаний?

Не натёрли ещё. Путь к шару долгий и начинается с написания развесистого блока catch.

vsb>>Планка зависит от минимальной квалификации допускаемого к этому коду программиста конкретной компании. Там, где я был, эта планка на уровне начинающего разработчика, знающего основные конструкции языка.

BFE>Вы понимаете, что с какой планкой в компании будут работать только начинающие программисты?

В многоклеточной компании существует разделение труда.

vsb>>В NASA, наверное, эта планка на уровне доктора наук.

BFE>Смешно мне с такого.

А мне грустно: проскакивала информация, что в Гугле яйцеголовых бросают на цензурирование высказываний в Ютубе.
Re[5]: Может ли хороший программист, пройти фильтр плохого,
От: mgu  
Дата: 21.07.21 13:20
Оценка:
Здравствуйте, B0FEE664, Вы писали:

N>>>А о неуместных абстракциях, бесполезных интерфейсах и всяких контейнерах не к месту. Когда с маниакальной настойчивостью пишут супергибкий и расширяемый во все стороны код.

BFE>Ерунда это. Супергибкий и расширяемый во все стороны код почти никто не умеет писать. Такой код обычно не проходит тестирование.

Люто минусую.

BFE>Абстакции никак не связаны со сложностью чтения, а вот со сложностью исправления багов — очень даже. При абстракциях баг правится ровно в одном месте, а при их отсутствии приходится искать все возможные неверные конфигурации по всему коду.


Люто плюсую.
Re[6]: Может ли хороший программист, пройти фильтр плохого,
От: mgu  
Дата: 21.07.21 13:23
Оценка:
Здравствуйте, Умака Кумакаки, Вы писали:

BFE>>Абстакции никак не связаны со сложностью чтения, а вот со сложностью исправления багов — очень даже. При абстракциях баг правится ровно в одном месте, а при их отсутствии приходится искать все возможные неверные конфигурации по всему коду.


УК>тут какая-то лютая ахинея про связь абстракций и проявление бага в одном месте написана, даже стесняюсь спросить где ты работаешь, чтобы туда не попасть


Вы лучше про своё место работы напишите, чтобы обходить его за милю*.

*Миля -- абстрактная единица.
Re[5]: Может ли хороший программист, пройти фильтр плохого,
От: gyraboo Россия  
Дата: 21.07.21 13:24
Оценка: +1
Здравствуйте, B0FEE664, Вы писали:

BFE>Абстакции никак не связаны со сложностью чтения, а вот со сложностью исправления багов — очень даже.


Мне кажется, абстракция как раз-таки упрощает чтение кода, смотрим определение термина "абстрация" в википедии:
"Абстра́кция в объектно-ориентированном программировании — это использование только тех характеристик объекта, которые с достаточной точностью представляют его в данной системе. Основная идея состоит в том, чтобы представить объект минимальным набором полей и методов и при этом с достаточной точностью для решаемой задачи."

Ведь чем меньше полей, особенно если нет лишних полей, тем проще читать код.
www.nanonewsnet.ru
Re[6]: Может ли хороший программист, пройти фильтр плохого,
От: B0FEE664  
Дата: 21.07.21 14:07
Оценка:
Здравствуйте, gyraboo, Вы писали:

BFE>>Абстакции никак не связаны со сложностью чтения, а вот со сложностью исправления багов — очень даже.


G>Мне кажется, абстракция как раз-таки упрощает чтение кода, смотрим определение термина "абстрация" в википедии:

G>"Абстра́кция в объектно-ориентированном программировании — это использование только тех характеристик объекта, которые с достаточной точностью представляют его в данной системе. Основная идея состоит в том, чтобы представить объект минимальным набором полей и методов и при этом с достаточной точностью для решаемой задачи."

Странное определение. Что ещё за "с достаточной точностью"?

G>Ведь чем меньше полей, особенно если нет лишних полей, тем проще читать код.


Вовсе нет. Не выходя за рамки данного определения можно сказать, что для представления любого объекта достаточно двух-трех методов:
метод перечисляющий функции работы с объектом,
метод перечисляющий поля объекта и
метод перечисляющий аргументы для каждой перечисленной функции.
Всего-то три метода и вот вам точное представление объекта в системе.

Думаете легко с такой абстра́кцией работать? Скажу по опыту: работать можно, но это не просто. Гораздо проще, если методы и поля можно вызывать и использовать непосредственно. Однако есть системы, где прямые вызовы и непосредственное использование будут только усложнять код, а вот приведённая абстракция — упрощать. Поэтому уровень абстрагирования должен соответствовать сложности решаемой задачи.
И каждый день — без права на ошибку...
Re[7]: Может ли хороший программист, пройти фильтр плохого,
От: gyraboo Россия  
Дата: 21.07.21 14:18
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>>>Абстакции никак не связаны со сложностью чтения, а вот со сложностью исправления багов — очень даже.


G>>Мне кажется, абстракция как раз-таки упрощает чтение кода, смотрим определение термина "абстрация" в википедии:

G>>"Абстра́кция в объектно-ориентированном программировании — это использование только тех характеристик объекта, которые с достаточной точностью представляют его в данной системе. Основная идея состоит в том, чтобы представить объект минимальным набором полей и методов и при этом с достаточной точностью для решаемой задачи."

BFE>Странное определение. Что ещё за "с достаточной точностью"?


"с достаточной точностью для решаемой задачи"
Почему странное? А как бы ты определил что такое абстракция?

G>>Ведь чем меньше полей, особенно если нет лишних полей, тем проще читать код.


BFE>Вовсе нет. Не выходя за рамки данного определения можно сказать, что для представления любого объекта достаточно двух-трех методов:

BFE>метод перечисляющий функции работы с объектом,
BFE>метод перечисляющий поля объекта и
BFE>метод перечисляющий аргументы для каждой перечисленной функции.
BFE>Всего-то три метода и вот вам точное представление объекта в системе.

BFE>Думаете легко с такой абстра́кцией работать? Скажу по опыту: работать можно, но это не просто. Гораздо проще, если методы и поля можно вызывать и использовать непосредственно. Однако есть системы, где прямые вызовы и непосредственное использование будут только усложнять код, а вот приведённая абстракция — упрощать. Поэтому уровень абстрагирования должен соответствовать сложности решаемой задачи.


Ну да, уровень абстрагирования должен быть "с достаточной точностью для решаемой задачи".
Перечисляющие методы — это какой-то необычный подход, я конечно же говорил про обычное ооп-шное, когда все методы и поля именуются и вызываются клиентом явно, а не через какие-то списки функций и полей. Другими словами, чем меньше методов и полей у класса, без ущерба решаемой задаче, тем проще код. Если же подходить к этому формально, то теоретически можно разбить всю бизнес-логику на простейшие абстракции, у каждой сделать всего 2 метода:
execute() — выполняет 1 операцию
getLinked() — возвращает ссылку на связанную абстракцию.
Если по бизнесу некая сущность выполняет n операций, то мы разбиваем эту сущность на n абстракций, каждая абстракция объявляет метод execute и ссылку на связанную абстракцию, которая выполняет другую операцию этой бизнес-сущности. И формально такой код должен быть наиболее простым, ведь каждая абстракция имеет всего 2 метода. Но по сути такой код превратится в гротескную и сложную для понимания кашу.
www.nanonewsnet.ru
Re[8]: Может ли хороший программист, пройти фильтр плохого,
От: B0FEE664  
Дата: 21.07.21 15:04
Оценка:
Здравствуйте, gyraboo, Вы писали:

G>"с достаточной точностью для решаемой задачи"

G>Почему странное? А как бы ты определил что такое абстракция?
Абстракция в ООП — это возможность совершать операцию над неопределённым множеством разнотипных объектов (или же метод позволяющий исполнить такую возможность).

G>>>Ведь чем меньше полей, особенно если нет лишних полей, тем проще читать код.


BFE>>Вовсе нет. Не выходя за рамки данного определения можно сказать, что для представления любого объекта достаточно двух-трех методов:

BFE>>метод перечисляющий функции работы с объектом,
BFE>>метод перечисляющий поля объекта и
BFE>>метод перечисляющий аргументы для каждой перечисленной функции.
BFE>>Всего-то три метода и вот вам точное представление объекта в системе.

BFE>>Думаете легко с такой абстра́кцией работать? Скажу по опыту: работать можно, но это не просто. Гораздо проще, если методы и поля можно вызывать и использовать непосредственно. Однако есть системы, где прямые вызовы и непосредственное использование будут только усложнять код, а вот приведённая абстракция — упрощать. Поэтому уровень абстрагирования должен соответствовать сложности решаемой задачи.


G>Ну да, уровень абстрагирования должен быть "с достаточной точностью для решаемой задачи".

G>Перечисляющие методы — это какой-то необычный подход, я конечно же говорил про обычное ооп-шное, когда все методы и поля именуются и вызываются клиентом явно, а не через какие-то списки функций и полей.
Это обычное, но редко используемое ООП.

G>Другими словами, чем меньше методов и полей у класса, без ущерба решаемой задаче, тем проще код. Если же подходить к этому формально, то теоретически можно разбить всю бизнес-логику на простейшие абстракции, у каждой сделать всего 2 метода:

G>execute() — выполняет 1 операцию
G>getLinked() — возвращает ссылку на связанную абстракцию.
G>Если по бизнесу некая сущность выполняет n операций, то мы разбиваем эту сущность на n абстракций, каждая абстракция объявляет метод execute и ссылку на связанную абстракцию, которая выполняет другую операцию этой бизнес-сущности. И формально такой код должен быть наиболее простым, ведь каждая абстракция имеет всего 2 метода. Но по сути такой код превратится в гротескную и сложную для понимания кашу.

Вот поэтому я и говорю, что абстакция никак не связаны со сложностью чтения, т.к. абстракция может как упрощать, так и усложнять чтение кода. Если задача сложная, то абстракция может упростить код, если задача простая, то абстракция может усложнить код.
И каждый день — без права на ошибку...
Re[9]: Может ли хороший программист, пройти фильтр плохого,
От: gyraboo Россия  
Дата: 21.07.21 15:15
Оценка:
Здравствуйте, B0FEE664, Вы писали:

G>>"с достаточной точностью для решаемой задачи"

G>>Почему странное? А как бы ты определил что такое абстракция?
BFE>Абстракция в ООП — это возможность совершать операцию над неопределённым множеством разнотипных объектов (или же метод позволяющий исполнить такую возможность).

Не совсем корректная формулировка. Ведь все эти разнотипные объекты все же состоят в отношениях с абстракцией ("is a" в случае наследования или "realize" в случае реализации). Поэтому говорить, что эти объекты разнотипны — это не совсем корректно. Их типы всегда имеют одним из базовых типов тип абстракции.
Кроме того, есть абстракции, выделенные по признакам (полям), а не по операциям, поэтому возможность совершать операцию — это не определение того что такое абстракция.
Я думаю так: Абстрагирование — это создание типа, обобщающего множество объектов разных подтипов. Абстракция — это сам обобщающий тип.

G>>>>Ведь чем меньше полей, особенно если нет лишних полей, тем проще читать код.


BFE>>>Вовсе нет. Не выходя за рамки данного определения можно сказать, что для представления любого объекта достаточно двух-трех методов:

BFE>>>метод перечисляющий функции работы с объектом,
BFE>>>метод перечисляющий поля объекта и
BFE>>>метод перечисляющий аргументы для каждой перечисленной функции.
BFE>>>Всего-то три метода и вот вам точное представление объекта в системе.

BFE>>>Думаете легко с такой абстра́кцией работать? Скажу по опыту: работать можно, но это не просто. Гораздо проще, если методы и поля можно вызывать и использовать непосредственно. Однако есть системы, где прямые вызовы и непосредственное использование будут только усложнять код, а вот приведённая абстракция — упрощать. Поэтому уровень абстрагирования должен соответствовать сложности решаемой задачи.


G>>Ну да, уровень абстрагирования должен быть "с достаточной точностью для решаемой задачи".

G>>Перечисляющие методы — это какой-то необычный подход, я конечно же говорил про обычное ооп-шное, когда все методы и поля именуются и вызываются клиентом явно, а не через какие-то списки функций и полей.
BFE>Это обычное, но редко используемое ООП.

G>>Другими словами, чем меньше методов и полей у класса, без ущерба решаемой задаче, тем проще код. Если же подходить к этому формально, то теоретически можно разбить всю бизнес-логику на простейшие абстракции, у каждой сделать всего 2 метода:

G>>execute() — выполняет 1 операцию
G>>getLinked() — возвращает ссылку на связанную абстракцию.
G>>Если по бизнесу некая сущность выполняет n операций, то мы разбиваем эту сущность на n абстракций, каждая абстракция объявляет метод execute и ссылку на связанную абстракцию, которая выполняет другую операцию этой бизнес-сущности. И формально такой код должен быть наиболее простым, ведь каждая абстракция имеет всего 2 метода. Но по сути такой код превратится в гротескную и сложную для понимания кашу.

BFE>Вот поэтому я и говорю, что абстакция никак не связаны со сложностью чтения, т.к. абстракция может как упрощать, так и усложнять чтение кода. Если задача сложная, то абстракция может упростить код, если задача простая, то абстракция может усложнить код.


К сожалению ты не понял мою мысль, а я не могу её донести. Абстракция именно что связана со сложностью чтения, если эта абстракция не формально уменьшает кол-во полей, а делает это адекватно и в соответствии с решаемой задачей. Бизнес-логика, написанная на абстрактном уровне, всегда проще, чем бизнес-логика слоя реализации, т.к. слой реализации кроме обобщенных абстрактных операций содержит кучу полей и методов, описывающих детали. А деталей всегда много, они запутанны, и усложняют чтение кода.
www.nanonewsnet.ru
Re[5]: Может ли хороший программист, пройти фильтр плохого, при найме?
От: Lloret  
Дата: 21.07.21 16:15
Оценка:
mgu>А вашему начальнику не нужны профессионалы: они же, канальи, всё сделают за полгода, и система будет работать как часы. Затем профессионалы откочуют в другую контору, а куда деваться начальнику?

И что мешает наальнику самому их "откочевать", а вместо них набрать раза в 3 больше джунов, которые будут в 2 раза дешевле? А что, система крутится, лавэ мутится... Мастера сделали свое дело, им заплатили $$$$$$$$ , теперь можно и лей-оффнуть.
Re[6]: Может ли хороший программист, пройти фильтр плохого,
От: mgu  
Дата: 21.07.21 16:40
Оценка: +1
Здравствуйте, gyraboo, Вы писали:

BFE>>Абстакции никак не связаны со сложностью чтения, а вот со сложностью исправления багов — очень даже.


G>Мне кажется, абстракция как раз-таки упрощает чтение кода, смотрим определение термина "абстрация" в википедии:

G>"Абстра́кция в объектно-ориентированном программировании — это использование только тех характеристик объекта, которые с достаточной точностью представляют его в данной системе. Основная идея состоит в том, чтобы представить объект минимальным набором полей и методов и при этом с достаточной точностью для решаемой задачи."

G>Ведь чем меньше полей, особенно если нет лишних полей, тем проще читать код.


Подкину ещё: если кто-то не видит абстракций, то это не означает, что их нет. Например, нам надо оперировать возрастом:

int age = 33;

int -- это абстракция, возраст обычно не превышает 120 лет, понадобятся проверки. А можно и чисто конкретно:

Age age = new Age(33);

А внутри будут конструктор и сеттер с проверкой. Но всё равно нужно будет отслеживать их успешность. Так что часто абстракции проще. А при предоставлении API без них вообще никак.
Re[6]: Может ли хороший программист, пройти фильтр плохого, при найме?
От: mgu  
Дата: 21.07.21 16:51
Оценка: 8 (1)
Здравствуйте, Lloret, Вы писали:

mgu>>А вашему начальнику не нужны профессионалы: они же, канальи, всё сделают за полгода, и система будет работать как часы. Затем профессионалы откочуют в другую контору, а куда деваться начальнику?


L>И что мешает наальнику самому их "откочевать", а вместо них набрать раза в 3 больше джунов, которые будут в 2 раза дешевле? А что, система крутится, лавэ мутится... Мастера сделали свое дело, им заплатили $$$$$$$$ , теперь можно и лей-оффнуть.


Да так, собственно, обычно и происходит. Причём по спирали: в моменты, когда система начинает идти вразнос, нанимают реаниматолога.
Re[7]: Может ли хороший программист, пройти фильтр плохого,
От: Умака Кумакаки Ниоткуда  
Дата: 21.07.21 17:35
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Скажите, Умака Кумакаки, как часто вы исправляете ошибки в чужом коде? Не находите, а именно исправляете.


три раза в день, например
нормально делай — нормально будет
Re[7]: Может ли хороший программист, пройти фильтр плохого,
От: Умака Кумакаки Ниоткуда  
Дата: 21.07.21 17:56
Оценка: -2 :)
Здравствуйте, mgu, Вы писали:

mgu>int age = 33;


mgu>Age age = new Age(33);


если для тебя второй вариант проще, то это серьёзные проблемы с кукухой и "вон из профессии"
нормально делай — нормально будет
Re[8]: Может ли хороший программист, пройти фильтр плохого,
От: gyraboo Россия  
Дата: 21.07.21 18:05
Оценка: +2
Здравствуйте, Умака Кумакаки, Вы писали:

mgu>>int age = 33;


mgu>>Age age = new Age(33);


УК>если для тебя второй вариант проще, то это серьёзные проблемы с кукухой и "вон из профессии"


Зависит от абстракции. Если абстракция возраст имеет такие свойства, как особенности возраста, то инкапсулировать их в объекте Возраст — не самая плохая идея.
www.nanonewsnet.ru
Re[8]: Может ли хороший программист, пройти фильтр плохого,
От: mgu  
Дата: 21.07.21 23:59
Оценка:
Здравствуйте, Умака Кумакаки, Вы писали:

УК>Здравствуйте, mgu, Вы писали:


mgu>>int age = 33;


mgu>>Age age = new Age(33);


УК>если для тебя второй вариант проще, то это серьёзные проблемы с кукухой и "вон из профессии"


Это был вырожденный пример без конкретной реализации, не побоюсь этого слова, абстракция. Для тех, кто любит попроще, можно сделать посложнее:

Age age = 33;

(с перегрузкой оператора).

Но не все понимают абстракции, как например:

ссылка
Re[4]: Может ли хороший программист, пройти фильтр плохого,
От: AlexGin Беларусь  
Дата: 22.07.21 09:23
Оценка:
Здравствуйте, vsb, Вы писали:

L>Простой для кого и понятный кому?


vsb>Для тех, кто его будет читать и модифицировать в будущем. Планка зависит от минимальной квалификации допускаемого к этому коду программиста конкретной компании. Там, где я был, эта планка на уровне начинающего разработчика, знающего основные конструкции языка.


Это правильно — не найдут роту вундеркиндов в компанию по разработке софта.
Тем более, что кроме самого ЯП/технологии, следует иметь и представления о прикладной области, для которой и создаётся софт.

В NASA, наверное, эта планка на уровне доктора наук.

Самый трудночитаемый и сложно-сопровождаемый код я видел у людей науки.
Их задача — не код, а скорее концепции и формулы.
Так что — и в NASA будут те же требования, когда передадут разработку субподрядной софтверной компании.

P.S. В NASA (предполагаю) разработку ещё пару лет будут тестировать.
Re[5]: Может ли хороший программист, пройти фильтр плохого,
От: Sharov Россия  
Дата: 22.07.21 10:09
Оценка: +1
Здравствуйте, B0FEE664, Вы писали:

BFE>Абстакции никак не связаны со сложностью чтения, а вот со сложностью исправления багов — очень даже. При абстракциях баг правится ровно в одном месте, а при их отсутствии приходится искать все возможные неверные конфигурации по всему коду.


Грамотные абстракции это самое чтение очень сильно сокращают -- не надо лопатить кучу кода, чтобы что-то найти и поправить.
Ищется конкретная абстракция и соотв. метод, в одном месте все и правиться. В противном случае, процедурный стиль
или дурацкие и текучие абстракции, править надо в нескольких местах, а значит и кода прочитать в разы больше.
Абстракции именно про написания и чтение кода, экономия времени на этом.
Кодом людям нужно помогать!
Отредактировано 22.07.2021 17:50 Sharov . Предыдущая версия . Еще …
Отредактировано 22.07.2021 10:20 Sharov . Предыдущая версия .
Отредактировано 22.07.2021 10:20 Sharov . Предыдущая версия .
Re[6]: Может ли хороший программист, пройти фильтр плохого,
От: gyraboo Россия  
Дата: 22.07.21 10:12
Оценка: +1
Здравствуйте, Sharov, Вы писали:

BFE>>Абстакции никак не связаны со сложностью чтения, а вот со сложностью исправления багов — очень даже. При абстракциях баг правится ровно в одном месте, а при их отсутствии приходится искать все возможные неверные конфигурации по всему коду.


S>Грамотное абстракции это самое чтение очень сильно сокащают -- не надо лапатить кучу кода, чтобы что-то найти и поправить. Ищется

S>конкретная абстракция и соотв. метод, в одном месте все и правиться. В противном случае, процедурный стиль или дурацкие и текучие
S>абстракции, править надо в нескольких местах, а значит и кода прочитать в разы больше. Абстракции именно про написания и чтение кода,
S>экономия времени на этом.

И ещё нужно соблюдать принцип SOLID/DIP. Чтобы не смешивать на одном уровне абстракцию и реализацию. Иначе детали реализации будут затруднять чтение кода абстракции.
www.nanonewsnet.ru
Re[7]: Может ли хороший программист, пройти фильтр плохого,
От: Sharov Россия  
Дата: 22.07.21 10:21
Оценка:
Здравствуйте, gyraboo, Вы писали:

G>И ещё нужно соблюдать принцип SOLID/DIP. Чтобы не смешивать на одном уровне абстракцию и реализацию. Иначе детали реализации будут затруднять чтение кода абстракции.


Я же упомянул текучие абстракции (leaky abstractions), это как раз оно.
Кодом людям нужно помогать!
Re[8]: Может ли хороший программист, пройти фильтр плохого,
От: gyraboo Россия  
Дата: 22.07.21 10:23
Оценка:
Здравствуйте, Sharov, Вы писали:

G>>И ещё нужно соблюдать принцип SOLID/DIP. Чтобы не смешивать на одном уровне абстракцию и реализацию. Иначе детали реализации будут затруднять чтение кода абстракции.


S>Я же упомянул текучие абстракции (leaky abstractions), это как раз оно.


А, ясно. Не знал такого термина, поэтому не заметил.
www.nanonewsnet.ru
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.