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

On 12.01.2013 14:41, Аноним 208 wrote:

> В ИТ около 15 лет, был ~6 конторах, ни разу не слышал чтобы хоть раз
> чей-нибудь код называли хорошим, только и слышно здесь говно, там говно.
Видел. Правда это был код американской конторы, хоть программисты и в
Минске были и в Америке. Просто в том коде поучаствовал и Скотт Майерс.

Здравствуйте, Аноним, Вы писали:

А>В ИТ около 15 лет, был ~6 конторах, ни разу не слышал чтобы хоть раз чей-нибудь код называли хорошим, только и слышно здесь говно, там говно.
А>Даже нет у него в отличие от говнокода названия своего, там вареньекод, медокод.
говно вокруг, везде говно, все это логично — системы, которые сейчас в Москве дорабатывают, созданы в 90, 00-ые, никто писать не умел тогда

А>Если знаете какой-нибудь опенсорс или есть свой код в интернете пришлите ссылочку посмаковать, хоть раз взглянуть на это чудо которое не назовут говном.
адъ и погибель, я пытаюсь vmime собрать с зависимостями, такого треша я не видел, а это работает

Здравствуйте, Аноним, Вы писали:

А>В ИТ около 15 лет, был ~6 конторах, ни разу не слышал чтобы хоть раз чей-нибудь код называли хорошим, только и слышно здесь говно, там говно.
А>Даже нет у него в отличие от говнокода названия своего, там вареньекод, медокод.
А>Если знаете какой-нибудь опенсорс или есть свой код в интернете пришлите ссылочку посмаковать, хоть раз взглянуть на это чудо которое не назовут говном.

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

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

RW>Здравствуйте, Аноним, Вы писали:

А>>В ИТ около 15 лет, был ~6 конторах, ни разу не слышал чтобы хоть раз чей-нибудь код называли хорошим, только и слышно здесь говно, там говно.
А>>Даже нет у него в отличие от говнокода названия своего, там вареньекод, медокод.
RW>говно вокруг, везде говно, все это логично — системы, которые сейчас в Москве дорабатывают, созданы в 90, 00-ые, никто писать не умел тогда
Тоже самое будут говорить про 2010 -- стиль сменился. Зато в 2030 все будут говорить какие были классные программеры в 2000ных -- на таком говне мамонта писали, такие сложные вещи, а у нас на 100500 ядерных машинах перерисовка окошек тормозит.

Здравствуйте, Аноним, Вы писали:

А>В ИТ около 15 лет, был ~6 конторах, ни разу не слышал чтобы хоть раз чей-нибудь код называли хорошим, только и слышно здесь говно, там говно.
А>Даже нет у него в отличие от говнокода названия своего, там вареньекод, медокод.
А>Если знаете какой-нибудь опенсорс или есть свой код в интернете пришлите ссылочку посмаковать, хоть раз взглянуть на это чудо которое не назовут говном.
Я, наоборот, настоящий "говнокод" видел только от студентов, остальное укладывалось в стилистические корреляции.

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

D>Я, наоборот, настоящий "говнокод" видел только от студентов, остальное укладывалось в стилистические корреляции.
Флуктуации, в смысле

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

А>>>Даже нет у него в отличие от говнокода названия своего, там вареньекод, медокод.
RW>>говно вокруг, везде говно, все это логично — системы, которые сейчас в Москве дорабатывают, созданы в 90, 00-ые, никто писать не умел тогда
D>Тоже самое будут говорить про 2010 -- стиль сменился. Зато в 2030 все будут говорить какие были классные программеры в 2000ных -- на таком говне мамонта писали, такие сложные вещи, а у нас на 100500 ядерных машинах перерисовка окошек тормозит.

естественный ход событий

Здравствуйте, Аноним, Вы писали:

А>В ИТ около 15 лет, был ~6 конторах, ни разу не слышал чтобы хоть раз чей-нибудь код называли хорошим, только и слышно здесь говно, там говно.
А>Даже нет у него в отличие от говнокода названия своего, там вареньекод, медокод.
А>Если знаете какой-нибудь опенсорс или есть свой код в интернете пришлите ссылочку посмаковать, хоть раз взглянуть на это чудо которое не назовут говном.


На мой взгляд код 7-zip и nginx хороший.

Здравствуйте, Аноним, Вы писали:

А>В ИТ около 15 лет, был ~6 конторах, ни разу не слышал чтобы хоть раз чей-нибудь код называли хорошим, только и слышно здесь говно, там говно.
Сам говно не пишу и сотрудников проверяю.. Это ж стиль вырабатывается. Ответственность не только перед собой, но и тем кто будет его смотреть. Легкое г видел.. исправлял.. с полным не встречался..

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

RW>естественный ход событий
Но так было и будет всегда, с новым годом, друзья, с новым годом (С).

Здравствуйте, <Аноним>, Вы писали:

А>В ИТ около 15 лет, был ~6 конторах, ни разу не слышал чтобы хоть раз чей-нибудь код называли хорошим, только и слышно здесь говно, там говно.
А>Даже нет у него в отличие от говнокода названия своего, там вареньекод, медокод.
А>Если знаете какой-нибудь опенсорс или есть свой код в интернете пришлите ссылочку посмаковать, хоть раз взглянуть на это чудо которое не назовут говном.

Навскидку:

1. kakadu jpeg2000 library
2. helix AAC Fixed point decoder
3. CT HE AAC + SBR+ Parametric stereo encoder.
4. boost uBLAS library (в бусте хватает хороших либ)
5. приятности есть (не все) в исходниках Half Life 2
6. некоторые либы NVIDIA
... и т.д

ССылки легко в гугле найти.

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

1>На мой взгляд код 7-zip и nginx хороший.

7-zip? в каком месте он там хороший, в С/ или СPP/ ?

вообще С код не может быть хорошим по-определению,
а С++ код там от С недалеко ушел.
хотя там где COM интерфейсы его можно объяснить ограничениями COM (хотя зачем там вообще COM?).

собственно catch(int) в main() сразу намекает на качество кода

Здравствуйте, Аноним, Вы писали:

А>В ИТ около 15 лет, был ~6 конторах, ни разу не слышал чтобы хоть раз чей-нибудь код называли хорошим, только и слышно здесь говно, там говно.
А>Даже нет у него в отличие от говнокода названия своего, там вареньекод, медокод.
А>Если знаете какой-нибудь опенсорс или есть свой код в интернете пришлите ссылочку посмаковать, хоть раз взглянуть на это чудо которое не назовут говном.

Нет такого, по многим причинам. А тебе посоветую читать все подряд. Просто идешь на github\codeplex\ещекуданить, ищешь интересные тебе проекты и начинаешь разбираться.

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

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

1>>На мой взгляд код 7-zip и nginx хороший.

A>7-zip? в каком месте он там хороший, в С/ или СPP/ ?

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

A>а С++ код там от С недалеко ушел.
A>хотя там где COM интерфейсы его можно объяснить ограничениями COM (хотя зачем там вообще COM?).
А Вы, что считаете единственно верным оплотом качества?

A>собственно catch(int) в main() сразу намекает на качество кода
Мне как то не намекает вообще. Если в рамках проекта используется один стиль исключений, или от него отходят только в небольших участках — это нормально.
И использовать int для кода работающего в ОС возвращаюшей коды ошибок вполне разумно.

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

1>А Вы, что считаете единственно верным оплотом качества?
критериями —
безопасность (в т.ч. type-safety, отсутствие двойной инициализации, etc),
отсутствие лишнего кода (соблюдение DRY, YAGNI, SRP; использование RAII вместо ручных вызовов free и т.п.),
SOLID дизайн,
удобство поддержки кода, в т.ч. удобство отладки — исключения вместо возврата ошибок


A>>собственно catch(int) в main() сразу намекает на качество кода
1>Мне как то не намекает вообще. Если в рамках проекта используется один стиль исключений, или от него отходят только в небольших участках — это нормально.
1>И использовать int для кода работающего в ОС возвращаюшей коды ошибок вполне разумно.
в С++ это ненормально.

Здравствуйте, Аноним, Вы писали:
А>В ИТ около 15 лет, был ~6 конторах, ни разу не слышал чтобы хоть раз чей-нибудь код называли хорошим, только и слышно здесь говно, там говно.
А>Даже нет у него в отличие от говнокода названия своего, там вареньекод, медокод.
из опенсорсного
в качестве примера гавна я обычно привожу Miranda IM
как пример негавна — Chromium

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

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

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

1>>А Вы, что считаете единственно верным оплотом качества?
A>критериями —
A>безопасность (в т.ч. type-safety, отсутствие двойной инициализации, etc),
A>отсутствие лишнего кода (соблюдение DRY, YAGNI, SRP; использование RAII вместо ручных вызовов free и т.п.),
A>SOLID дизайн,
A>удобство поддержки кода, в т.ч. удобство отладки — исключения вместо возврата ошибок
Перефразирую свой вопрос — есть ли конкрентые примеры, того, что Вы считаете хорошим кодом, где с ними можно ознакомится?


A>>>собственно catch(int) в main() сразу намекает на качество кода
1>>Мне как то не намекает вообще. Если в рамках проекта используется один стиль исключений, или от него отходят только в небольших участках — это нормально.
1>>И использовать int для кода работающего в ОС возвращаюшей коды ошибок вполне разумно.
A>в С++ это ненормально.
Инструмент должен давать возможность, а не ограничения. В С++ это возможно, и нормально. При выше озвученых условиях.
Если хочется что бы объектом было вообще все — есть другие языки.

PS. Я за собой не припоминаю использования таких исключений.

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

1>Перефразирую свой вопрос — есть ли конкрентые примеры, того, что Вы считаете хорошим кодом, где с ними можно ознакомится?

да что-то не припоминаю.
в LLVM есть много хорошего, но там запрещены исключения,

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

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

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

