I>Как избавить компанию от "плохих" программистов которые не хотят развиваться в сторону правильных архитектурных решений, а упорно стоят на позиции что хороший программист это тот который умеет писать сложный код. )
Никак, пока человек не пройдет весь путь:
1) Напишет свою архтектуру, а через пару лет вознинет необходимость переделывать
2) Проведет несколько лет на поддержке такого сложного кода, написанного другими
3) Прочитает аннотацию одного из банды четырех, где описано для чего писалась та книга
4) Узнает про парадокс, по которому больше работать, не означает больше получать денег
5) Поймет, что тупо кодить — уныло, а сложно кодить — вдвойне уныло, интереснее выходить за пределы проекта.

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

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Плохих программистов не бывает. Бывают плохие руководители (Ваш случай)

Плохие программисты бывают, и их обычно повышают до руководителя (зачем же перемещать специалиста, хорошо пишущего код?)

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

mgu>int age = 33;

mgu>Age age = new Age(33);

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

KP> из-за того что на нём куча народу сидит

По вполне очевидной причине: это лучший в своей категории продукт по совокупности свойств.
Есть аналогичные, в чем-то превосходящие — например, Signal объективно предоставляет чуть больше privacy.

Но по совокупности аналогов нет. Так, чтобы надежно работать с более чем двухмиллиардной армией пользователей, — попросту ни одного другого варианта не существует. А свистоперделки вставлять на сотню миллионов юзеров с парой поддерживаемых платформ совсем нетрудно.

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

Воспользуюсь сообщением из другого топика.

Автор: Denwer
Дата: 09.07.21

ЭФ>Категорически не согласен. Их учат правильно физически защищать помещения,
ЭФ>анализировать трафик и куче другой админской специфики.

Не нужно мне рассказывать чему их учат и уровень их подготовки, они проходят стажировку и практику у нас, а безопасников обычно я беру, т.к. самые годные студенты почему то там.

Упаси боже, чтобы кто-то подумал, что я назначаю кого-то в "хороших" или "плохих" программистов тут!! Нет, просто использую это расхождение во взглядах, что бы проилюстрировать разную школу программирования.

Одни считают, что хороший программист, это тот который умный-умный и умеет писать алгоритмы! И пишет страшно маленькие и страшно быстрые программы.
Другие считают, что хороший программист, это тот который умеет разрабатывать промышленный код! Тот код который, страшно простой и понятный, и который потом можно сопровождать и самое главное потом легко развивать.

То есть у одного врожденный талант и нет знаний (хакеры не учатся), а у другого знания об архитектуре (слоистости, интерфейсах, минимизации связей и пр), и о жизненном цикле ПО.

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

Избавить в том смысле, как научить "плохих" программистов, развиваться? Как заронить в их головах искру сомнения — а может я что-то делаю не так?

===

Тема очень актуальна для России, так как хакеров явно хватает, а вот технологов явно нет.
Что делать? Жесткая атестация? Принудительные курсы повышения квалификации?

G>Но переписывать не дадут. А если датут — то выделят, скажем, год на переписывания системы, которую писали 15 лет. И это будет заведомо провальный проект.
G>Но можно сцепив зубы постепенно отпиливать кусочки от существующего монолита. Или распределенного монолита. Постоянно выбивая у бизнеса ресурсы на рефакторинг и доказывая что когда-нибудь это сократит поток инцидентов и time-to-market. И это можно сделать. Все можно. Только где вот тут неспешность?

Похоже, что у вас есть действительно ценный опыт. Без шуток, описываемое вами — ничуть не редкость, но чаще случается в больших (или очень старых) конторах.

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

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

mgu>Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>>Плохих программистов не бывает. Бывают плохие руководители (Ваш случай)

mgu>Плохие программисты бывают, и их обычно повышают до руководителя (зачем же перемещать специалиста, хорошо пишущего код?)

Такое бывает. Человеку ну просто не дано быть программистом. Но при этом он в каждой ж..е затычка, всюду лезет и выкарабкивается наверх. Видел такое.

Но я бы сказал, что и хороших разрабов продвигают в лиды (у которых половина времени тратится на всякую менеджескую активность). Причем это практически единственный сценарий, как стать лидом.

Здравствуйте, imh0, Вы писали:

vsb>>Если программист не умеет писать алгоритмы и быстрый код, то он плохой программист, очевидно. Если программист не умеет писать простой и понятный код, то он тоже плохой программист. Зачем тут выбирать? Хороший сферический программист в вакууме должен уметь делать и то и другое. А если некий программист умеет делать что-то одно, то для всех областей применять его не получится.

I>"писать алгоритмы и страшно быстрый код", так-то это был "сарказам". ) Это негодная оптимизация!

Если человек оптимизирует в ущерб читаемости там, где оптимизация не нужна, то это признак того, что он ещё не дошёл до нужного уровня развития. Ну или у него был специфический бэкграунд, если кто-то всю жизнь писал код для микроконтролеров, а потом пересел на Java, наверное как-то так и будет.

I>Алгоритмы и быстрый код нужны там где, есть узкое место.

Вот и я про то же. Не понимая хотя бы временной сложности того кода, который ты пишешь, очень легко создать на ровном месте тормоза. O(N^2) выстреливает очень быстро, причём, что самое неприятное, зачастую в продакшне.

I>Да пожайлуйста — вести хранение заранее посчитанных длинн и определять изменение по попытке доступа на запись в память строки. )