1>>Перефразирую свой вопрос — есть ли конкрентые примеры, того, что Вы считаете хорошим кодом, где с ними можно ознакомится?

A>да что-то не припоминаю.
A>в LLVM есть много хорошего, но там запрещены исключения,

A>libtorrent-rasterbar вроде ничего так выглядит, но там опять же поддерживается BOOST_NO_EXCEPTIONS, а значит в реализации нет исключений,
A>к тому же там для сообщений об ошибках используется std::string, за что я на них очень зол

Возможно это связано с нереализуемостью Ваших требований в реальном мире.

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

A>к тому же там для сообщений об ошибках используется std::string, за что я на них очень зол

Расжуйте , любопытно отчего?

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

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

A>>к тому же там для сообщений об ошибках используется std::string, за что я на них очень зол

M>Расжуйте , любопытно отчего?

там есть структура torrent_status — состояние торрента,
а у нее член std::string error; — текст ошибки, если торрент остановился из за ошибки.
(кода ошибки нету, только bool paused и string error)

выглядит этот текст например так:
Access denied: path\to\file

а в не-английской винде он выглядит так

Доступ запрещен: путь\к\файлу
^cp1251          ^cp866

т.е. разные части std::string в разных кодировках

разумеется если в пути к файлу есть например еще и китайские символы, то все совсем печально

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

1>На мой взгляд код 7-zip

Это он так маскируется. А когда начинаешь его использовать как библиотеку начинает вылазить всякое:
— документация отсутствует в принципе;
— ленивые потоки поддерживаются очень и очень ограниченным количество архиваторов (архиватор здесь и далее — модуль библиотеки) (split и доступаторы к образам файловых систем), остальные приходится тупо извлекать, хотя казалось бы;
— открытие многотомного 7-zip архива и вообще любого архива засунутого в split происходит через одно место, в общем коде "либы" этого нет, приходится писать-копипастить "по мотивам";
— если сходу реализовать у себя интерфейс необходимый для многотомныех архивов, отвалится кто-то из однотомных;
— если вдруг понадобилось узнать время файла в архиве и его тип (универсальное или глобальное), прийдется внимательно читать код каждого конкретного архиватора, а для zip'а, который может сохранять время в виде FAT-, NTFS- и UNIX-времени писать толпу триков, потому что 7zip "услужливо" приводит время к "нужному" нам виду и его приходится потом возвращать в исходный вид;
— и еще что-то, что уже забылось.

Нет, конечно, спасибо автору, за то что выполнил столько грязной работы и собрал кучу разношерстного опенсор-г*на в одну библиотеку, но назвать это хорошим кодом — слишком смело.

1>и nginx хороший

Я как-то специально выделил час на то чтобы осмотреть код и составить поверхностное впечатление о проекте (вопрос интеграции с ним тогда прямо не стоял, но намечался). Итог: "ничё не понятно, многа буков, где спеки".

Если уж приводить пример хорошего, то в опенсорсе это OpenSSL и ICU: нормальное качество кода, хорошо проработанное API.

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

AK>Здравствуйте, 11molniev, Вы писали:

1>>На мой взгляд код 7-zip

AK>Это он так маскируется. А когда начинаешь его использовать как библиотеку начинает вылазить всякое:
AK>- документация отсутствует в принципе;
AK>- ленивые потоки поддерживаются очень и очень ограниченным количество архиваторов (архиватор здесь и далее — модуль библиотеки) (split и доступаторы к образам файловых систем), остальные приходится тупо извлекать, хотя казалось бы;
AK>- открытие многотомного 7-zip архива и вообще любого архива засунутого в split происходит через одно место, в общем коде "либы" этого нет, приходится писать-копипастить "по мотивам";
AK>- если сходу реализовать у себя интерфейс необходимый для многотомныех архивов, отвалится кто-то из однотомных;
AK>- если вдруг понадобилось узнать время файла в архиве и его тип (универсальное или глобальное), прийдется внимательно читать код каждого конкретного архиватора, а для zip'а, который может сохранять время в виде FAT-, NTFS- и UNIX-времени писать толпу триков, потому что 7zip "услужливо" приводит время к "нужному" нам виду и его приходится потом возвращать в исходный вид;
AK>- и еще что-то, что уже забылось.

AK>Нет, конечно, спасибо автору, за то что выполнил столько грязной работы и собрал кучу разношерстного опенсор-г*на в одну библиотеку, но назвать это хорошим кодом — слишком смело.
Ну я имел в виду не sdk, а сам 7-zip. Хотя если честно, я не пробовал особо его использовать — просто заинтересовался и поверхностно познакомился с кодом.

1>>и nginx хороший

AK>Я как-то специально выделил час на то чтобы осмотреть код и составить поверхностное впечатление о проекте (вопрос интеграции с ним тогда прямо не стоял, но намечался). Итог: "ничё не понятно, многа буков, где спеки".
Ну там везде все свое и на первый взгляд, да, разобратся тяжеловато. Но в целом сам код вопросом не вызывает. Я в свое время интегрировал))

AK>Если уж приводить пример хорошего, то в опенсорсе это OpenSSL и ICU: нормальное качество кода, хорошо проработанное API.
По поводу OpenSSL согласен, как то не вспомнил. С ICU не сталкивался.

Мне код Qt очень понравился. Как самого фреймворка, так и созданных с его помощью идущих в комплекте тулзов — Designer, Creator.

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

V>On 12.01.2013 14:41, Аноним 208 wrote:

>> В ИТ около 15 лет, был ~6 конторах, ни разу не слышал чтобы хоть раз
>> чей-нибудь код называли хорошим, только и слышно здесь говно, там говно.
V>Видел. Правда это был код американской конторы, хоть программисты и в
V>Минске были и в Америке. Просто в том коде поучаствовал и Скотт Майерс.
Эпично. Самому вместе с ним не довелось работать?

On 14.01.2013 13:58, Kernan wrote:

> Эпично. Самому вместе с ним не довелось работать?
Лично нет.

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

>> В ИТ около 15 лет, был ~6 конторах, ни разу не слышал чтобы хоть раз
>> чей-нибудь код называли хорошим, только и слышно здесь говно, там говно.
V>Видел. Правда это был код американской конторы, хоть программисты и в
V>Минске были и в Америке. Просто в том коде поучаствовал и Скотт Майерс.

Ты про тот проект, что я думаю? Ну не скажи, не скажи. Местами там перебор.

On 15.01.2013 3:07, ambel-vlad wrote:

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

А>Если знаете какой-нибудь опенсорс или есть свой код в интернете пришлите ссылочку посмаковать, хоть раз взглянуть на это чудо которое не назовут говном.
Java Collections, Guava, Spring Framework 3.x, ...

Здравствуйте, Аноним, Вы писали:

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

Во FreeBSD можно посмотреть исходники базовых утилит вроде cp/ls/rm и т.п. Не помню, как оно там правильно зовется. То ли world, то ли все же нет. Лет 7-8 назад там все было очень и очень хорошо. Смотреть именно из FreeBSD, если они реализацию на GNU-шную еще не поменяли.

Я в те исходники случайно залез. На линуке rm отказался удалять файл больше 4Гб, писал "cannot stat file". Я очень удивился еще, ведь там вроде всего пара системных вызовов, которые на размер файла не завязаны. Полез смотреть в код. В BSD там все было аккуратно, красиво и кратко. В GNU rm началось с какой-то кучи больших и страшных макросов, я испугался и все закрыл достаточно быстро.

Здравствуйте, Аноним, Вы писали:

А>В ИТ около 15 лет, был ~6 конторах, ни разу не слышал чтобы хоть раз чей-нибудь код называли хорошим, только и слышно здесь говно, там говно.
А>Даже нет у него в отличие от говнокода названия своего, там вареньекод, медокод.
А>Если знаете какой-нибудь опенсорс или есть свой код в интернете пришлите ссылочку посмаковать, хоть раз взглянуть на это чудо которое не назовут говном.
Любой код кроме своего, априори — говно

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

A>

A>Доступ запрещен: путь\к\файлу
A>^cp1251          ^cp866
A>

A>т.е. разные части std::string в разных кодировках

на самом деле путь\к\файлу там в utf-8.
в версии 0.16.7 это пофиксили и вся строка в utf-8.

A>Любой код кроме своего, априори — говно

Читаю свой код 2003 года, такое г...о, что самому стыдно.

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

V>А русский код — индусы отдыхают. Пример, парсить RIFF WAV шапку
V>сдвигами.
Можешь пояснить как это?

On 21.01.2013 10:57, Kernan wrote:

> Можешь пояснить как это?
Не могу, ибо код проприетарный. С так да, чел зачитывал 44 байта (что
уже неверно в общем случае) и разбирал их сдвигами. Когда я это увидел,
у меня глаза округлились. Сейчас этот чел вполне успешно работает
программистом где-то в нерезиновой.

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

V>On 21.01.2013 10:57, Kernan wrote:

>> Можешь пояснить как это?
V>Не могу, ибо код проприетарный. С так да, чел зачитывал 44 байта (что
V>уже неверно в общем случае) и разбирал их сдвигами. Когда я это увидел,
V>у меня глаза округлились. Сейчас этот чел вполне успешно работает
V>программистом где-то в нерезиновой.
Да я просто про подход спрашивал. Как это разбирать сдвигами? Можешь псевдокод привести? И как это правильнее сделать до кучи. Никакой конкретики по проекту не надо. Просто я видел разные способы разбора бинарных данных и хочется пополнить арсенал .

On 21.01.2013 11:26, Kernan wrote:

> Да я просто про подход спрашивал. Как это разбирать сдвигами? Можешь
> псевдокод привести? И как это правильнее сделать до кучи. Никакой
> конкретики по проекту не надо. Просто я видел разные способы разбора
> бинарных данных и хочется пополнить арсенал .
formatTag+=(unsigned char)chBuff[l]*1<<8
что было переделано на:
formatTag+=(unsigned char)chBuff[l]*256

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

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