В C вообще идиотская манера хранить строки, не представляю, как это пролезло в мейнстрим. Длину надо хранить в -1, -2 и тд байте. И не придётся её считать. Ну или просто где-то рядом с указателем, как это делается в большинстве остальных языков. По-моему кроме С (и тех мест, где нужна совместимость с С) больше нигде так не делают.

Здравствуйте, Lloret, Вы писали:

vsb>>Если программист не умеет писать простой и понятный код

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

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

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

mgu>>int age = 33;

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

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

Зависит от абстракции. Если абстракция возраст имеет такие свойства, как особенности возраста, то инкапсулировать их в объекте Возраст — не самая плохая идея.

Здравствуйте, Lloret, Вы писали:

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

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

Да так, собственно, обычно и происходит. Причём по спирали: в моменты, когда система начинает идти вразнос, нанимают реаниматолога.

Здравствуйте, imh0, Вы писали:

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

Если курс задан и он не совпадает с точкой зрения некоторых разработчиков, то эти разработчики рано или поздно или начнут работать с принятием такого курса, или уйдут. Третьего не дано. Всё зависит от лида, как он сможет всё это разрулить.

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

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

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

Здравствуйте, namespace, Вы писали:

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

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

Плохих программистов не бывает. Бывают плохие руководители (Ваш случай)

I>Одни считают, что хороший программист, это тот который умный-умный и умеет писать алгоритмы! И пишет страшно маленькие и страшно быстрые программы.
I>Другие считают, что хороший программист, это тот который умеет разрабатывать промышленный код! Тот код который, страшно простой и понятный, и который потом можно сопровождать и самое главное потом легко развивать.

I>То есть у одного врожденный талант и нет знаний (хакеры не учатся), а у другого знания об архитектуре (слоистости, интерфейсах, минимизации связей и пр), и о жизненном цикле ПО.

Эти выводы не очень логично звучат.

Нет никакого "врожденного таланта". Зато есть опыт и знания. Написать страшно маленькую, страшно быструю программу — это высший уровень умений. Чаще всего эта программа будет еще и очень понятна (тому кто вообще хоть в чем-то может разобраться сложнее "вложенных if"). И чаще всего на основе этой программы можно будет строить много всего. Ибо она — маленькая и очень простая, с четким назначением и понятным смыслом.

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

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

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

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

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

Здравствуйте, B0FEE664, Вы писали:


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

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

Здравствуйте, B0FEE664, Вы писали:

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

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

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

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

vsb>>В NASA, наверное, эта планка на уровне доктора наук.
BFE>Смешно мне с такого.

А мне грустно: проскакивала информация, что в Гугле яйцеголовых бросают на цензурирование высказываний в Ютубе.

Здравствуйте, B0FEE664, Вы писали:

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

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

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

Здравствуйте, gyraboo, Вы писали:

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

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

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

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

int age = 33;

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

Age age = new Age(33);

А внутри будут конструктор и сеттер с проверкой. Но всё равно нужно будет отслеживать их успешность. Так что часто абстракции проще. А при предоставлении API без них вообще никак.

Здравствуйте, B0FEE664, Вы писали:

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

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

Здравствуйте, Sharov, Вы писали:

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

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

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

mgu>По плодам их узна́ете их. А заявляет начальство обычно про то, что через пару лет "мы порвём Майкрософт", ещё 40 тысяч вёдер, и золотой ключик у нас в кармане!

К счастью, моему начальству делать такие заявления не требуется. Ибо наш продукт действительно не только лучший, но и самый сильный на рынке. Майкрософту не светит.

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

SD>>К счастью, моему начальству делать такие заявления не требуется. Ибо наш продукт действительно не только лучший, но и самый сильный на рынке. Майкрософту не светит.
mgu>Шо за продукт?

WhatsApp.

SD>>>К счастью, моему начальству делать такие заявления не требуется. Ибо наш продукт действительно не только лучший, но и самый сильный на рынке. Майкрософту не светит.
mgu>>Шо за продукт?

S>WhatsApp.

Это та срань, что не позволяет просмотреть сообщения без инета, которые писались на телефоне? И которая не переносит сообщения на другое тело телефона, если я симку поменяю? И которая не дает добавить контакт в нее, а не в стандартную записную книжку?

Здравствуйте, Lloret, Вы писали:

SD>>>>К счастью, моему начальству делать такие заявления не требуется. Ибо наш продукт действительно не только лучший, но и самый сильный на рынке. Майкрософту не светит.
mgu>>>Шо за продукт?

S>>WhatsApp.

L>Это та срань, что не позволяет просмотреть сообщения без инета, которые писались на телефоне? И которая не переносит сообщения на другое тело телефона, если я симку поменяю? И которая не дает добавить контакт в нее, а не в стандартную записную книжку?

Остаётся снять шляпу перед его маркетологами -- хороший продукт может продвинуть каждый дурак. И, скорее всего, WhatsApp повторит судьбу Скайпа, который М$ выкупил и изговнял.

Здравствуйте, SkyDance, Вы писали:

mgu>>По плодам их узна́ете их. А заявляет начальство обычно про то, что через пару лет "мы порвём Майкрософт", ещё 40 тысяч вёдер, и золотой ключик у нас в кармане!

SD>К счастью, моему начальству делать такие заявления не требуется. Ибо наш продукт действительно не только лучший, но и самый сильный на рынке. Майкрософту не светит.