1>>Перефразирую свой вопрос — есть ли конкрентые примеры, того, что Вы считаете хорошим кодом, где с ними можно ознакомится?

A>да что-то не припоминаю.
A>в LLVM есть много хорошего, но там запрещены исключения,

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

Например, помните вызова типа clang -march=help что печатают список процессоров?

Это реализовано через анус: когда инициализируется процессор, то вместо собственно инициализации архитектуры help
оно печатает список процессоров в std::cerr и завершает работу.

То есть если вы захотите убийцу IDA с гуем, которой даёт выбрать процессор то во-первых хрен вы получите список процессоров не через задницу, во-вторых если в .ini файле вам введут "help" как тип процессор, то прога завалиться если вы специально не будете проверять на то, что там передается "help".

https://github.com/llvm-mirror/llvm/blob/master/lib/MC/SubtargetFeature.cpp

Смотреть getFeatureBits и Help.

Меня никто не убедит что getFeatureBits'у простительно писать список фич в cerr. getFeatureBits() за это не должно отвечать.

Здравствуйте, Аноним, Вы писали:

А>В ИТ около 15 лет, был ~6 конторах, ни разу не слышал чтобы хоть раз чей-нибудь код называли хорошим, только и слышно здесь говно, там говно.
А>Даже нет у него в отличие от говнокода названия своего, там вареньекод, медокод.
А>Если знаете какой-нибудь опенсорс или есть свой код в интернете пришлите ссылочку посмаковать, хоть раз взглянуть на это чудо которое не назовут говном.

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

M>4. boost uBLAS library (в бусте хватает хороших либ)

boost uBLAS детскими болезнями страдает

Автор: nen777w
Дата: 17.08.12

К сожалению мне пришлось от него отказаться в пользу либ из umfpack.

В Qt ничего такой. Может там и есть говно, но интерфейсы его прячут хорошо.

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

M>>4. boost uBLAS library (в бусте хватает хороших либ)

N>boost uBLAS детскими болезнями страдает

Автор: nen777w
Дата: 17.08.12

К сожалению мне пришлось от него отказаться в пользу либ из umfpack.

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

On 29.01.2013 19:17, nen777w wrote:

> boost uBLAS детскими болезнями страдает
> <http://rsdn.ru/forum/cpp.applied/4859519&gt;

Автор: nen777w
Дата: 17.08.12

К сожалению мне пришлось от
> него отказаться в пользу либ из umfpack.
Я Armadilo использую.

Здравствуйте, Аноним, Вы писали:

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

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

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

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

Соответственно, у нас есть два состояния кода.
1. "Это говнокод.".
2. "Это же говнокод. Тут всё надо переписать".

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

Самое крупное переписывание (7-и значные долларовые суммы up to date), которое я видел лично, было вызвано неприятием функционального программирования на шаблонах С++ а ля mpl/Loki. В результате получено менее технологичное решение (без автоматической кодогенерации кода БД по декларативному xml описанию), так к тому же до сих пор и не внедрённое, так что затраты ещё вырастут.

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

1>На мой взгляд код 7-zip и nginx хороший.

Nginx — образец проблем, которые получаются, если делать всё вручную. Например, большинство директив в файле конфигурации не понимают переменные (нельзя сказать error_log /path/$some_var_depending_on_host/whatever.log) — казалось бы, должен быть некий централизованный механизм, но нет, парсер каждой директивы сам занимается разбором аргументов, причем полностью в ручном режиме, даже без грамматики. Я уверен, что приделать любую новую фичу к nginx — всё равно, что искать иголку в стоге заряженных граблей, нацеленных в ноги (или это не то сравнение?). Один if чего стоит, с миллионом подлых глюков.

А>В ИТ около 15 лет, был ~6 конторах, ни разу не слышал чтобы хоть раз чей-нибудь код называли хорошим, только и слышно здесь говно, там говно.
А>Даже нет у него в отличие от говнокода названия своего, там вареньекод, медокод.

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

В общем, то что код 'пахнет', это не характеристика кода, это характеристика того кто 'нюхает'.

RO>Nginx — образец проблем, которые получаются, если делать всё вручную. ... Я уверен, что приделать любую новую фичу к nginx — всё равно, что искать иголку в стоге заряженных граблей, нацеленных в ноги (или это не то сравнение?).

Кстати забавный момент! Из того что популярные продукты, типа того же NGIX'a трактуются как говнокод, ИМХО, есть интересное следствие — идеально сферический код в вакууме нужен разве что такому же идеальному и сферическому разрабу, обитающему ровно в том же вакууме, и польза от такого кода ровно такая же — сферическая. В реальности приносит пользу именно то, что называется у сферического разраба говнокодом. Может таки надо думать о пользе кода, а не о идеальности его формы? ))))

Позволю себе не согласиться.

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

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

M>Например преобразование YUV -> RGB написано с ошибками в десяток процентов, работает на порядок медленнее чем аналоги. Выполняет ли он свою функцию ? Да , выполняет. Его подробно не тестировали и использовали в программе конвертере ибо результат был похож на ожидаемый. Ударит ли по качеству ? обязательно ударит , но возможно не сразу.

Ну тогда говнокод не характеристика а состояние, и зависит не от программиста а от процесса. Собственно любой код кроме не написанного — говнокод, в какой-то момент времени. )))

M>Но для другого програмиста все эти баги и недоработки будут очевидными , и это однозначно говнокод.

Что как бы напрямую зависит от состояния того самого другого программиста.

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

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

M>Но мы то говорим о качестве кода. А код в котором явные недоработки и баги сложно назвать качественным,

Хм, а с какого момента код становится качественным? Как бы практически в любом коде можно найти недоработки, и баги. И в любом коде можно найти фатальный недостаток. Так что же весь код тогда говно?

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


M>>Но мы то говорим о качестве кода. А код в котором явные недоработки и баги сложно назвать качественным,

AS>Хм, а с какого момента код становится качественным? Как бы практически в любом коде можно найти недоработки, и баги. И в любом коде можно найти фатальный недостаток. Так что же весь код тогда говно?

Я говорил про ЯВНЫЕ недоработки и баги, а не те которые надо годами искать. А в целом можно ввести метрику количественную при желании.

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

AS>>Хм, а с какого момента код становится качественным? Как бы практически в любом коде можно найти недоработки, и баги. И в любом коде можно найти фатальный недостаток. Так что же весь код тогда говно?
M>Я говорил про ЯВНЫЕ недоработки и баги, а не те которые надо годами искать. А в целом можно ввести метрику количественную при желании.

Ну, интересно посмотреть на метрику. Кстати, как это не удивительно, но ЯВНЫЕ баги и недоработки, могут вообще не влиять на качество софта. Тут же ведь вопрос в что это за баги и недоработки. ЯВНОСТЬ ещё не означает принципиальной проблемы. )))

M>Я говорю что вы термины пытаетесь размыть. Таким же образом можно говорить что нет некрасивых и красивых женщин , вкусной и невкусной еды и т.п. Какой в этом смысл ХЗ.

Кстати, хорошее сравнение. Ведь очевидно что ЯВНО красивые/некрасивые женщины и вкусная/невкусная еда — существуют, но в процентном отношении ко всей массе — в ничтожном количестве. Остальное где-то по серёдке. Так же и с кодом. Несомненно есть код ущербный (обычно студенческий) и код идеал (наверное есть), вот только в реальности клеймо говнокод к сей градации отношения вообще никакого не имеет. Чисто сугубо личное отношение некого программера к некому коду, обычно определяемое неспособностью прочитать/понять тот самый код и смериться с несовершенством мира.

З.Ы.
ИМХО, идеалист за клавиатурой хуже любого говнокода )))

Здравствуйте, Alexéy Sudachén, Вы писали:

AS>Чисто сугубо личное отношение некого программера к некому коду, обычно определяемое неспособностью прочитать/понять тот самый код и смериться с несовершенством мира.

А "говнокод" и есть субъективная оценка понятности и сопровождаемости кода.
Код, который не может поддерживать обычный программер — это говонокод.
Я тут не говорю, о сложных алгоримах, понимание которых требует специальных знаний.
И говонокод увы существует.
Признаки такие:
— плохо документирован, или комментарии вообще вводят с толку
— названия переменных/методов/классов не отражает сути
— код неединообразно форматирован
— нету автоматических тестов
— роли классов не понятны
— границы модулей/компонент размыты или вообще отсуствуют
— отсутствие layers и вообще какой-нибудь разумной инкапсуляции. отовсюду все видно и доступно.
— и т.д.

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

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

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

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

Здравствуйте, Alexéy Sudachén, Вы писали:

AS>Может таки надо думать о пользе кода, а не о идеальности его формы?

Странный вопрос. Если тебе поручено реализовать X, то ты будешь думать о пользе X и его роли в русской революции, или о том, как этот X лучше реализовать?

А если окажется, что код 90% повсеместно используемых продуктов — (в лучшем случае) спагетти-код, то вывод «наверное, это и есть залог успеха» не совсем логичен.

On 11.03.2013 21:56, Roman Odaisky wrote:

> А если окажется, что код 90% повсеместно используемых продуктов — (в
> лучшем случае) спагетти-код, то вывод «наверное, это и есть залог
> успеха» не совсем логичен.
Ну почему же. Ты можешь постратить время на вилизывание кода, а
конкуренты тебе обойдут, а когда ты код "идеально" вылижешь, он никому
не нужен будет.

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

>> А если окажется, что код 90% повсеместно используемых продуктов — (в
>> лучшем случае) спагетти-код, то вывод «наверное, это и есть залог
>> успеха» не совсем логичен.
V>Ну почему же. Ты можешь постратить время на вилизывание кода, а
V>конкуренты тебе обойдут, а когда ты код "идеально" вылижешь, он никому
V>не нужен будет.

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

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