Ваш продукт редкостное УГ, которым приходится пользоваться исключительно из-за того что на нём куча народу сидит. Для всех коммуникаций с людьми кто пользуется альтернативными мессенджерами предпочитаю их. Беда в том, что народ костный, а ваше ICQ на момент создания действительно было сильным продуктом.

I>Тема очень актуальна для России, так как хакеров явно хватает, а вот технологов явно нет.

Что-то сомневаюсь. Одни технологи кругом, своей головой подумать мало кто может.

Здравствуйте, imh0, Вы писали:

I>Одни считают, что хороший программист, это тот который умный-умный и умеет писать алгоритмы! И пишет страшно маленькие и страшно быстрые программы.
I>Другие считают, что хороший программист, это тот который умеет разрабатывать промышленный код! Тот код который, страшно простой и понятный, и который потом можно сопровождать и самое главное потом легко развивать.

Если программист не умеет писать алгоритмы и быстрый код, то он плохой программист, очевидно. Если программист не умеет писать простой и понятный код, то он тоже плохой программист. Зачем тут выбирать? Хороший сферический программист в вакууме должен уметь делать и то и другое. А если некий программист умеет делать что-то одно, то для всех областей применять его не получится.

I>Избавить в том смысле, как научить "плохих" программистов, развиваться? Как заронить в их головах искру сомнения — а может я что-то делаю не так?

Если человек уверен в своей позиции — и достаточно зрел, то никак. Или силком заставить, но скорей всего он сам уволится через некоторое время, если у него будут другие варианты, или уволить.

Здравствуйте, vsb, Вы писали:

vsb>Если программист не умеет писать алгоритмы и быстрый код, то он плохой программист, очевидно. Если программист не умеет писать простой и понятный код, то он тоже плохой программист. Зачем тут выбирать? Хороший сферический программист в вакууме должен уметь делать и то и другое. А если некий программист умеет делать что-то одно, то для всех областей применять его не получится.

"писать алгоритмы и страшно быстрый код", так-то это был "сарказам". ) Это негодная оптимизация!
Алгоритмы и быстрый код нужны там где, есть узкое место. Функцию strlen можно тоже оптимизировать до ручки, хотя казалось бы как это можно.
Да пожайлуйста — вести хранение заранее посчитанных длинн и определять изменение по попытке доступа на запись в память строки. )
Например. )

Здравствуйте, imh0, Вы писали:

I>То есть у одного врожденный талант и нет знаний (хакеры не учатся), а у другого знания об архитектуре (слоистости, интерфейсах, минимизации связей и пр), и о жизненном цикле ПО.

Ну вот покойный мыщъх был хакером из настоящих, что называется. Неужто про него можно сказать, что он не учился? Я не о формальных корочках, а новых знаниях.

Здравствуйте, imh0, Вы писали:

I>Да пожайлуйста — вести хранение заранее посчитанных длинн и определять изменение по попытке доступа на запись в память строки. )
I>Например. )

Емнип, в Паскале строки именно так хранились
Сперва длина строки, потом данные — вполне себе рабочий вариант представления строк.

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

Мне кажется, что задача обратная: как заставить компании понять, что программист натыркавшийся на литкоде с никому не нужным кодом не равно хороший программист.

Здравствуйте, ForestDront, Вы писали:

FD>Мне кажется, что задача обратная: как заставить компании понять, что программист натыркавшийся на литкоде с никому не нужным кодом не равно хороший программист.

Вроде как раз не обратная. )

Здравствуйте, imh0, Вы писали:

I>Одни считают, что хороший программист, это тот который умный-умный и умеет писать алгоритмы! И пишет страшно маленькие и страшно быстрые программы.
I>Другие считают, что хороший программист, это тот который умеет разрабатывать промышленный код! Тот код который, страшно простой и понятный, и который потом можно сопровождать и самое главное потом легко развивать.

I>То есть у одного врожденный талант и нет знаний (хакеры не учатся), а у другого знания об архитектуре (слоистости, интерфейсах, минимизации связей и пр), и о жизненном цикле ПО.

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

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

По поводу фильтра при найме. Я прошёл больше сотни интервью и могу уверенно сказать, что проблема тут чисто психологическая. IT-чмошник изначально идёт "валить" кандидата, ничем не брезгуя, лишь бы самоутвердиться. IT-инфузория искренне не понимает, как можно не знать содержимого её пробирки, и что даже узкая область не ограничивается её мембраной. Есть ещё варианты написания кода под секундомер с формальной проверкой по ограниченному списку критериев. Если нанимают таким способом, то откуда берутся многомесячные срывы сроков сдачи очередного этапа? Зашкварное количество брака вопросов у меня не вызывает. У всех этих случаев есть один общий признак -- строгие временные рамки, то есть важен сам процесс, а не результат.

А для специалиста для принятия решения достаточно 15 минут: несколько вопросов, связанных с вакансией, а не с тем, что чепушила когда-то учил или узнал только вчера.

Здравствуйте, namespace, Вы писали:

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

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

Так это же прекрасно! Но каким боком тут сложность?

N>Как результат: куча кода, который ничего полезного не делает, и в котором очень сложно разобраться.

Как раз гибкий код и получается компактным. А упомянутые кучи -- это ветки, в которые программа не может зайти в принципе.

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

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

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

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

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

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

mgu>Средним разработчикам как раз такое не под силу -- у них кругозор ограничен текущей задачей.
как раз таки под силу, потому что они слышали звон да не знали где он и большая часть разработки у них мотивирована как резюме-дривен-девелопмент, им главное вписать побольше умных слов в резюме чтобы выбить +20% зп у другого работодателя, но часть просто по дурости плодит слои абсракций, потому что никто по пальцам не бьёт линейкой

mgu>Выделенный кусок не понял: начали за здравие, а кончили за упокой.
какой именно пункт не понят?
1) питухи кукарекают о расширяемости и масштабируемости, генерят кучу бойлерплейта и абсракций для этого
2) читабельность кода падает, потому что там где был простой вызов, теперь куча промежуточных слоёв абсракций
3) никаких особых требований к расширяемости и масштабирумости никто не предъявлял, питухи возбудились просто потому что могут

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

mgu>>Средним разработчикам как раз такое не под силу -- у них кругозор ограничен текущей задачей.
УК>как раз таки под силу, потому что они слышали звон да не знали где он и большая часть разработки у них мотивирована как резюме-дривен-девелопмент, им главное вписать побольше умных слов в резюме чтобы выбить +20% зп у другого работодателя, но часть просто по дурости плодит слои абсракций, потому что никто по пальцам не бьёт линейкой

Понимание абстракций и интерфейсов не входит в современный канон ключевых слов, от которых текут суровые технические директора (они дрочат на алгоритмы и структуры данных).

mgu>>Выделенный кусок не понял: начали за здравие, а кончили за упокой.
УК>какой именно пункт не понят?
УК>1) питухи кукарекают о расширяемости и масштабируемости, генерят кучу бойлерплейта и абсракций для этого
УК>2) читабельность кода падает, потому что там где был простой вызов, теперь куча промежуточных слоёв абсракций
УК>3) никаких особых требований к расширяемости и масштабирумости никто не предъявлял, питухи возбудились просто потому что могут

"ко-ко-ко расширяемо, ко-ко-ко, масштабируемо, ко-ко-ко", и как бы да, всё может быть и так

никаких особых требований к раширяемости и масштабируемости нет, не было и не будет,

Так пригодится расширяемость или нет?

Здравствуйте, imh0, Вы писали:


I>Тема очень актуальна для России, так как хакеров явно хватает, а вот технологов явно нет.

Да никого в России не хватает. По моему скромному опыта прохождения/проведения собеседований дефицит щас ну просто лютый.

А по теме: почему же не может? если звезды совпадут, то и плохой спец может нанять хорошего. Проблема плохого спеца не в том, что он не может нанять хорошего, проблема в том, что он это сделает с гораздо меньшей вероятностью, чем наймет плохого.
И тогда плохие будут притягивать плохих, и это будет расти как раковая опухоль.
А хороший с большой вероятностью откажется.
Серьезно. Вот если меня на собесе не впечатлит технический уровень интервьювера — я туда не пойду.


I>Что делать? Жесткая атестация? Принудительные курсы повышения квалификации?
Это ты о чем? Аттестация среди всех контор? Нереально вообще. И непонятно, как поможет.
Аттестация внутри вашей конторы? Ну... все зависит от жесткости. Если будет достаточно жестко — хорошие от вас побегут. А плохие останутся ))

vsb>Если программист не умеет писать простой и понятный код

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

N>Как результат: куча кода, который ничего полезного не делает

Как ничего полезного не делает? А Resume-Driven Development кто за Вас будет делать?

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

mgu>Так пригодится расширяемость или нет?

разумеется, нет. если бы она пригождалась хотя бы в пяти процентах случаев вопросов бы не было. Впрочем я понял, что ты себя узнал уже в описании типичного абсракциониста.

N>5) Поймет, что тупо кодить — уныло, а сложно кодить — вдвойне уныло, интереснее выходить за пределы проекта.

Иными словами, бросай программирование, денег все равно не заработаешь. Отличное предложение на форуме разработчиков.

mgu>Плохие программисты бывают, и их обычно повышают до руководителя (зачем же перемещать специалиста, хорошо пишущего код?)

Так и есть, но только причина со следствием перепутаны. Если человеку хочется учиться дебажить других людей, а не писать хороший код, то его место именно там — в менеджменте. А не в технической работе.

Здравствуйте, Gradiens, Вы писали:

G>Серьезно. Вот если меня на собесе не впечатлит технический уровень интервьювера — я туда не пойду.

Ну тут не так всё просто, если есть желание вырасти, приводя всё в порядок — то почему бы и нет Да и врятли кто-то ставит себе целью впечатлять кандидата знаниями, плюс человеческие факторы — не выспался, голова другим занята, или тот, кто должен был быть на интервью, заболел, и погнали попавшегося под руку

Здравствуйте, SkyDance, Вы писали:

SD>Нет никакого "врожденного таланта". Зато есть опыт и знания. Написать страшно маленькую, страшно быструю программу — это высший уровень умений. Чаще всего эта программа будет еще и очень понятна (тому кто вообще хоть в чем-то может разобраться сложнее "вложенных if"). И чаще всего на основе этой программы можно будет строить много всего. Ибо она — маленькая и очень простая, с четким назначением и понятным смыслом.

...и узкой областью применения. Промышленный же код выполняет огромное количество задач, пишется коллективно, и код по определению не может быть маленьким.

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

Именно слои и помогают структурировать массив кода и избегать нежелательных взаимодействий.

SD>И нет, не всегда это был тот же программист, что изначально разработал систему. Это были другие, те, кто "имеют знания о слоистости и интерфейсах".

Системы не пишут в одиночку. Более того, зачастую неизвестно, кто и каким образом будет подхватывать данные и затем их использовать для своих нужд. Поэтому без интерфейсов никак.