On 12.03.2013 1:39, Roman Odaisky wrote:

> Если с самого начала хорошо спроектировать, затраты времени окупятся при
> первой же необходимости существенно изменить код. Тем более затрат-то:
> просто хорошо подумать, прежде чем шашкой махать, и не делать глупостей.
Что ж Господь Бог так человека хреновенько спроектировал-то?

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

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

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

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

B>Код, который не может поддерживать обычный программер — это говонокод.

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

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

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

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

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

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

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

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

Здравствуйте, Alexéy Sudachén, Вы писали:

AS>Дык, это же и есть главная проблема! Вот детей как бы сначала учат читать, а уже за тем писать. Программеров же почему то учат сразу писать, а читать не учат совсем, тогда как большую часть времени, по уму, программер именно читает код. Вот и получается что 'чукча не читатель — чукча писатель', всё вокруг говно и только чукча в белом.

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

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

AS>>Дык, это же и есть главная проблема! Вот детей как бы сначала учат читать, а уже за тем писать. Программеров же почему то учат сразу писать, а читать не учат совсем, тогда как большую часть времени, по уму, программер именно читает код. Вот и получается что 'чукча не читатель — чукча писатель', всё вокруг говно и только чукча в белом.

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

И что хотя бы половина людей в этих командах код тоже умеют читать? От чего же тогда такое плохое качество кода?

B>Был бы ты тут рядом, я бы тебе показал говнокод.

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

B>Во всех отраслях нормально говорить о качестве.
B>С чего бы написание кода чем-то отличается от других?
B>То, что ты имеешь ввиду — это скорей всего безосновательное критиканство любого когда,

Качество кода, в условиях заданных критериев — понятие объективное. Говнокод — характеристика субъективная по определению, и будучи использована превращает обсуждение любого кода в критиканство.

On 12.03.2013 13:33, Atik wrote:

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

Здравствуйте, Alexéy Sudachén, Вы писали:

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

AS>Дык не бывает в природе 'хорошо спроектировать', разве что в совсем вырожденных случаях. Обычно бывает — писать код эволюционно, от меньшего к большему, ровно то что нужно и не закрывая возможности развития.

Так последнее и есть основным признаком хорошего проектирования.

Вот тот же nginx. Они что, с самого начала не знали, что в конфигурационном файле будут использоваться $-переменные в директивах, и что юзеры могут захотеть использовать их в любых местах? Или что существует свыше 9000 всевозможных парсеров грамматик, которые намного проще адаптировать под изменяющиеся требования, чем велосипед? Например, они решили поддерживать нестандартный синтаксис с пробелами в URI — GET /bug/a horrible name with spaces.html HTTP/1.1\r\n... — но их парсер просто перебирает символы слева направо, и GET /bug/A Horrible Name With Spaces.html HTTP/1.1 ему уже не по силам, потому что после последовательности пробел-H он ждет T-T-P-slash.

http/ngx_http_parse.c — вообще очень занимательный файл. Там есть идентично объявленные макросы ngx_str3_cmp и ngx_str3Ocmp (причем это заглавная O, а не ноль), используются вот так:

if (ngx_str3Ocmp(m, 'P', 'O', 'S', 'T')) {
    r->method = NGX_HTTP_POST;
    break;
}

и, при правильной endian-ности платформы, оптимизируют сравнение, кастуя 4 байта строки в uint32_t. А при неправильной, просто посимвольно сравнивают m[0], m[1], m[2] и m[3] — только ngx_str3_cmp не сравнивает m[3], а ngx_str3Ocmp — m[1]. Даже здесь есть логика — ngx_str3_cmp вызывается, проверяя строку на "GET " и "PUT ", а вызов ngx_str3Ocmp находится внутри if (m[1] == 'O') { проверить POST, COPY, MOVE, LOCK } else { проверить HEAD } — хотя и непонятно, какие копейки они выигрывают таким образом. Но если так делать, то почему не сравнить первые 4 байта запроса со строкой "GET " вообще до начала разбора, а не наткнувшись на пробел (после кучи невыровненных сравнений и условных переходов)? Почему не делать того же для строки "HTTP/1.1", пусть даже она не будет выровнена? Почему вообще вся эта черная магия делается вручную, а не есть результатом работы кодогенератора?

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

RO>Вот тот же nginx. Они что, с самого начала не знали, что в конфигурационном файле будут использоваться $-переменные в директивах, и что юзеры могут захотеть использовать их в любых местах? Или что существует свыше 9000 всевозможных парсеров грамматик, которые намного проще адаптировать под изменяющиеся требования,

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

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

RO>Здравствуйте, 11molniev, Вы писали:

1>>На мой взгляд код 7-zip и nginx хороший.

RO>Nginx — образец проблем, которые получаются, если делать всё вручную. Например, большинство директив в файле конфигурации не понимают переменные (нельзя сказать error_log /path/$some_var_depending_on_host/whatever.log) — казалось бы, должен быть некий централизованный механизм, но нет, парсер каждой директивы сам занимается разбором аргументов, причем полностью в ручном режиме, даже без грамматики. Я уверен, что приделать любую новую фичу к nginx — всё равно, что искать иголку в стоге заряженных граблей, нацеленных в ноги (или это не то сравнение?). Один if чего стоит, с миллионом подлых глюков.
1. Первоначально это был проект для личного использования.
2. Вы серьезно или издеваетесь? Парсер конфига это один из модулей. И их может быть несколько последовательно отрабатывающих. И как раз таки основной разбор делается не каждым модулем по отдельности, а централизованно. И при это подерживаются разные типы деректив.
Вот только ngx_conf_handler нефига не подставляет переменные, так как предполагает, что параметр может включать в себя спецсимволы обрабатываемые целевым модулем.
Добавить глобальную обработку — это дописать кусок кода в этой функции. В одном месте. А если добавить ещё один флаг для модулей, с помощью которого можно указать разрешено ли подставлять данные — то будет полная совместимость со всеми модулями, в том числе сторонних разработчиков.
Что же касается переменных $some_var_depending_on_host — то они зависят от контекста и по логике могут обрабатыватся разными модулями, друг с другом не связанными, потому и не разрашаются. Но при этом ничто не мешает допилить ещё один модуль, в который общие параметры могут складыватся и забиратся основным парсером (потребует правки модулей). Или добавив немного кода все в тот же глобальный обработчик ngx_conf_handler мы можем сами разрешать параметры с совпадающими именами.
Nginx это образец проблем которые могут оказатся у пользователя, если разработчик сделает хороший для себя код.
3. Приделать любую фичу к nginx-су проще простого. И именно как раз таки граблей там нет.

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

1>1. Первоначально это был проект для личного использования.

Для личного использования Рамблера.

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

То-то такой велосипед при разборе параметра so_keepalive: http://trac.nginx.org/nginx/browser/nginx/trunk/src/http/ngx_http_core_module.c#L4133

А был бы парсер, он бы сам всё сделал из грамматики в три строки наподобие:

so_keepalive:
    "on"
    "off"
    time? ":" time? ":" time?

1>Вот только ngx_conf_handler нефига не подставляет переменные, так как предполагает, что параметр может включать в себя спецсимволы обрабатываемые целевым модулем.
1>Добавить глобальную обработку — это дописать кусок кода в этой функции. В одном месте. А если добавить ещё один флаг для модулей, с помощью которого можно указать разрешено ли подставлять данные — то будет полная совместимость со всеми модулями, в том числе сторонних разработчиков.
1>Что же касается переменных $some_var_depending_on_host — то они зависят от контекста и по логике могут обрабатыватся разными модулями, друг с другом не связанными, потому и не разрашаются. Но при этом ничто не мешает допилить ещё один модуль, в который общие параметры могут складыватся и забиратся основным парсером (потребует правки модулей). Или добавив немного кода все в тот же глобальный обработчик ngx_conf_handler мы можем сами разрешать параметры с совпадающими именами.

Вот у меня есть некоторое количество мини-сайтиков, все используют один и тот же конфигурационный файл. Я хотел было разрешить autoindex для некоторых из них путем map $host $autoindex { ... on/off }; ... autoindex $autoindex; — а вот нет. Причем ngx_http_autoindex_module точно выполняется одним из последних, к этому моменту $host гарантированно есть, но не работает.

1>3. Приделать любую фичу к nginx-су проще простого. И именно как раз таки граблей там нет.

Динамическая загрузка модулей? :-)

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

RO>Здравствуйте, 11molniev, Вы писали:

1>>1. Первоначально это был проект для личного использования.
RO>Для личного использования Рамблера.
Для личного пользования администратором Рамблера

1>>2. Вы серьезно или издеваетесь? Парсер конфига это один из модулей. И их может быть несколько последовательно отрабатывающих. И как раз таки основной разбор делается не каждым модулем по отдельности, а централизованно. И при это подерживаются разные типы деректив.
RO>То-то такой велосипед при разборе параметра so_keepalive: http://trac.nginx.org/nginx/browser/nginx/trunk/src/http/ngx_http_core_module.c#L4133

RO>А был бы парсер, он бы сам всё сделал из грамматики в три строки наподобие:
RO>

RO>so_keepalive:
RO>    "on"
RO>    "off"
RO>    time? ":" time? ":" time?
RO>

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

1>>Вот только ngx_conf_handler нефига не подставляет переменные, так как предполагает, что параметр может включать в себя спецсимволы обрабатываемые целевым модулем.
1>>Добавить глобальную обработку — это дописать кусок кода в этой функции. В одном месте. А если добавить ещё один флаг для модулей, с помощью которого можно указать разрешено ли подставлять данные — то будет полная совместимость со всеми модулями, в том числе сторонних разработчиков.
1>>Что же касается переменных $some_var_depending_on_host — то они зависят от контекста и по логике могут обрабатыватся разными модулями, друг с другом не связанными, потому и не разрашаются. Но при этом ничто не мешает допилить ещё один модуль, в который общие параметры могут складыватся и забиратся основным парсером (потребует правки модулей). Или добавив немного кода все в тот же глобальный обработчик ngx_conf_handler мы можем сами разрешать параметры с совпадающими именами.

RO>Вот у меня есть некоторое количество мини-сайтиков, все используют один и тот же конфигурационный файл. Я хотел было разрешить autoindex для некоторых из них путем map $host $autoindex { ... on/off }; ... autoindex $autoindex; — а вот нет. Причем ngx_http_autoindex_module точно выполняется одним из последних, к этому моменту $host гарантированно есть, но не работает.
Я же не сказал, что такой функционал есть, я сказал, что добавить его относительно простая задача, которая требует довольно небольшой правки кода.
Я не использовал map, но хочу отметить, что сопоставить хостам autoindex, вместо того что бы прописывать их в конфигурации хоста — в моем понимании странно. Конфигурационный файл становится больше только то и всего.
И самое главное: вы не можите использовать переменные для autoindex переменные не потому, что код написан криво, а потому, что autoindex вычисляется однократно — при прочтении конфигурации, а не для каждого запроса в отдельности. Проблема не в том, что как вы утверждаете "парсер каждой директивы сам занимается разбором аргументов, причем полностью в ручном режиме, даже без грамматики", а в том что этот параметр статический, не зависящий от запроса. И опять же ничто не мешает это поменять правкой кода в одном единственном месте (ngx_http_autoindex_module.c). Но то, что он статичен делает работу этого модуля чуть-чуть быстрей. Ничтожная величина — но таких величин множество и это один из факторов делающий nginx таким быстрым.

1>>3. Приделать любую фичу к nginx-су проще простого. И именно как раз таки граблей там нет.

RO>Динамическая загрузка модулей?

Таки можно. Без возможности выгрузки

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

V>On 21.01.2013 11:26, Kernan wrote:

V>formatTag+=(unsigned char)chBuff[l]*1<<8
V>что было переделано на:
V>formatTag+=(unsigned char)chBuff[l]*256

А криминал в чем ? В свое время, давным-давно правда, видел инструкции прямо инструктирующие делать сдвигами.

Здравствуйте, Alexéy Sudachén, Вы писали:

AS>В общем, то что код 'пахнет', это не характеристика кода, это характеристика того кто 'нюхает'.

Качество кода определяет вектор развития девелопера. Будет ли он т.н. бойцом с кодом или инженером. Востребованы почему то именно инженеры. Вот чудеса

Здравствуйте, Alexéy Sudachén, Вы писали:

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

Ну вот смотри, код писался в 2004м году. Что бы ввести довольно сложную и важную оптимизацию затрачено около 1 дня, при том что все оптимизированые конструкции были уже готовы, затронуто всего 5 файлов. Солюшн — доменная модель, довольно сложные сценарии, вагоны кода. Код довольно легко покрылся юнит-тестами. Итог работы — пара-тройка багов которые вылезли в регрешнах.

Второй пример — добавить кнопку на тулбар, связать её с формой, прикрутить обновления, событиями и тд. Убито три дня времени, модифицировано полтора десятка файлов, регрешны + дали пару десятков багов, на которые ушло еще от недели до двух + повторное тестирование и тд и тд.
Вопрос — какого хрена добавление кнопки на тулбар выливается в такую эпопею ?
Очень простой ответ — люди, которые писали эт часть , были очень трудолюбивыми и аккуратными — аккуратно и методично размножили сточки кода на пару сотен айтемов и сделали соответсвующие изменения в целой куче файлов.
Вместо того, что бы написать внятное обновление UI, ну скажем контроллер , с конфигурянием айтемов навроде

ItemFromXml("ItemID")
.Enable(x => condition)
.Down(x => condition)
.OnClick(x => Show(XXX))
.Mode(x => mode)
.RaizeUpdate(x => Update.FromToolbar);

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

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

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

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

V>>formatTag+=(unsigned char)chBuff[l]*1<<8
V>>что было переделано на:
V>>formatTag+=(unsigned char)chBuff[l]*256

P>А криминал в чем ? В свое время, давным-давно правда, видел инструкции прямо инструктирующие делать сдвигами.

Шо, в самом деле, вместо умножения сдвиг делать ? Это инструкции образца 80х, когда компилер не умел оптимизировать.

Вот смотри, круть какая: (((a << 1)+a)+(a << 1))<<1

Посмотри, сколько людей сходу ответит что здесь делается.

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

Я вот только одного не пойму... это характеристика кода или таки девелоперов?!

I>Вобщем чисто теоретически, все зависит от способности читать код, а практически оказывается, что сложность самого кода растет

Практически оказывается что имеющиеся в наличии девелоперы говно?!

Здравствуйте, Alexéy Sudachén, Вы писали:

AS>Практически оказывается что имеющиеся в наличии девелоперы говно?!
У твоего оппонента не может такого быть, ибо у них очень грамотное и правильное собеседование и плохие девелоперы его не пройдут. Что был твоим оппонентом не раз доказано здесь на форуме.

AS>>В общем, то что код 'пахнет', это не характеристика кода, это характеристика того кто 'нюхает'.
I>Качество кода определяет вектор развития девелопера. Будет ли он т.н. бойцом с кодом или инженером. Востребованы почему то именно инженеры. Вот чудеса

Качество кода характеристика интегральная. Не бывает просто лучше или хуже. Как бы нет в природе лучшего вообще, есть лучшее в частности. С худшим ровно так же. ИМХО, руководителю то нефигво бы было это понимать )))

Твой посыл ведь можно понимать и так что человек, который может разобраться в сложно запутанном коде и распутать его до вразумительной сложности или хотя бы прибить матёрые баги, ничего толкового написать не может, а вот тот кто не может читать код сложнее чем из учебника — он ОГОГО какой инженер ))) То есть чем меньше 'натворить' может тем лучше )))) Тоже подход, хотя он и не работает.

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

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


A>вообще С код не может быть хорошим по-определению,
A>а С++ код там от С недалеко ушел.
A>хотя там где COM интерфейсы его можно объяснить ограничениями COM (хотя зачем там вообще COM?).

A>собственно catch(int) в main() сразу намекает на качество кода

Самое смешное, что там не COM. А по мотивам. Обработка ошибок строго зачаточная. Хочется взять и все с нуля переписать. Но некогда, приходится так использовать

AS>>Практически оказывается что имеющиеся в наличии девелоперы говно?!
А>У твоего оппонента не может такого быть, ибо у них очень грамотное и правильное собеседование и плохие девелоперы его не пройдут. Что был твоим оппонентом не раз доказано здесь на форуме.

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

Что до собеседований, дык я у него на собеседованиях не был, и кто его пройдёт, а кто нет — не знаю. Но по общему фону тусофки могу судить что 'грамотные и правильные девелоперы', ну те которые проходят собеседования, и программисты способные писать код — это таки разные люди )))

I>Вот смотри, круть какая: (((a << 1)+a)+(a << 1))<<1
I>Посмотри, сколько людей сходу ответит что здесь делается.

Э... и сколько же людей ответит что делает тривиальный код (a<<3)+(a<<1)? Ну... я даже не знаю ... наверное все, кто знает что такое << ? Не, ну правда, у вас что действительно настолько плохие программисты?!

Здравствуйте, Alexéy Sudachén, Вы писали:

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

AS>Я вот только одного не пойму... это характеристика кода или таки девелоперов?!

Кода, что очевидно.

I>>Вобщем чисто теоретически, все зависит от способности читать код, а практически оказывается, что сложность самого кода растет

AS>Практически оказывается что имеющиеся в наличии девелоперы говно?!

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

Представил ?

Теперь представь себя и сравни с этим идеальным девелопером.

Опаньки, ктото из вас двоих окажется говном !

Здравствуйте, Alexéy Sudachén, Вы писали:

AS>>>В общем, то что код 'пахнет', это не характеристика кода, это характеристика того кто 'нюхает'.
I>>Качество кода определяет вектор развития девелопера. Будет ли он т.н. бойцом с кодом или инженером. Востребованы почему то именно инженеры. Вот чудеса

AS>Качество кода характеристика интегральная. Не бывает просто лучше или хуже. Как бы нет в природе лучшего вообще, есть лучшее в частности. С худшим ровно так же. ИМХО, руководителю то нефигво бы было это понимать )))

Качество во все времена было соответствие требованиям. А то что ты говоришь, это общие слова.

AS>Твой посыл ведь можно понимать и так что человек, который может разобраться в сложно запутанном коде и распутать его до вразумительной сложности или хотя бы прибить матёрые баги, ничего толкового написать не может, а вот тот кто не может читать код сложнее чем из учебника — он ОГОГО какой инженер ))) То есть чем меньше 'натворить' может тем лучше )))) Тоже подход, хотя он и не работает.

AS>Востребованы люди, которые без волшебного пенделя могут сделать свою работу в оговоренные сроки и в заданных ограничениях. Остальное романтика.

Скорость роста квалификации девелопера и скорость роста сложности спагетти кода как правило отличаются в разы и всегда не в пользу девелопера.

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

Здравствуйте, Alexéy Sudachén, Вы писали:

I>>Вот смотри, круть какая: (((a << 1)+a)+(a << 1))<<1
I>>Посмотри, сколько людей сходу ответит что здесь делается.

AS>Э... и сколько же людей ответит что делает тривиальный код (a<<3)+(a<<1)? Ну... я даже не знаю ... наверное все, кто знает что такое << ? Не, ну правда, у вас что действительно настолько плохие программисты?!

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

AS>>Востребованы люди, которые без волшебного пенделя могут сделать свою работу в оговоренные сроки и в заданных ограничениях. Остальное романтика.
I>Скорость роста квалификации девелопера и скорость роста сложности спагетти кода как правило отличаются в разы и всегда не в пользу девелопера.

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

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