mgu>...и узкой областью применения.

Напротив. Красивый, краткий, понятный код, делающий ровно то, что нужно, без протечек абстракций, имеет самую широкую область применения. Как кирпич, строительный блок.

mgu>Промышленный же код выполняет огромное количество задач, пишется коллективно, и код по определению не может быть маленьким.

Это плохой код. Который "выполняет огромное количество задач". См. "God object" антипаттерн. Код, если он не маленький по определению, или плохо написан, или написан на неподходящей платформе (скажем, на ассемблере вместо РНР), или сделан в виде "огранического роста". Когда вместо архитектуры есть просто наслоения бизнес-логики "а сейчас нам понадобилось вот это", раковой опухолью разросшееся всюду. Без рефакторинга, без снижения сложности, без выделения общих сущностей и т.п..

mgu>Именно слои и помогают структурировать массив кода и избегать нежелательных взаимодействий.

Только при условии, что эти слои железными руками и в ежовых рукавицах держит кто-то очень хорошо понимающий, к каким последствиям ведут leaky abstractions. Это еще возможно в маленьких конторах, или где уже есть устоявшийся поток денег. Но никак не в стартапах (где главное — быстрее), или в больших компаниях, где политика попросту не позволяет существовать самой роли подобного архитектора.

SD>>И нет, не всегда это был тот же программист, что изначально разработал систему. Это были другие, те, кто "имеют знания о слоистости и интерфейсах".
mgu>Системы не пишут в одиночку. Более того, зачастую неизвестно, кто и каким образом будет подхватывать данные и затем их использовать для своих нужд. Поэтому без интерфейсов никак.

Это вообще к чему? Сравнение шло между "простым и кратким кодом" (который якобы "врожденный талант" дает), и "промышленным антиподом" — спагетти и лазаньей (со слоями же, да?) одновременно.

Здравствуйте, Antidote, Вы писали:

A>Здравствуйте, Gradiens, Вы писали:

G>>Серьезно. Вот если меня на собесе не впечатлит технический уровень интервьювера — я туда не пойду.

A>Ну тут не так всё просто, если есть желание вырасти, приводя всё в порядок — то почему бы и нет
Понимаю, зависит от мотивации.
Я уже вот прямо сейчас 3-й раз подрыд вырастаю, приводя все в порядок )) И это порядком поднадоело.
Но первый раз да, думал, я такой крутой, щас приду, да как нанесу непоправимую пользу! Так что согласен, невысокий уровень компании/интервьювера может говорить о возможностях. Не факт, что получится ими воспользоваться, но по крайней мере они есть.
А есть и другая мысль: Мне неинтересно чувствовать себя самым крутым, потому что эта крутизна только в пределах своего уютного (или не очень) болота. Вот я хочу расти в окружении профессионалов. Тогда расти буду в разы быстрее. Кроме того, "приводить все в порядок" может быть очень нервно затратно. И вообще, может быть нереально. То есть, поддерживать текущее легаси — бесперспективная нервотрепка. Выкинуть все и написать заново- авантюра, даже если выделят ресурсы. Постепенно переписывать легаси, отпочковывая от него сервисы и постоянно поддерживая совместимость — задача зачастую на годы. Не все осилят этот путь. А если и осилят, то в конце пути вам вместо награды вручат еще одно легаси ))


A>Да и врятли кто-то ставит себе целью впечатлять кандидата знаниями, плюс человеческие факторы — не выспался, голова другим занята, или тот, кто должен был быть на интервью, заболел, и погнали попавшегося под руку

Да, возможно.
Хотя косвенно обычно можно по уровню вопросов понять уровень знаний интервьювера, его кругозор.

Здравствуйте, Gradiens, Вы писали:

G>Я уже вот прямо сейчас 3-й раз подрыд вырастаю, приводя все в порядок )) И это порядком поднадоело.
G>Но первый раз да, думал, я такой крутой, щас приду, да как нанесу непоправимую пользу! Так что согласен, невысокий уровень компании/интервьювера может говорить о возможностях. Не факт, что получится ими воспользоваться, но по крайней мере они есть.
G>А есть и другая мысль: Мне неинтересно чувствовать себя самым крутым, потому что эта крутизна только в пределах своего уютного (или не очень) болота. Вот я хочу расти в окружении профессионалов. Тогда расти буду в разы быстрее. Кроме того, "приводить все в порядок" может быть очень нервно затратно. И вообще, может быть нереально. То есть, поддерживать текущее легаси — бесперспективная нервотрепка. Выкинуть все и написать заново- авантюра, даже если выделят ресурсы. Постепенно переписывать легаси, отпочковывая от него сервисы и постоянно поддерживая совместимость — задача зачастую на годы. Не все осилят этот путь. А если и осилят, то в конце пути вам вместо награды вручат еще одно легаси ))

Всё правильно, поэтому это стоит дорого. А чтобы расти среди профессионалов — можно и немного подвинуться по деньгам, иногда

Здравствуйте, vsb, Вы писали:

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

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

vsb>В NASA, наверное, эта планка на уровне доктора наук.
Смешно мне с такого.

Здравствуйте, SkyDance, Вы писали:

mgu>>...и узкой областью применения.

SD>Напротив. Красивый, краткий, понятный код, делающий ровно то, что нужно, без протечек абстракций, имеет самую широкую область применения. Как кирпич, строительный блок.

Ну да. А чем соединять эти блоки? Интерфейсами же.