В природе нет сколь угодно малого и сколь угодно большого, это лишь абстракции для упрощения модели или инструмент демагогии. )))

I>>>А второй выглядит очень красиво и тд тд. Но это говнокод, потому что за время проекта не нашлось ни одного девелопера, кто бы смог побороть дублирование в этом коде.
AS>>Я вот только одного не пойму... это характеристика кода или таки девелоперов?!
I>Кода, что очевидно.

Ну вот для меня это совершенно не очевидно. Да и между прочим, код, я так понимаю, инопланетяне подарили.

I>Опаньки, ктото из вас двоих окажется говном !

О! Ты демонстрируешь просто редкие жемчужины логики! ))) Из двоих, кто например говно — Микеланджело или Да Винчи? Ведь всегда кто-то должен быть говном, не правда ли?!

Здравствуйте, <Аноним>, Вы писали:

AS>>Практически оказывается что имеющиеся в наличии девелоперы говно?!
А>У твоего оппонента не может такого быть, ибо у них очень грамотное и правильное собеседование и плохие девелоперы его не пройдут.

Обычный аутсорсинг тама.

Здравствуйте, Alexéy Sudachén, Вы писали:

AS>потому что за время проекта не нашлось ни одного девелопера, кто бы смог побороть дублирование в этом коде — я придумал? Или это просто фетишь, который на самом деле нафиг никому не нужен, потому и не нашлось. )
Это был сарказм. Икемуфула тут уже много лет плачется про плохих программистов, которых тщательно отбирает на своих собеседованиях. Тут уже много "обсуждений" по этому поводу было.
А фетишь, очень возможно, что это и есть тот самый "Неуловимый Джо".

AS>Что до собеседований, дык я у него на собеседованиях не был, и кто его пройдёт, а кто нет — не знаю. Но по общему фону тусофки могу судить что 'грамотные и правильные девелоперы', ну те которые проходят собеседования, и программисты способные писать код — это таки разные люди )))
Вообще-то чаще всего именно так и есть.

Здравствуйте, Alexéy Sudachén, Вы писали:

AS>>>Востребованы люди, которые без волшебного пенделя могут сделать свою работу в оговоренные сроки и в заданных ограничениях. Остальное романтика.
I>>Скорость роста квалификации девелопера и скорость роста сложности спагетти кода как правило отличаются в разы и всегда не в пользу девелопера.

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

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

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

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

AS>В природе нет сколь угодно малого и сколь угодно большого, это лишь абстракции для упрощения модели или инструмент демагогии. )))

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

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

Здравствуйте, Alexéy Sudachén, Вы писали:

I>>>>А второй выглядит очень красиво и тд тд. Но это говнокод, потому что за время проекта не нашлось ни одного девелопера, кто бы смог побороть дублирование в этом коде.
AS>>>Я вот только одного не пойму... это характеристика кода или таки девелоперов?!
I>>Кода, что очевидно.

AS>Ну вот для меня это совершенно не очевидно. Да и между прочим, код, я так понимаю, инопланетяне подарили.

Практически инопланетяне, то есть, я не знаю, кто его писал.

I>>Опаньки, ктото из вас двоих окажется говном !

AS>О! Ты демонстрируешь просто редкие жемчужины логики! ))) Из двоих, кто например говно — Микеланджело или Да Винчи? Ведь всегда кто-то должен быть говном, не правда ли?!

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

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

Вот и получается — или ты идельный девелопер, который все задачи делает за 0 времени, или, пользуюясь твоей терминологией, говнодевелопер.

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

AV>Здравствуйте, <Аноним>, Вы писали:

AS>>>Практически оказывается что имеющиеся в наличии девелоперы говно?!
А>>У твоего оппонента не может такого быть, ибо у них очень грамотное и правильное собеседование и плохие девелоперы его не пройдут.

AV>Обычный аутсорсинг тама.

Тама не обычный аутсорс, не надо врать.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Alexéy Sudachén, Вы писали:

AS>>потому что за время проекта не нашлось ни одного девелопера, кто бы смог побороть дублирование в этом коде — я придумал? Или это просто фетишь, который на самом деле нафиг никому не нужен, потому и не нашлось. )
А>Это был сарказм. Икемуфула тут уже много лет плачется про плохих программистов, которых тщательно отбирает на своих собеседованиях. Тут уже много "обсуждений" по этому поводу было.

Это Вжик похоже, не уверен. Видишь ли, у меня пока нет возможности влиять на качество кода, который достаётся по наследству. Пока что я такого просветления не достиг. А судя по тому, что было в коде, то да, так и не нашлось девелопера, кто бы смог забороть дублирование. Это следует из того факта, что код убитого проекта попал ко мне.
Чем те люди занимались, не знаю, наверное тренировались читать код, как Alexéy Sudachén, а не струкрутировать и устранять проблемы, ну, как вариант, меняли умножение на сдвиги "патамушта луче знали сколько ригистроф у працэсара"

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

>> А если окажется, что код 90% повсеместно используемых продуктов — (в
>> лучшем случае) спагетти-код, то вывод «наверное, это и есть залог
>> успеха» не совсем логичен.
V>Ну почему же. Ты можешь постратить время на вилизывание кода, а
V>конкуренты тебе обойдут, а когда ты код "идеально" вылижешь, он никому
V>не нужен будет.

Да не нужно вылизывать код. Устранется сразу тоьлко явное дублирование + мало-мальски структурируется для тех требований что есть сейчас. Хороший код это не тот, что хорошо выглядит, это тот, который легко менять, хотя он может быть страшнее чем белая горячка

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

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

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

V>Нужно делать только то, что требуется и укладываться в требуемые сроки,
V>а код, архитектура — это баловство за счет работодателя.

Ты лучше пример кода приведи.

Здравствуйте, Alexéy Sudachén, Вы писали:

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

AS>И что хотя бы половина людей в этих командах код тоже умеют читать? От чего же тогда такое плохое качество кода?

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

AS>Не показал бы. Для меня такого понятия просто не существует. В любом коде есть недостатки, где-то их больше, где-то меньше. Где-то весь код один большой недостаток ) Короче, они есть всегда и более того, иногда могут превращаться в достоинства в зависимости от ситуации и наоборот. Надо просто принимать код как он есть, без эмоциональной окраски и проекций на собственные идеалы. А дальше уже решать что делать, если вообще что-то нужно с этим делать.

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

Надо ли объяснять, что фиксы этой простыни и фиксы двух строчек занимают совершенно разное время ? Если ты не согласен — давай свой образчик код.

B>>Во всех отраслях нормально говорить о качестве.
B>>С чего бы написание кода чем-то отличается от других?
B>>То, что ты имеешь ввиду — это скорей всего безосновательное критиканство любого когда,

AS>Качество кода, в условиях заданных критериев — понятие объективное. Говнокод — характеристика субъективная по определению, и будучи использована превращает обсуждение любого кода в критиканство.

Да критерии вобщем всегда заданы. А говнокод это просто эмоциональная оценка кода который ни в какие критерии не вписывается.

AS>>Не показал бы. Для меня такого понятия просто не существует. В любом коде есть недостатки, где-то их больше, где-то меньше. Где-то весь код один большой недостаток ) Короче, они есть всегда и более того, иногда могут превращаться в достоинства в зависимости от ситуации и наоборот. Надо просто принимать код как он есть, без эмоциональной окраски и проекций на собственные идеалы. А дальше уже решать что делать, если вообще что-то нужно с этим делать.

I>Не дай бог "индусский вариант" зафиксишь хотя бы на секунду позже — пеняй на себя. Вот у меня есть образчик — простыня в несколько экранов императивного кода свернулась без какого либо ухудшения свойств примерно в 2 короткие строчки такого же императивного кода.
I>Надо ли объяснять, что фиксы этой простыни и фиксы двух строчек занимают совершенно разное время ? Если ты не согласен — давай свой образчик код.

Естественно. Любые фиксы занимают время. Причём как показала практика фиксы в коде с развесистой охренектурой занимают время ничуть не меньше чем в спагетте коде. То есть я так понял, что для тебя говнокод это то где чего-то зафиксить требует времени?! Ну тогда это любой код. Хотя может просто не стоит подписываться на работу за нереальное время, и тогда говнокод магическим образом исчезнет и вместо него появится результат чего-то труда?!

Здравствуйте, Alexéy Sudachén, Вы писали:

I>>Надо ли объяснять, что фиксы этой простыни и фиксы двух строчек занимают совершенно разное время ? Если ты не согласен — давай свой образчик код.

AS>Естественно. Любые фиксы занимают время.

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

>Причём как показала практика фиксы в коде с развесистой охренектурой занимают время ничуть не меньше чем в спагетте коде. То есть я так понял, что для тебя говнокод это то где чего-то зафиксить требует времени?!

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

>Ну тогда это любой код. Хотя может просто не стоит подписываться на работу за нереальное время, и тогда говнокод магическим образом исчезнет и вместо него появится результат чего-то труда?!

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

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

P.S. Если нечего сказать, можешь продолжить свою любимую тему: "у вас программисты говно"

AS>>Естественно. Любые фиксы занимают время.
I>При чем время фикса непосредтсвенно зависит от состояния кода, вот так фокус ! То есть, кастомер вынужден платить бОльшие деньги только по этой причине.

Естественно, как и от квалификации программеров. И кастомер вынужден платить столько сколько стоит изменение в его коде. Я так понимаю кастомуру код подарили, он не принимал решения как и кому его давать на разработку и ничего в таком раскладе не выиграл, конечно же? Вот тут мы приходим к основной проблеме — ты почему вместо работы считаешь деньги в кармане кастомера?! Считать его деньги задача сейлсов. Твоя задача сказать сроки и в эти сроки сделать работу. Не можешь сказать сроки, выдержать их, или просто не нравиться этим заниматься?! Ну дык, и какое это всё имеет отношение к коду? Не хочется иметь в резюме строчку цать лет правил баги в легаси-(говно)коде — не занимайся этим.

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

I>Ты лучше объясни, для чего нужно структурировать код и почему одна и та же задача в разном коде занимает совершенно разное количество времени.
I>P.S. Если нечего сказать, можешь продолжить свою любимую тему: "у вас программисты говно"

Давай на реальном примере, да? С теми же сдвигами о которых ты так жалобно плакался. Какой подход идейно правильного программера с не замараным нимбом? Ну кроме того чтобы слюнявить жилетку? Долго курить траву для просветления и откровения как сей код поправить? Угу. Написать скриптик на перле или питоне который превратит этот код в легко читаемый в голову не приходило?! Ну как же я забыл, правильные программеры они всякую мелкую фигню не пишут ))) на КЫВТ это уже много раз доказали. Только по крупному, только хардкор и охренектура. Странно да, вроде и крылья и нимб на месте, а вот как руки до дела доходит, сразу мордой в жилетку.... ууу... у нас не один программер не может код разрулить.

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

Здравствуйте, Alexéy Sudachén, Вы писали:

I>>Ты лучше объясни, для чего нужно структурировать код и почему одна и та же задача в разном коде занимает совершенно разное количество времени.
I>>P.S. Если нечего сказать, можешь продолжить свою любимую тему: "у вас программисты говно"

AS>Давай на реальном примере, да? С теми же сдвигами о которых ты так жалобно плакался.

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

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

Не так вопрос ставишь, не разрулить любой код, а любой код за сколь угодно малое время. Вот у меня есть два варианта в разных продуктах, в одном добавление кнопки сравнимо с временем клика, в другом — надо перепахивать весь солюшн.
В который раз спрашиваю — ты сможешь гарантировать скорость фикса во втором случае за время сравнимое с временем клика ? Ну, то есть, хотя бы за минуту найти и пофиксить 30-50 мест ?

Внятно ответь : "Да, смогу пофиксить 30-50 заранее неизвестных мест за время до одной минуты" или так "Нет, не смогу, времени надо ххх"

Здравствуйте, Alexéy Sudachén, Вы писали:

AS>>>Естественно. Любые фиксы занимают время.
I>>При чем время фикса непосредтсвенно зависит от состояния кода, вот так фокус ! То есть, кастомер вынужден платить бОльшие деньги только по этой причине.

AS>Естественно,

Опаньки ! А недавно ты яростно отрицал это.

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

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

>Вот тут мы приходим к основной проблеме — ты почему вместо работы считаешь деньги в кармане кастомера?!

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

>Считать его деньги задача сейлсов.

Типичный подход эффективного менеджера на распильных проектах. Вот так вот кастомер и получает унылое Г и переделывает один и тот же проект по нескольку раз.

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

Да ты не волнуйся, я так и делаю, но вот есть ощущение что ты только свой код-проекты и видишь.

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

I>Это вжик жаловался на сдвиги,
Как обычно ты в своих фантазиях весь. Я (вжик) привел пример разбора RIFF шапки сдвигами. И таки да, разбор RIFF сдвигами — это и есть пример говнокода.

Здравствуйте, Аноним, Вы писали:

I>>Это вжик жаловался на сдвиги,
А>Как обычно ты в своих фантазиях весь. Я (вжик) привел пример разбора RIFF шапки сдвигами. И таки да, разбор RIFF сдвигами — это и есть пример говнокода.

"А может ты просто читать код не умеешь ?" @ AS тут утверждает, что говно не в коде, а в девелоперах. Кому из вас верить ?

Я, кстати, сильно сомневаюсь, что только "разбор RIFF шапки" может быть примером говнокода.

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

А>>Как обычно ты в своих фантазиях весь. Я (вжик) привел пример разбора RIFF шапки сдвигами. И таки да, разбор RIFF сдвигами — это и есть пример говнокода.
I>Я, кстати, сильно сомневаюсь, что только "разбор RIFF шапки" может быть примером говнокода.

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

Здравствуйте, Аноним, Вы писали:

А>>>Как обычно ты в своих фантазиях весь. Я (вжик) привел пример разбора RIFF шапки сдвигами. И таки да, разбор RIFF сдвигами — это и есть пример говнокода.
I>>Я, кстати, сильно сомневаюсь, что только "разбор RIFF шапки" может быть примером говнокода.

А>Вопрос всем, подскажите в какой ветке RSDN имеет смысл обсудить местное модерирование в контексте запрета здесь подобногго троллинга и бана таких персонажей. Написано же "разбора RIFF шапки сдвигами", нет, некоторые упорно пытаются читать не то, что написано и загаживают даже профильные ветки.

Я не понимаю, "разбора RIFF шапки сдвигами" это единсвенно легальный вариант говнокода или есть другие ? Ты не ходи кругами, внятно ответь.

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

I>Я не понимаю, "разбора RIFF шапки сдвигами" это единсвенно легальный вариант говнокода или есть другие ? Ты не ходи кругами, внятно ответь.
Какой смысл тебе отвечать, если ты все одно не читаешь? Только форум загаживать? Для этого есть Политика, О жизни и т.п. Священные войны.

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

D>Тоже самое будут говорить про 2010 -- стиль сменился. Зато в 2030 все будут говорить какие были классные программеры в 2000ных -- на таком говне мамонта писали, такие сложные вещи, а у нас на 100500 ядерных машинах перерисовка окошек тормозит.

Нечто подобное сейчас говорят про программы для ZX Spectrum.

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

Скорость фикса редко когда определяется тем, как быстро читается и меняется код.
Надо не забывать накладные расходы. В частности, около трети времени (личная статистика) на фикс уходит на создание регрессионного автоматического теста — иными словами, на код, воспроизводящий проблему. Еще треть уходит на административные действия (тикет, коммит, код ревью и прочее).

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

Рискну утверждать, что это заблуждение.
"Задача добавления кнопки" может формулироваться так — "по нажатию на эту кнопку я хочу, чтобы мне выводилась оценка (valuation) моего инвестиционного портфолио". Казалось бы, что может быть проще — портфолию в базе уже есть, все бумаги известны, количества есть, и даже есть поле, куда эта оценка должна выводиться.
Однако математический аппарат под этой "кнопкой" — даже если взять классику Блэка-Шоулза — мало кто за неделю осилит.

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

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

SD>Рискну утверждать, что это заблуждение.
SD>"Задача добавления кнопки" может формулироваться так — "по нажатию на эту кнопку я хочу, чтобы мне выводилась оценка (valuation) моего инвестиционного портфолио".
Казалось бы, что может быть проще — портфолию в базе уже есть, все бумаги известны, количества есть, и даже есть поле, куда эта оценка должна выводиться.
SD>Однако математический аппарат под этой "кнопкой" — даже если взять классику Блэка-Шоулза — мало кто за неделю осилит.

Задача была простая "добавить кнопку на тулбар". То есть, пример вполне конкретный — добавить кнопку и связать с имеющимся готовым функционалом. Это и есть именно тот пример, про который я говорил.

I>Задача была простая "добавить кнопку на тулбар". То есть, пример вполне конкретный — добавить кнопку и связать с имеющимся готовым функционалом. Это и есть именно тот пример, про который я говорил.

Откуда нам знать вашу ситуацию? Может статься, что тулбары разрабатывали очень давно, и требования к ним были жесткие и точно сформулированные: вот такой набор кнопок, вот так себя ведёт. Программисты сделали ровно то, что от них требуется. В тот момент тулбар развивать не планировалось. И каждое последующее добавление кнопки шло со словами "вы добавьте прямо сейчас, нам не до рефакторинга, надо пилить — завтра релиз". Вы же не думаете всерьез, что важный релиз будут переносить лишь потому, что через 3-5 лет понадобится добавить еще кнопок на тулбар?

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

I>>Задача была простая "добавить кнопку на тулбар". То есть, пример вполне конкретный — добавить кнопку и связать с имеющимся готовым функционалом. Это и есть именно тот пример, про который я говорил.

SD>Откуда нам знать вашу ситуацию? Может статься, что тулбары разрабатывали очень давно, и требования к ним были жесткие и точно сформулированные: вот такой набор кнопок, вот так себя ведёт. Программисты сделали ровно то, что от них требуется. В тот момент тулбар развивать не планировалось. И каждое последующее добавление кнопки шло со словами "вы добавьте прямо сейчас, нам не до рефакторинга, надо пилить — завтра релиз". Вы же не думаете всерьез, что важный релиз будут переносить лишь потому, что через 3-5 лет понадобится добавить еще кнопок на тулбар?

Объяснение есть у каждого. Я в курсе, очень удобно пилить деньги кастомера. Ну добавляется кнопка месяц, ну и что в этом плохого ? Раз кастомер платит, так хоть полгода.

Это подход распильных проектов: "полгода до релиза, месяц пишем фичи, четыре месяца фиксим кнопки, месяц общий багфикс"

Если тебе нравится такой подход, так никто ж не мешает, пили сколько хочешь.

Мне такой подход категорически не нравится.

I>Объяснение есть у каждого. Я в курсе, очень удобно пилить деньги кастомера. Ну добавляется кнопка месяц, ну и что в этом плохого ? Раз кастомер платит, так хоть полгода.

Не пойму, вы сейчас радеете за деньги кастомера? Или считаете, что заказчик идиот? А не этот ли заказчик 5 лет назад сэкономил, и вместо рефакторинга кривой подсистемы сказал "нет, мне надо сейчас и быстро"? Если этот же, то какие могут быть претензии.

I>Это подход распильных проектов: "полгода до релиза, месяц пишем фичи, четыре месяца фиксим кнопки, месяц общий багфикс"

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

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