mgu>>Промышленный же код выполняет огромное количество задач, пишется коллективно, и код по определению не может быть маленьким.

SD>Это плохой код. Который "выполняет огромное количество задач". См. "God object" антипаттерн. Код, если он не маленький по определению, или плохо написан, или написан на неподходящей платформе (скажем, на ассемблере вместо РНР), или сделан в виде "огранического роста". Когда вместо архитектуры есть просто наслоения бизнес-логики "а сейчас нам понадобилось вот это", раковой опухолью разросшееся всюду. Без рефакторинга, без снижения сложности, без выделения общих сущностей и т.п..

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

mgu>>Именно слои и помогают структурировать массив кода и избегать нежелательных взаимодействий.

SD>Только при условии, что эти слои железными руками и в ежовых рукавицах держит кто-то очень хорошо понимающий, к каким последствиям ведут leaky abstractions. Это еще возможно в маленьких конторах, или где уже есть устоявшийся поток денег. Но никак не в стартапах (где главное — быстрее), или в больших компаниях, где политика попросту не позволяет существовать самой роли подобного архитектора.

Я с такими архитекторами взаимодействовал, они существуют.

SD>>>И нет, не всегда это был тот же программист, что изначально разработал систему. Это были другие, те, кто "имеют знания о слоистости и интерфейсах".
mgu>>Системы не пишут в одиночку. Более того, зачастую неизвестно, кто и каким образом будет подхватывать данные и затем их использовать для своих нужд. Поэтому без интерфейсов никак.

SD>Это вообще к чему? Сравнение шло между "простым и кратким кодом" (который якобы "врожденный талант" дает), и "промышленным антиподом" — спагетти и лазаньей (со слоями же, да?) одновременно.

А откуда взялись спагетти? Чуть выше в качестве слоёв вы обсуждали абстракции. Код в вакууме не имеет значения, поэтому я рассматриваю весь код в масштабе приложения. Лазанья -- это уже клинический случай слоистости, я про здоровое использование. Если у вас CRUD, то даже в маленьком уютном коде, как вы обойдётесь без слоёв? С другой стороны, я в ступоре от повсеместного использования слоя ORM в высоконагруженных промышленных приложениях.

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

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

Здравствуйте, Gradiens, Вы писали:

G>А есть и другая мысль: Мне неинтересно чувствовать себя самым крутым, потому что эта крутизна только в пределах своего уютного (или не очень) болота. Вот я хочу расти в окружении профессионалов. Тогда расти буду в разы быстрее.

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

G>Кроме того, "приводить все в порядок" может быть очень нервно затратно. И вообще, может быть нереально. То есть, поддерживать текущее легаси — бесперспективная нервотрепка. Выкинуть все и написать заново- авантюра, даже если выделят ресурсы. Постепенно переписывать легаси, отпочковывая от него сервисы и постоянно поддерживая совместимость — задача зачастую на годы. Не все осилят этот путь. А если и осилят, то в конце пути вам вместо награды вручат еще одно легаси ))

Так в этом весь смысл! Именно под неспешное переписывание и можно выбить ресурсы. Все программные задачи уже давно решены, либо же собираются Питоном из библиотек.

G>Хотя косвенно обычно можно по уровню вопросов понять уровень знаний интервьювера, его кругозор.

Почему же косвенно? 80% интервьюеров черпают список вопросов из интернета, там же добывают и свой код.

Здравствуйте, B0FEE664, Вы писали:

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

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

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

Люто плюсую.

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

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

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

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

*Миля -- абстрактная единица.

Здравствуйте, gyraboo, Вы писали:

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

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

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

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

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

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

Здравствуйте, B0FEE664, Вы писали:

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

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

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

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

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

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

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

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

Здравствуйте, gyraboo, Вы писали:

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

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

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

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

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

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

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

Здравствуйте, 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>Вот поэтому я и говорю, что абстакция никак не связаны со сложностью чтения, т.к. абстракция может как упрощать, так и усложнять чтение кода. Если задача сложная, то абстракция может упростить код, если задача простая, то абстракция может усложнить код.

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

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

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

Здравствуйте, B0FEE664, Вы писали:

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

три раза в день, например

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

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

mgu>>int age = 33;

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

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

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

Age age = 33;

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

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

Здравствуйте, vsb, Вы писали:

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

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

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

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

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

P.S. В NASA (предполагаю) разработку ещё пару лет будут тестировать.

Здравствуйте, gyraboo, Вы писали:

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

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

Здравствуйте, Sharov, Вы писали:

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

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

А, ясно. Не знал такого термина, поэтому не заметил.

Здравствуйте, gyraboo, Вы писали:

G>А, ясно. Не знал такого термина, поэтому не заметил.

https://en.wikipedia.org/wiki/Leaky_abstraction

Здравствуйте, gyraboo, Вы писали:

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

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

Нет. Объекты вообще могут быть без базовых классов, без наследования.

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

Нет, абстракция может быть функцией без объекта. Типичный пример — это функция сортировки, которая в качестве параметра берёт оператор сравнения сортируемых объектов. В С++ это std::sort. В общепринятой терминологии такие функции называют обобщёнными, чтобы отличать их от виртуальных. Однако следует ясно понимать, что и те и другие позволяет реализовать полиморфизм, а значит работать с объектами на абстрагированном уровне.

G>К сожалению ты не понял мою мысль, а я не могу её донести.
Я прекрасно понимаю, что вы пытаетесь сказать, но я так же понимаю и Умака Кумакаки.

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

Если число абстракций превышает число деталей реализации, тогда абстракция усложняет код.

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

BFE>>Вы понимаете, что с какой планкой в компании будут работать только начинающие программисты?
mgu>В многоклеточной компании существует разделение труда.
mgu>А мне грустно: проскакивала информация, что в Гугле яйцеголовых бросают на цензурирование высказываний в Ютубе.

Такое впечатление, что ваше подсознание не даёт вам понять то, что вы знаете.

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

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

Понятно. А вот в конторе, где я сейчас работаю, три ошибки в неделю на всю немаленькую команду и то, через месяц тестирования ошибки кончились.

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


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

mgu>Так в этом весь смысл! Именно под неспешное переписывание и можно выбить ресурсы. Все программные задачи уже давно решены, либо же собираются Питоном из библиотек.
Ты пробовал выбивать ресурсы под неспешное переписывание?
Если программные задачи уже решены, нафига переписывать-то? Ресурсов не дадут. А даже наоборот, отнимут.
А вот если задачи в бэклоге плодятся как кролики, если команда больше половины времени разгребает инциденты, если проект сменил несколько поколений разрабов и никто реально не понимает, ка он работает — вот тогда как раз и нужно переписывать.
Но переписывать не дадут. А если датут — то выделят, скажем, год на переписывания системы, которую писали 15 лет. И это будет заведомо провальный проект.
Но можно сцепив зубы постепенно отпиливать кусочки от существующего монолита. Или распределенного монолита. Постоянно выбивая у бизнеса ресурсы на рефакторинг и доказывая что когда-нибудь это сократит поток инцидентов и time-to-market. И это можно сделать. Все можно. Только где вот тут неспешность?

Здравствуйте, Gradiens, Вы писали:

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

Нет ресурсов -- нет фронта работ. Есть ресурсы -- перетасовываем кнопки, это недолго.

mgu>>Так в этом весь смысл! Именно под неспешное переписывание и можно выбить ресурсы. Все программные задачи уже давно решены, либо же собираются Питоном из библиотек.
G>Ты пробовал выбивать ресурсы под неспешное переписывание?

Винчестер выбить не могу. Но я не специалист по выбиванию.

G>Если программные задачи уже решены, нафига переписывать-то? Ресурсов не дадут. А даже наоборот, отнимут.
G>А вот если задачи в бэклоге плодятся как кролики, если команда больше половины времени разгребает инциденты, если проект сменил несколько поколений разрабов и никто реально не понимает, ка он работает — вот тогда как раз и нужно переписывать.

Нужно, но личный состав озадачен, и для начальника выгоднее выбить ещё штатные единицы. А вот когда стихает канонада, тогда нужно что-то изображать, можно и попереписывать.

G>Но переписывать не дадут. А если датут — то выделят, скажем, год на переписывания системы, которую писали 15 лет. И это будет заведомо провальный проект.
G>Но можно сцепив зубы постепенно отпиливать кусочки от существующего монолита. Или распределенного монолита. Постоянно выбивая у бизнеса ресурсы на рефакторинг и доказывая что когда-нибудь это сократит поток инцидентов и time-to-market. И это можно сделать. Все можно. Только где вот тут неспешность?

А это смотря как взяться и как отчитываться. А год на 15-летнюю систему -- реально, ведь писали-то вслепую, 2 шага вперёд, один шаг назад.

G> А если и осилят, то в конце пути вам вместо награды вручат еще одно легаси ))

Печальный и непреложный факт

mgu>int -- это абстракция, возраст обычно не превышает 120 лет, понадобятся проверки. А можно и чисто конкретно:
mgu>Age age = new Age(33);

Всегда удивляло, почему ратующие за подобную типизацию товарищи все еще не перешли на Haskell или OCAml. Упорно продолжают грызть не приспособленный для этого кактус, и хорошо еще если это Java, а не C++.

Здравствуйте, SkyDance, Вы писали:

mgu>>int -- это абстракция, возраст обычно не превышает 120 лет, понадобятся проверки. А можно и чисто конкретно:
mgu>>Age age = new Age(33);

SD>Всегда удивляло, почему ратующие за подобную типизацию товарищи все еще не перешли на Haskell или OCAml. Упорно продолжают грызть не приспособленный для этого кактус, и хорошо еще если это Java, а не C++.

А зачем? Статическая типизация есть статическая типизация. Ну перейдут они на ФП, будут грызть кактус другого порядка.
Сильно не факт, что слаще.

Здравствуйте, SkyDance, Вы писали:

mgu>>int -- это абстракция, возраст обычно не превышает 120 лет, понадобятся проверки. А можно и чисто конкретно:
mgu>>Age age = new Age(33);

SD>Всегда удивляло, почему ратующие за подобную типизацию товарищи все еще не перешли на Haskell или OCAml.

Это был абстрактный пример.

SD>Упорно продолжают грызть не приспособленный для этого кактус, и хорошо еще если это Java, а не C++.

А сейчас даже стало интересно: чем такой код на Джаве лучше, чем на С++?

Здравствуйте, SkyDance, Вы писали:

SD>В значительной мере это self-inflicted wound: отсутствие специалиста по маркетингу, который будет "продавать" бизнесу объяснение, что именно дает рефакторинг. Продавать в терминах, понятных этому бизнесу. Одна из реально сложных проблем для инженеров: объяснить с цифрами в руках, как много убытков наносит кривизна здесь, корявость там, и тормоза вот в этом месте.
SD>Но найти таких маркетологов сложно, и еще сложнее убедить бизнес в том, чтобы этого маркетолога нанять.