SD>Не пойму, вы сейчас радеете за деньги кастомера? Или считаете, что заказчик идиот? А не этот ли заказчик 5 лет назад сэкономил, и вместо рефакторинга кривой подсистемы сказал "нет, мне надо сейчас и быстро"? Если этот же, то какие могут быть претензии.

Привык людей не обсчитывать.

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

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

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

Ты предлагаешь распильный вариант — если кастомер не в курсе, давай возьмем денег по максимуму.

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

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

I>>Это подход распильных проектов: "полгода до релиза, месяц пишем фичи, четыре месяца фиксим кнопки, месяц общий багфикс"

SD>У меня сложилось обратное ощущение. Ибо распил — это как раз "мы делаем правильную архитектуру, которая через 5 лет позволит нам легко менять кнопки на тулбаре". Не знаю, как у вас, но в большинстве связанных с бизнесом мест такие начинания быстро бы пресекались, ибо что через 5 лет будет, даже Доу Джонс не знает.

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

Во вторых, покажи, где я говорил про 5 лет ?

I>Кастомер ничего не понимает в софтостроении, вообще ничего, более того, у него целая куча ложных моделей, аналогий.

Хотите сказать, ваш заказчик — глуп и ничего не понимает в том, как надо вести бизнес? Тогда он разорится независимо от того, сэкономите вы ему деньги, или нет. Поэтому будем исходить из предположения, что заказчик таки может привлечь сторонних экспертов и при существенном расхождении в оценках спросить "как же так".

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

I>У меня как раз такой проект сейчас, разрабатывался непойми кем с 2001го года.
<...>
I>Во вторых, покажи, где я говорил про 5 лет ?

Шизофренией какой-то попахивает... окей, не 5, пусть будет 12 лет.

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

I>>Кастомер ничего не понимает в софтостроении, вообще ничего, более того, у него целая куча ложных моделей, аналогий.

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

Заказчик ничего не понимает в софтостроении. Вообще ничего. Он как ребенок, ему надо объяснять по многу раз. А ведение бизнеса здесь абсолютно ни при чем.

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

I>>Во вторых, покажи, где я говорил про 5 лет ?
SD>Шизофренией какой-то попахивает... окей, не 5, пусть будет 12 лет.

Ты покажи где я про такое говорил, а то в самом деле, шизофрения, если ты такое видишь, а на форуме этого нет.

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

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

I>Ты покажи где я про такое говорил

Прямо здесь и пишешь:
I>У меня как раз такой проект сейчас, разрабатывался непойми кем с 2001го года.

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

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

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

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

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

I>>Ты покажи где я про такое говорил

Сейчас у меня веб проект, там нет никаких кнопок на тулбаре

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

Риск появился сразу же. А вот проблема вылезла разумеется позже, на первом же серьезном изменении требований и так продолжалось до тех пор, пока проект не сдох.

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

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

I>Риск появился сразу же.

И его митигировали путём откладывания.
Это тоже обычный способ решения проблем. Путём откладывания. А там ишак уже того...

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


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

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

SD>Во-вторых, я не верю в месяц на добавление кнопки. Имею на то право.

Я тоже не верил, пока не протащил свою первую кнопку. Реально конечно не месяц месяц на кнопку, а месяц на кнопки для готовой фичи. Это время с добавлением, отладкой, багфиксом кода связывания кнопок. Добавил кнопку — а в N+1 сценарии кнопка теряет свое состояние, из нажатого становится отжатой. В N+2 кнопка создает проблемы для других кнопок. В N+3 кнопка создает побочный эффект — креш если открыта вьюха A.
Такая вот орхетектура, что бы только отыскать код который влияет на кнопки или наоборот, надо убить вагон времени.

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

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

SD>И его митигировали путём откладывания.

Правильно. Оттягивали решение до тех пор, пока девелоперы не стали 100% времени писать водопроводный код. И проект ожидаемо умер и попал на воскрешение, где им и занялся me

SD>Это тоже обычный способ решения проблем. Путём откладывания. А там ишак уже того...

Новый слово в инженерии — решать проблему путём её откладывания. Попробуй на практике применить, найди работу с почасовой оплатой, когда кастомер будет время от времени или постоянно пересматривать ваши репорты, чего сделано и сколько затрачено. Только естесвенно все репортай честно — добавлял кнопку месяц, значит пишешь: "таск нумер ААА12345 'байндинг кнопки XXX' 160 часов."

P.S. У меня вопрос напоследок, не собирался ли ты ЗП команды за месяц получить путем откладывания проблемы на потом ?

I>Правильно. Оттягивали решение до тех пор, пока девелоперы не стали 100% времени писать водопроводный код. И проект ожидаемо умер и попал на воскрешение, где им и занялся me

Видишь как здорово. Все довольны. Тебе есть работа, заказчикам — проект, инвесторам — деньги много лет капали. Причем, сдается мне, неплохие, раз осталось на реанимацию полумёртвого проекта. Жизнь как она есть.

I>Новый слово в инженерии — решать проблему путём её откладывания.

Прямо мои слова, из 2007 (?) года. Я тоже негодовал и демонстрировал бурю протеста. Видишь, всего-то понадобилось 6 лет и работа на разных должностях, чтобы понять — и такое решение тоже решение. Обидно, но факт: это зачастую работает много лучше, чем созывать митинги, генерировать тонну виртуальной бумаги и заниматься умным рефакторингом.
Цинично? Разумеется. А как иначе. Такова жизнь.

On 03.05.2013 9:35, Ikemefula wrote:

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

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

I>>Правильно. Оттягивали решение до тех пор, пока девелоперы не стали 100% времени писать водопроводный код. И проект ожидаемо умер и попал на воскрешение, где им и занялся me

SD>Видишь как здорово. Все довольны. Тебе есть работа, заказчикам — проект, инвесторам — деньги много лет капали. Причем, сдается мне, неплохие, раз осталось на реанимацию полумёртвого проекта. Жизнь как она есть.

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

I>>Новый слово в инженерии — решать проблему путём её откладывания.

SD>Прямо мои слова, из 2007 (?) года. Я тоже негодовал и демонстрировал бурю протеста. Видишь, всего-то понадобилось 6 лет и работа на разных должностях, чтобы понять — и такое решение тоже решение. Обидно, но факт: это зачастую работает много лучше, чем созывать митинги, генерировать тонну виртуальной бумаги и заниматься умным рефакторингом.

Да я заметил, многие считают, что распилом заниматься это очень выгодно и круто.

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

>> Новый слово в инженерии — решать проблему путём её откладывания.
V>Не только в инженерии, а вообще в человеческой деятельности, "решение
V>проблемы путем ее откладывания" — иногда самый оптимальный путь.

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

On 05.05.2013 9:01, Ikemefula wrote:

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

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

V>On 05.05.2013 9:01, Ikemefula wrote:

>> Нет такого в инженерии, инженерия вся про решение проблем, а не про
>> переписывание репортов с той целью, что бы кастомер не догадался, что
>> платит за водопроводный код а не функционал.
V>Мне, разговор здесь с тобой, напоминает разговор с ребенком из детского
V>сада у которого куча "Почему?".

Так ты попробуй выйти из детского сада, я только за !

Здравствуйте, Аноним, Вы писали:

А>В ИТ около 15 лет, был ~6 конторах, ни разу не слышал чтобы хоть раз чей-нибудь код называли хорошим, только и слышно здесь говно, там говно.
А>Даже нет у него в отличие от говнокода названия своего, там вареньекод, медокод.
А>Если знаете какой-нибудь опенсорс или есть свой код в интернете пришлите ссылочку посмаковать, хоть раз взглянуть на это чудо которое не назовут говном.

У меня в голове давно крутится идея сделать сервис именно с таким названием — "говнокод". Суть в том, что одни разработчи выкладывают туда свой код, а более опытные коллеги подробно объясняют им, почему их код — говно. Движущей силой было бы желание одних прокачать скиллы, умноженное на желание других самоутвердится за счёт менее опытных коллег. Явление распространённое. С другой стороны думаю, что у человека достаточно умного, чтобы объяснить почему код реально говно, нет желания самоутвеждаться, унижая других. Что думаете, коллеги, стрельнет сервис или нет?

Здравствуйте, Аноним, Вы писали:


А>У меня в голове давно крутится идея сделать сервис именно с таким названием — "говнокод". Суть в том, что одни разработчи выкладывают туда свой код, а более опытные коллеги подробно объясняют им, почему их код — говно. Движущей силой было бы желание одних прокачать скиллы, умноженное на желание других самоутвердится за счёт менее опытных коллег. Явление распространённое. С другой стороны думаю, что у человека достаточно умного, чтобы объяснить почему код реально говно, нет желания самоутвеждаться, унижая других. Что думаете, коллеги, стрельнет сервис или нет?

Уже всё наговнокодили до тебя

http://codereview.stackexchange.com/

Здравствуйте, Alexéy Sudachén, Вы писали:

AS>В общем, то что код 'пахнет', это не характеристика кода, это характеристика того кто 'нюхает'.

Говнокод конечно у каждого свой, но обычно у разных сортов говнокода есть одна общая черта — он непонятен.
А раз он непонятен, он несет в себе риски:
1) багов в реализации
2) багов при изменении
3) багов при изменении использования
и других проблем.

Причем все эти риски достаются именно нюхающему. Понятное дело что ему это не нравится

Здравствуйте, Аноним, Вы писали:

А>У меня в голове давно крутится идея сделать сервис именно с таким названием — "говнокод". Суть в том, что одни разработчи выкладывают туда свой код, а более опытные коллеги подробно объясняют им, почему их код — говно.Что думаете, коллеги, стрельнет сервис или нет?

может взлететь

+1
У boost.ublas ещё странная документация, и сама библиотека не очень функциональна. Используем Eigen

Библиотека Netty из Java очень понравилась.