Да кого волнует эта корявость? В наши дни ресурсы на рефакторинг выбивают, когда личному составу заняться нечем. А сдувать штат чревато.

S>А зачем? Статическая типизация есть статическая типизация. Ну перейдут они на ФП, будут грызть кактус другого порядка.

Когда сам язык изначально не был предназначен для статической типизации, добавление таковой путем наслоения новых конструкций не добавляет элегантности. Скорее, напротив, становится камнем на шее, только мешающим. И инструментировать такое сложнее, и то что компилятор должен быть навороченнее — не добавляет удобства.

Другое дело если язык изначально разрабатывается с учетом требований статической типизации. Тот же ocaml, базирующийся на type inference (только не надо про 'auto' в С++, это не одно и то же, — уже даже сама необходимость писать тип auto убивает половину смысла).

mgu>Да кого волнует эта корявость? В наши дни ресурсы на рефакторинг выбивают, когда личному составу заняться нечем. А сдувать штат чревато.

Очень сильное заявление!
Где-то рядом по силе с "кого в наши дни интересует производительность", а также "зачем нужны разработки новых алгоритмов, все уже изобретено".

Хорошо, что мне никогда не придется работать с руководством, которое могло бы делать подобные заявления.

Здравствуйте, SkyDance, Вы писали:

S>>А зачем? Статическая типизация есть статическая типизация. Ну перейдут они на ФП, будут грызть кактус другого порядка.
SD>Когда сам язык изначально не был предназначен для статической типизации, добавление таковой путем наслоения новых конструкций не добавляет элегантности. Скорее, напротив, становится камнем на шее, только мешающим. И инструментировать такое сложнее, и то что компилятор должен быть навороченнее — не добавляет удобства.

О каком языке идет речь, smalltalk или питоне? Потому как ява/цпп/c# изначально разрабатывались статическими ООП языками.

Здравствуйте, SkyDance, Вы писали:

mgu>>Да кого волнует эта корявость? В наши дни ресурсы на рефакторинг выбивают, когда личному составу заняться нечем. А сдувать штат чревато.

SD>Очень сильное заявление!
SD>Где-то рядом по силе с "кого в наши дни интересует производительность", а также "зачем нужны разработки новых алгоритмов, все уже изобретено".

SD>Хорошо, что мне никогда не придется работать с руководством, которое могло бы делать подобные заявления.

По плодам их узна́ете их. А заявляет начальство обычно про то, что через пару лет "мы порвём Майкрософт", ещё 40 тысяч вёдер, и золотой ключик у нас в кармане!

Здравствуйте, SkyDance, Вы писали:

mgu>>По плодам их узна́ете их. А заявляет начальство обычно про то, что через пару лет "мы порвём Майкрософт", ещё 40 тысяч вёдер, и золотой ключик у нас в кармане!

SD>К счастью, моему начальству делать такие заявления не требуется. Ибо наш продукт действительно не только лучший, но и самый сильный на рынке. Майкрософту не светит.

Шо за продукт?

Здравствуйте, kaa.python, Вы писали:

KP>Ваш продукт редкостное УГ, которым приходится пользоваться исключительно из-за того что на нём куча народу сидит.

Для меня парадокс, что видео звонки де-факто это скайп, причём корпоративный teams тоже видео через скайп гонит. Почему вацап, который де-факто замена sms, непопулярен для видео?
К скайпу видео у меня претензия, что 1080p60 виртуальную камеру obs он не переваривает, по крайней мере на линуксе. А вацап переваривает, интересно?

Здравствуйте, SkyDance, Вы писали:

KP
SD>Есть аналогичные, в чем-то превосходящие — например, Signal объективно предоставляет чуть больше privacy.

Закрытый протокол, с разработчиками что мамой клянутся будто там всё безопасно, еула где явно прописана передача данных ФБ теперь стала учить меньше privacy? Ну прям совсем чуть-чуть в сравнении с Сигналом, ага

Здравствуйте, Тёмчик, Вы писали:

Тё>Для меня парадокс, что видео звонки де-факто это скайп, причём корпоративный teams тоже видео через скайп гонит. Почему вацап, который де-факто замена sms, непопулярен для видео?

У меня мама WhatsApp любит, все её подружки там. Так что всё звонки только через него.

Кстати, у Телеграмма видеозвонки текут, через минут 10 видео звонка он сначала начинает адово лагать, а потом просто падает. Тоесть WhatsApp как бы и говно, но по совокупности параметров выходит лучше чем конкуренты. Хотя для текста он на 100% сливает телеге.

KP>Закрытый протокол, с разработчиками что мамой клянутся будто там всё безопасно, еула где явно прописана передача данных ФБ теперь стала учить меньше privacy? Ну прям совсем чуть-чуть в сравнении с Сигналом, ага

WhatsApp и Signal используют один и то же протокол, и даже одну и ту же реализацию. Вот эту: https://github.com/signalapp/libsignal-protocol-c
В чем ты можешь убедиться, декомпилировав официальные клиенты, или написав свой, или вовсе просто перехватывая трафик внутри приложения.

"Передача данных в ФБ" или куда угодно еще не меняет факта: все коммуникации проходят через сквозное шифрование. Это ж не Телеграм, где общение идет открытым текстом, за исключением редчайшего сценария 1:1 сообщений в специальном приватном чате.