Здравствуйте, reversecode, Вы писали:
R>если даже несколько сот многовато, для программиста >5 лет R>это проф не пригодность
Для программиста, независимо от стажа, способность анализировать чужой код, за пределами самого общего понимания, вообще не является профессиональной необходимостью. Профессиональная функция программиста — создавать код, а не "разматывать" его. То есть, если программист способен создать код в рамках заданных условий (задача, время, стоимость, надежность и т.п.) — он однозначно полностью профпригоден. Умение копаться в чужом коде и переделывать его — сугубо дополнительные способности.
R>>В метафоре про чукчу речь идет об умении читать и только. На то она и метафора.
ЕМ>Тогда и не стоило ее развивать с двусмысленными намеками.
Это почему? По моему скромному мнению, программист, не умеющий анализировать чужой код, очень похож на чукчу из известного анектода. Я же могу выразить свое мнение?
--
Не можешь достичь желаемого — пожелай достигнутого.
ЕМ>Для программиста, независимо от стажа, способность анализировать чужой код, за пределами самого общего понимания, вообще не является профессиональной необходимостью. Профессиональная функция программиста — создавать код, а не "разматывать" его. То есть, если программист способен создать код в рамках заданных условий (задача, время, стоимость, надежность и т.п.) — он однозначно полностью профпригоден. Умение копаться в чужом коде и переделывать его — сугубо дополнительные способности.
Тут невольно вспмонилось "чука — не читатель, чукча — писатель..."
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, sergey2b, Вы писали:
S>мне надо мигрировать приложение с win на linux S>примерно несколько сот тыс строк S>состоит из N самописных библиотек (те исходный код доступен) которые в итоге собираються в юинарник
S>уже понятно что часть кода реально не используеться S>есть ли какая либо возможность определить какой код реально используеться в приложении
1. Собираете всё в статические либы.
2. Потом компилируете целевые исполняемые файлы, генерируя при этом map файл
3. Затем парсите его и выделеяте то что используются
4. ...
5. PROFIT
Евгений Музыченко:
ЕМ>Для программиста, независимо от стажа, способность анализировать чужой код, за пределами самого общего понимания, вообще не является профессиональной необходимостью. Профессиональная функция программиста — создавать код, а не "разматывать" его.
Неумение читать код, это профнепригодность. Дали тебе задачу передвинуть кнопку на форме, и ты сядешь всё с нуля переписывать?
Модератор-националист Kerk преследует оппонентов по политическим мотивам.
Натравить тулзы с code coverage и прогнать софт под как можно большим количеством юзкейсов. Либо тщательно проанализировать код самому. Либо понадеяться, что линкер выкинет лишнее.
Здравствуйте, sergey2b, Вы писали:
S>мне надо мигрировать приложение с win на linux S>примерно несколько сот тыс строк S>состоит из N самописных библиотек (те исходный код доступен) которые в итоге собираються в юинарник
S>уже понятно что часть кода реально не используеться S>есть ли какая либо возможность определить какой код реально используеться в приложении
clion вроде умеет, но я давно его не использовал
поэтому "вроде".
Здравствуйте, sergey2b, Вы писали:
S>линкер не вариант тк конечная цель сэкономить время на переноси исходного кода
Почему не вариант?
Ты просто решил, что надо на целевом линуксе смотреть, что выкинулось, а что нет. А надо смотреть виндовый вариант, что в нем используется, и от этого плясать.
Здравствуйте, sergey2b, Вы писали:
S>Здравствуйте, flаt, Вы писали:
F>>Натравить тулзы с code coverage и прогнать софт под как можно большим количеством юзкейсов. Либо тщательно проанализировать код самому. Либо понадеяться, что линкер выкинет лишнее.
S>а можно название 1-2 таких утилит для примера
Линкер — норм. Если он выкинул что-то, то это явно не нужно.
Другое дело, что линкер и прочие map-файлы не смогут обнаружить, например, что реально функция fn в таком фрагменте не вызывается: if (sinf(x) > 2.0f) { fn(); }
А source based code coverage как раз разметит, что при использовании программы условие в этой строке не становилось истинным никогда, и соответственно функция fn не нужна (если она больше нигде не вызывается).
Здравствуйте, sergey2b, Вы писали:
S>уже понятно что часть кода реально не используеться S>есть ли какая либо возможность определить какой код реально используеться в приложении
Кроме уже предложенных, можно попробовать профилировщики. Они выдают список всех ф-ций, которые вызывались. Если список можно вывести в текстовый файл, еще лучше. Еще поискать что-то типа call graph profiler.
Вот тут что-то делают https://www.cs.sfu.ca/~wsumner/teaching/886/callgraph-profiler.html
Здравствуйте, sergey2b, Вы писали:
S>есть ли какая либо возможность определить какой код реально используеться в приложении
Возьми код, который ТОЧНО используется (main и далее). И подключай сорцы по сообщениям линкера. Если совсем перфекционист — в подключенном сорце комментируй всё, кроме нужной функции. А потом раскомментируй по мере продвижения.
Здравствуйте, rg45, Вы писали:
R>А тут невольно вспоминается другой афоризм — про бабушку и бороду.
Ну давайте так: подпишетесь под утверждением, будто любой писатель, востребованный не самой маргинальной частью населения, способен быстро и грамотно анализировать чужие литературные произведения, независимо от их стиля и объема? То есть, сможет, бегло пробежавшись по тексту, выписать характеры персонажей, отметить возможные противоречия, нарисовать граф сюжетных линий, опять же выделив возможные нестыковки, очертить блоки повествования, классифицировать произведение по стилям и т.п.
Ну и до кучи: сможет ли любой успешный террорист без дополнительной подготовки столь же хорошо выполнять контртеррористическую работу?
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, IID, Вы писали:
S>>>есть ли какая либо возможность определить какой код реально используеться в приложении
IID>>Возьми код, который ТОЧНО используется (main и далее). И подключай сорцы по сообщениям линкера. Если совсем перфекционист — в подключенном сорце комментируй всё, кроме нужной функции. А потом раскомментируй по мере продвижения.
M>За пару лет управится
Отставить панику.
Лично портировал 5,8мб исходников (плюс либы типа OpenSSL, Jpeg и т.д.) с Lin на Win. Точнее добавлял ещё одну платформу для запуска.
ХЗ сколько там строк. Наверное раза в 2 побольше чем 100к.
Приложение под Linux Box, с кучей UI на OpenGL.
Очень повезло что:
— приложение уже содержало 2 платформы: Desktop и Embedded Linux. И было поделено на слои. Для GL/GLES сущностей существовали обёртки. Пришлось только часть Posix вызовов проэмулировать с помощью Win32, причём для некритических я сильно не заморачивался.
— в консоль Win10 завезли флаг поддержки Escape последовательностей VT100 — логи в терминале раскрасились сами собой. А логирования там просто дохрена.
Справился где-то за неделю. Получил возможность собирать, запускать и отлаживать прямо из студии.
Здравствуйте, K13, Вы писали:
K13>А вообще -- есть риск "не поймать" обработчики исключительных ситуаций, например таймаут при запросе в БД, исчерпание места на диске и т.п.
Конечно. Именно поэтому подсчёт покрытия часто используется совместно с тестами и прочим Continuous Integration: смотрим на непокрытые участки кода и либо удаляем их (как потерявшие актуальность), либо добавляем тест, который приведёт к срабатыванию нужной ветки.
Ну и в любом случае, имея детальную карту покрытия можно легко её огрубить до уровня функции, объектника, или библиотеки. А уже потом разбираться с такими крупными блоками — если из всей библиотеки ни одной функции не было вызвано, то на неё надо посмотреть повнимательнее на предмет полезности.
Здравствуйте, reversecode, Вы писали:
R>у вас есть в друзьях такие проф писатели ?
Прямо, чтоб в друзьях — нет, но общаться приходилось. Равно как и со множеством разного рода людей, занимающихся как синтезом, так и анализом. Совершенно очевидно, что эти способности не являются двунаправленными, симметричными. У наиболее успешных они и перекрываются наиболее полно, однако далеко не все, кто способен интересно и увлекательно хоть писать, хоть рассказывать, имеют сколько-нибудь выдающиеся способности к анализу.
R>у вас есть террорестический опыт ?
Чтобы понимать основы, не нужно личного опыта. Вы никогда не задумывались о том, почему в армии тех, кто способен установить и замаскировать мину, минимум на порядок больше, чем тех, кто способен ее найти и обезвредить?
R>а то что делаете вы это уводите тему в сторону да еще и не удачными примерами
Так давайте же удачных примеров. Или, по-Вашему, программирование — совершенно уникальная сфера деятельности, не имеющая себе аналогов?
R>а теперь видимо вы готовы рассказать нам форумчанам какими же умениями и знаниями должен обладать программист с 10 лет опыта ?
Я уже рассказал, что умение "сочинять вообще" не предполагает равного ему умения "разбираться вообще". В этих занятиях задействованы разные свойства мозга. У кого-то мозги "симметричные", и они одинаково легко как сочиняют, так и разбираются, а у кого-то эти свойства сдвинуты в одну сторону, причем достаточно сильно.
Здравствуйте, IID, Вы писали:
S>>есть ли какая либо возможность определить какой код реально используеться в приложении
IID>Возьми код, который ТОЧНО используется (main и далее). И подключай сорцы по сообщениям линкера. Если совсем перфекционист — в подключенном сорце комментируй всё, кроме нужной функции. А потом раскомментируй по мере продвижения.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Совсем не умеющий — похож. Так или иначе анализировать способен любой программист. Однако, делать это на уровне "как дышать" (ну, или как читать запоем тот же роман) — далеко не каждый. Для этого нужно иметь определенным образом устроенный мозг, а не только знания и опыт.
Моя младшенькая бьет меня иногда моим же оружием: "Папа, помоги — вот в этом месте какая-то фигня". Смотрю код, а там — ни в сказке сказать, ни пером описать. Смотрю, смотрю... В конце концов не выдерживаю: "а ты что сделать хотела, вообще?" Так она мне в ответ: "учись читать чужой код!"
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, Bill Baklushi, Вы писали:
ЕМ>>Для программиста, независимо от стажа, способность анализировать чужой код, за пределами самого общего понимания, вообще не является профессиональной необходимостью.
BB>Неумение читать код, это профнепригодность.
А неумение понять разницу между "читать" и "анализировать за пределами самого общего понимания" — это глупость?
Здравствуйте, rg45, Вы писали:
R>Моя младшенькая бьет меня иногда моим же оружием: "Папа, помоги — вот в этом месте какая-то фигня". Смотрю код, а там — ни в сказке сказать, ни пером описать. Смотрю, смотрю... В конце концов не выдерживаю: "а ты что сделать хотела, вообще?" Так она мне в ответ: "учись читать чужой код!"
Ну, сказал бы: "лапа, этот трэш я просто перепишу заново"
Здравствуйте, Евгений Музыченко, Вы писали:
R>>И когда программист уходит из конторы, поддержа продукта прекращается?
ЕМ>Если оставшиеся программисты не в состоянии поддерживать продукт — да, примеров достаточно. Чтобы этого не происходило, одни конторы принимают меры, облегчающие программистам понимание и сопровождение чужого (а также и своего) кода, другие — нанимают программистов с развитыми аналитическими способностями.
А бывают еще и третьи конторы — где понимание "чужого" кода считается нормой. Для этого утверждается корпоративный стиль кодирования и на систематической основе проводятся code-review. И процесс поддержки продукта не завязан на авторов кода, коих множество. Вот мне только такие конторы и попадались почему-то. Совпадение, наверное.
--
Не можешь достичь желаемого — пожелай достигнутого.
мне надо мигрировать приложение с win на linux
примерно несколько сот тыс строк
состоит из N самописных библиотек (те исходный код доступен) которые в итоге собираються в юинарник
уже понятно что часть кода реально не используеться
есть ли какая либо возможность определить какой код реально используеться в приложении
Здравствуйте, flаt, Вы писали:
F>Натравить тулзы с code coverage и прогнать софт под как можно большим количеством юзкейсов. Либо тщательно проанализировать код самому. Либо понадеяться, что линкер выкинет лишнее.
а можно название 1-2 таких утилит для примера
я сейчас анализирую но кода овер дофига (хотя некоторые стратегии я придумал)
линкер не вариант тк конечная цель сэкономить время на переноси исходного кода
W>Другое дело, что линкер и прочие map-файлы не смогут обнаружить, например, что реально функция fn в таком фрагменте не вызывается: if (sinf(x) > 2.0f) { fn(); }
W>А source based code coverage как раз разметит, что при использовании программы условие в этой строке не становилось истинным никогда, и соответственно функция fn не нужна (если она больше нигде не вызывается).
"В военное время значение синуса может достигать и четырех!"
А вообще -- есть риск "не поймать" обработчики исключительных ситуаций, например таймаут при запросе в БД, исчерпание места на диске и т.п.
Линкер в этом отношении надежнее: то что он не взял -- портировать не нужно.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Для программиста, независимо от стажа, способность анализировать чужой код, за пределами самого общего понимания, вообще не является профессиональной необходимостью. Профессиональная функция программиста — создавать код, а не "разматывать" его. То есть, если программист способен создать код в рамках заданных условий (задача, время, стоимость, надежность и т.п.) — он однозначно полностью профпригоден. Умение копаться в чужом коде и переделывать его — сугубо дополнительные способности.
Ничего подобного.
Код он не сферический в вакууме. А взаимодействует с другим кодом (ОС, библиотеками и т.д.).
Даже программисту-одиночке придётся изучать документацию, а часто и реализацию того, с чем он работает.
А в командах необходимость понимать чужой код возрастает многократно.
Иначе программирование превращается в "шаманство". Когда вместо детального выяснения причин делают перебор разных вариантов, подстановку разнообразных затычек и костылей, без полного понимания сути происходящего.
Причём заметь, даже пресловутое "самое общее понимание" — оно не возникает внезапно изниоткуда. Это тысячи часов опыта. Когда глядя на код ты сразу понимаешь что и зачем. А не пережёвываешь более низкоуровневые конструкции.
Здравствуйте, IID, Вы писали:
IID>Код он не сферический в вакууме. А взаимодействует с другим кодом (ОС, библиотеками и т.д.). IID>Даже программисту-одиночке придётся изучать документацию, а часто и реализацию того, с чем он работает.
За документацию разговора нет. А вот реализацию приходится изучать исключительно при нехватке документации (если, конечно, не ставится целью сделать "такое же, но с перламутровыми пуговицами").
IID>А в командах необходимость понимать чужой код возрастает многократно.
Именно поэтому в командах стараются применять стандарты кодирования, без которого способность понимать чужой код многократно падает. Если бы каждому программисту была имманентно присуща способность к хорошему пониманию чужого кода, в этом не было бы особой необходимости.
IID>Причём заметь, даже пресловутое "самое общее понимание" — оно не возникает внезапно изниоткуда. Это тысячи часов опыта. Когда глядя на код ты сразу понимаешь что и зачем.
Это не только опыт, но еще и определенным образом устроенные мозги, и определенные склонности. Иначе можно скатиться и до того, что каждый писатель, способный создать качественный роман, должен, лишь глядя на чужое творение (не читая его полностью и вдумчиво), видеть все характеры, сюжетные линии, их возможные нестыковки и т.п.
Здравствуйте, Евгений Музыченко, Вы писали:
R>>Тут невольно вспмонилось "чука — не читатель, чукча — писатель..."
ЕМ>Если чукча напишет что-нибудь достаточно дельное, то он таки писатель, увы и ах, даже если и не читал ничего.
А тут невольно вспоминается другой афоризм — про бабушку и бороду.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, sergey2b, Вы писали:
S>мне надо мигрировать приложение с win на linux S>примерно несколько сот тыс строк S>состоит из N самописных библиотек (те исходный код доступен) которые в итоге собираються в юинарник
S>уже понятно что часть кода реально не используеться S>есть ли какая либо возможность определить какой код реально используеться в приложении
Я позволю себе слегка отклониться от прямого ответа на прямой вопрос. Нужно иметь в виду, что тот факт, что какой-либо библиотечный код не используется в каком-либо конкретном приложении, не обязательно означает, что данный код бесполезен. Ведь такова природа бибилиотек — служить хранилищем всякой всячины, более или мене полезной, которая когда-нибудь где-нибудь может пригодиться. Линкер сам разберется, что нужно взять из библиотеки для того или иного приложения. Если библиотека нормально структурирована (разбита на объектные модули), то никаких проблем с избыточным размером бинарей не возникает, как правило.
--
Не можешь достичь желаемого — пожелай достигнутого.
R>Я позволю себе слегка отклониться от прямого ответа на прямой вопрос. Нужно иметь в виду, что тот факт, что какой-либо библиотечный код не используется в каком-либо конкретном приложении, не обязательно означает, что данный код бесполезен. Ведь такова природа бибилиотек — служить хранилищем всякой всячины, более или мене полезной, которая когда-нибудь где-нибудь может пригодиться. Линкер сам разберется, что нужно взять из библиотеки для того или иного приложения. Если библиотека нормально структурирована (разбита на объектные модули), то никаких проблем с избыточным размером бинарей не возникает, как правило.
проблемма не в размере
а в том что я портирую приложение с win на linux
и уже понятно что если я буду портировать все в сроки я не уложусь
Здравствуйте, sergey2b, Вы писали:
S>проблемма не в размере S>а в том что я портирую приложение с win на linux S>и уже понятно что если я буду портировать все в сроки я не уложусь
Да, я понял задачу. Просто наскольно это будет правильно — сделать фильтрацию библиотечного кода на основании лишь использования/неиспользования в одном отдельно взятом приложении? Это набор библиотек создавался только для этого приложения?
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, rg45, Вы писали:
R>Здравствуйте, sergey2b, Вы писали:
S>>проблемма не в размере S>>а в том что я портирую приложение с win на linux S>>и уже понятно что если я буду портировать все в сроки я не уложусь
R>Да, я понял задачу. Просто наскольно это будет правильно — сделать фильтрацию библиотечного кода на основании лишь использования/неиспользования в одном отдельно взятом приложении? Это набор библиотек создавался только для этого приложения?
нет 10+ приложений которые мне же придеться портировать
я понимаю вы правы, но реальная жизнь не идеальна
я и так завяз с переписыванием некоторых функций которые писались в расете на винду
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Ну давайте так: подпишетесь под утверждением, будто любой писатель, востребованный не самой маргинальной частью населения, способен быстро и грамотно анализировать чужие литературные произведения, независимо от их стиля и объема?
А зачем мне подписываться под твоими фантазиями? В метафоре про чукчу речь идет об умении читать и только. На то она и метафора.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, rg45, Вы писали:
R>>А тут невольно вспоминается другой афоризм — про бабушку и бороду.
ЕМ>Ну давайте так: подпишетесь под утверждением, будто любой писатель, востребованный не самой маргинальной частью населения, способен быстро и грамотно анализировать чужие литературные произведения, независимо от их стиля и объема? То есть, сможет, бегло пробежавшись по тексту, выписать характеры персонажей, отметить возможные противоречия, нарисовать граф сюжетных линий, опять же выделив возможные нестыковки, очертить блоки повествования, классифицировать произведение по стилям и т.п.
у вас есть в друзьях такие проф писатели ?
уверен что нет
поэтому заниматься фантазированием не будем
ЕМ>Ну и до кучи: сможет ли любой успешный террорист без дополнительной подготовки столь же хорошо выполнять контртеррористическую работу?
у вас есть террорестический опыт ?
уверен что тоже нет
а то что делаете вы это уводите тему в сторону да еще и не удачными примерами
а теперь видимо вы готовы рассказать нам форумчанам какими же умениями и знаниями должен обладать программист с 10 лет опыта ?
ну и как вы говорите до кучи
git ls-files | xargs cat | wc -l
что бы каждый смог оценить свои и другие проекты что бы иметь представление сколько же это 100kloc
Здравствуйте, rg45, Вы писали:
R>программист не умеющий анализировать чужой код, очень похож на чукчу из известного анектода.
Совсем не умеющий — похож. Так или иначе анализировать способен любой программист. Однако, делать это на уровне "как дышать" (ну, или как читать запоем тот же роман) — далеко не каждый. Для этого нужно иметь определенным образом устроенный мозг, а не только знания и опыт.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Для программиста, независимо от стажа, способность анализировать чужой код, за пределами самого общего понимания, вообще не является профессиональной необходимостью. Профессиональная функция программиста — создавать код, а не "разматывать" его. То есть, если программист способен создать код в рамках заданных условий (задача, время, стоимость, надежность и т.п.) — он однозначно полностью профпригоден. Умение копаться в чужом коде и переделывать его — сугубо дополнительные способности.
А поддержка программного продукта это чья функция — не программиста? Кто должен разгребать баги с продакшена?
--
Не можешь достичь желаемого — пожелай достигнутого.
IID>Лично портировал 5,8мб исходников (плюс либы типа OpenSSL, Jpeg и т.д.) с Lin на Win. Точнее добавлял ещё одну платформу для запуска. IID>ХЗ сколько там строк. Наверное раза в 2 побольше чем 100к. IID>Приложение под Linux Box, с кучей UI на OpenGL.
Уже под Linux — +1
IID>Очень повезло что:
Да, повезло
IID>- приложение уже содержало 2 платформы: Desktop и Embedded Linux. И было поделено на слои. Для GL/GLES сущностей существовали обёртки. Пришлось только часть Posix вызовов проэмулировать с помощью Win32, причём для некритических я сильно не заморачивался.
Вооот, уже 1) платформозависимый код выделили в отдельные подсистемы до тебя; 2) Posix прост как валенок по сравнению с богатством виндовых API => порт Posix->Win32 на порядок проще, чем порт Win32->Posix
IID>- в консоль Win10 завезли флаг поддержки Escape последовательностей VT100 — логи в терминале раскрасились сами собой. А логирования там просто дохрена.
О, а это интересно. Я себе делал вывод сообщений в консоль, для вывода в виндовую консоль использовал виндовые функции работы с цветами консоли, а для MinGW-шного баша использовал Escape последовательности.
Хотя у меня под любой виндой работает, но пришлось поискать, из под какого процесса меня запускали.
А десяточная консоль вообще без приседаний понимает escape'ы?
Кстати, раз зашла речь про Escape последовательности — может в курсе, как там в линупсе, при перенаправлении в файл кто их стрипает? Я сделал проверкой, является ли консольный хэндл файловым, или как-то так, и в зависимости от этого раскрашиваю или нет. Так себе решение, но работает.
И призовой вопрос — почему под виндой если я в MinGW-баше запускаю гит, то он вывод раскрашивает, а если я из своей проги запускаю гит, и свою прогу запускаю под тем же башем, то вывод выдается унылый одноцветный?
IID>Справился где-то за неделю. Получил возможность собирать, запускать и отлаживать прямо из студии.
Обратная задача посложнее, на мой взгляд. Конечно, зависит от сложности системы в целом и от того, насколько Win API использовано по полной, но имхо раз в несколько будет посложнее
Здравствуйте, reversecode, Вы писали:
R>ну и как вы говорите до кучи R>git ls-files | xargs cat | wc -l R>что бы каждый смог оценить свои и другие проекты что бы иметь представление сколько же это 100kloc
я некогда не задумывался сколько там кода на самом деле, тк код на stl портируеться легко
порция на эту неделю которую я еще не завершил 2319182 строк (сколько то можно вычисть make files)
Здравствуйте, Bill Baklushi, Вы писали:
ЕМ>>Для программиста, независимо от стажа, способность анализировать чужой код, за пределами самого общего понимания, вообще не является профессиональной необходимостью. Профессиональная функция программиста — создавать код, а не "разматывать" его.
BB>Неумение читать код, это профнепригодность. Дали тебе задачу передвинуть кнопку на форме, и ты сядешь всё с нуля переписывать?
Есть код, который проще переписать, чем понять, что он делает. У нас чел уволился из другого отдела, полтора года прошивку писал, под линупсом, в эклипсе. А у нас в отделе все технологии под кейл заточены, и под винду все, включая кучу полезного технологического софта. Это гавно на меня скинули, ну и отправили меня в командировку в Феодосию по этой теме. Так вот я там, сидя в горящем танке и положив ноут на сапоги убитого друга, переписал всё за две недели, прошерстив схемоту и пообщавшись с наладчиками системы
Здравствуйте, Евгений Музыченко, Вы писали:
R>>А поддержка программного продукта это чья функция — не программиста?
ЕМ>Собственные творения обязан понимать и уметь чинить любой — хоть программист, хоть слесарь.
И когда программист уходит из конторы, поддержа продукта прекращается?
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, rg45, Вы писали:
R>И когда программист уходит из конторы, поддержа продукта прекращается?
Если оставшиеся программисты не в состоянии поддерживать продукт — да, примеров достаточно. Чтобы этого не происходило, одни конторы принимают меры, облегчающие программистам понимание и сопровождение чужого (а также и своего) кода, другие — нанимают программистов с развитыми аналитическими способностями.
Здравствуйте, rg45, Вы писали:
R>А бывают еще и третьи конторы — где понимание "чужого" кода считается нормой. Для этого утверждается корпоративный стиль кодирования и на систематической основе проводятся code-review.
Маленькое уточнение: понимание считается нормой до введения указанных мер, или после того, как они возымели действие? То есть, в какой доле контор к каждому из программистов предъявляется требование быстро и правильно понимать любой код, независимо от того, кем, когда и для чего он был создан?
Здравствуйте, Евгений Музыченко, Вы писали:
R>>А бывают еще и третьи конторы — где понимание "чужого" кода считается нормой. Для этого утверждается корпоративный стиль кодирования и на систематической основе проводятся code-review.
ЕМ>Маленькое уточнение: понимание считается нормой до введения указанных мер, или после того, как они возымели действие?
Странно ты вопрос ставишь. Указаныые меры введены потому что понимание считается нормой. А не "до" или "после".
R>То есть, в какой доле контор к каждому из программистов предъявляется требование быстро и правильно понимать любой код, независимо от того, кем, когда и для чего он был создан?
Во всех, которые я видел. Все коммерческие фирмы существуют ради получения прибыли от производимого продукта. А содержание гениев, творящих шедвры, это уже не коммерция, а что-то другое.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, rg45, Вы писали:
R>Указаныые меры введены потому что понимание считается нормой.
Если бы понимание (снова уточню: достаточно быстрое и точное, а не абы какое) чужого кода (который, прежде всего, основан на чужом мышлении, чужом подходе, чужом стиле, чужом формате и т.п.) считалось (и являлось) нормой, то не было бы явной нужды в унификации этих самых подходов, стилей, форматов и прочего. Нравится одному писать по три goto на странице — и ради бога, любому понятно. Нравится другому записывать по нескольку составных операторов в одну строку — и это ради бога, любой махом разберется. Однако ж, зачем-то всю эту унификацию и стандартизацию поддерживают. Так зачем?
R>Все коммерческие фирмы существуют ради получения прибыли от производимого продукта. А содержание гениев, творящих шедвры, это уже не коммерция, а что-то другое.
То есть, с одной стороны, по-Вашему получается, что способности любого программиста к разгребанию и поддержке чужого кода, независимо от его качества, должны быть примерно равны его способностям к производству собственного. А с другой стороны, типовой программист, содержание которого экономически выгодно, с разгребанием произвольного кода, внезапно, справляется плохо, и почему-то нуждается в костылях вроде подробной документации, внятных комментариев, грамотного структурования, хорошего стиля и т.п. Мне в этом видится явное противоречие, а Вам?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>То есть, с одной стороны, по-Вашему получается, что способности любого программиста к разгребанию и поддержке чужого кода, независимо от его качества, должны быть примерно равны его способностям к производству собственного. А с другой стороны, типовой программист, содержание которого экономически выгодно, с разгребанием произвольного кода, внезапно, справляется плохо, и почему-то нуждается в костылях вроде подробной документации, внятных комментариев, грамотного структурования, хорошего стиля и т.п. Мне в этом видится явное противоречие, а Вам?
"Примерно равны", "подробная документация", "внятные комментарии", "костыли" — это откуда все взялось? Я сказал только то, что сказал. И избавь меня, пожалуйста, от необходимости отстаивать твои домыслы.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, Marty, Вы писали:
M>Уже под Linux — +1
Не знаю в чём ты увидел плюс.
M>Вооот, уже 1) платформозависимый код выделили в отдельные подсистемы до тебя;
далеко не весь
M>2) Posix прост как валенок по сравнению с богатством виндовых API => порт Posix->Win32 на порядок проще, чем порт Win32->Posix
ой не скажи...
как начнутся танцы с форками, сигналами, потоками и синхронизацией — простота тут же испарится.
а если tty-specific вещи то выключайте свет, кидайте бомбы.
M>А десяточная консоль вообще без приседаний понимает escape'ы?
Только флаг выставить.
M>Кстати, раз зашла речь про Escape последовательности — может в курсе, как там в линупсе, при перенаправлении в файл кто их стрипает?
Вот видишь! А это только самая верхушка TTY айсберга. Попробуй сделать полноценный remote shell, чтобы и ^ ввод работал, и ncurses приложения — и на..программируешься и напляшешься.
Я не разбирался, но считаю что они просто перестают генериться, если выходной файл их не поддерживает. Проверка: какой-нить посылкой ioctl в out-хендл.
Например dmesg имеет параметр -L/--color. Пайпинг приводит к пропаданию цвета. Смена auto на always ВНЕЗАПНО возвращает ESC последовательности на выходе из пайпа.
M>Я сделал проверкой, является ли консольный хэндл файловым, или как-то так, и в зависимости от этого раскрашиваю или нет. Так себе решение, но работает.
Параметр добавил ?
M>И призовой вопрос — почему под виндой если я в MinGW-баше запускаю гит, то он вывод раскрашивает, а если я из своей проги запускаю гит, и свою прогу запускаю под тем же башем, то вывод выдается унылый одноцветный?
Здравствуйте, IID, Вы писали:
M>>Уже под Linux — +1
IID>Не знаю в чём ты увидел плюс.
M>>Вооот, уже 1) платформозависимый код выделили в отдельные подсистемы до тебя;
IID>далеко не весь
Но это уже хоть что-то, по сравнению с портом нативного виндового в POSIX
M>>2) Posix прост как валенок по сравнению с богатством виндовых API => порт Posix->Win32 на порядок проще, чем порт Win32->Posix
IID>ой не скажи... IID>как начнутся танцы с форками, сигналами, потоками и синхронизацией — простота тут же испарится.
POSIX таки проще сделать через WinAPI, чем WinAPI через POSIX. Даже с танцами
IID>а если tty-specific вещи то выключайте свет, кидайте бомбы.
А тут можно и выкинуть, если надо по-быстрому
M>>А десяточная консоль вообще без приседаний понимает escape'ы?
IID>Только флаг выставить.
Что за флаг?
M>>Кстати, раз зашла речь про Escape последовательности — может в курсе, как там в линупсе, при перенаправлении в файл кто их стрипает?
IID>Вот видишь! А это только самая верхушка TTY айсберга. Попробуй сделать полноценный remote shell, чтобы и ^ ввод работал, и ncurses приложения — и на..программируешься и напляшешься.
Ну, если полноценный remote shell — неотъемлемая и/или ключевая часть проекта — то да. Иначе — можно просто выкинуть всё вот это
IID>Я не разбирался, но считаю что они просто перестают генериться, если выходной файл их не поддерживает. Проверка: какой-нить посылкой ioctl в out-хендл. IID>Например dmesg имеет параметр -L/--color. Пайпинг приводит к пропаданию цвета. Смена auto на always ВНЕЗАПНО возвращает ESC последовательности на выходе из пайпа.
M>>Я сделал проверкой, является ли консольный хэндл файловым, или как-то так, и в зависимости от этого раскрашиваю или нет. Так себе решение, но работает.
IID>Параметр добавил ?
Нет. Автодетект. В линупсовой версии isatty или как-то так, в виндовой — как-то аналогично над хэндлом stdio сделал.
Особых требований не было, просто для своих утилит решил вывод подраскрасить, если что-то пошло не так. Никаких пайпов и ничего какого-то сложного не предполагалось, кроме перенаправления в файл
M>>И призовой вопрос — почему под виндой если я в MinGW-баше запускаю гит, то он вывод раскрашивает, а если я из своей проги запускаю гит, и свою прогу запускаю под тем же башем, то вывод выдается унылый одноцветный?
IID>Зачем нужен MinGW баш, когда есть WSL ?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Если оставшиеся программисты не в состоянии поддерживать продукт — да, примеров достаточно. Чтобы этого не происходило, одни конторы принимают меры, облегчающие программистам понимание и сопровождение чужого (а также и своего) кода, другие — нанимают программистов с развитыми аналитическими способностями.
Не понимаю, о каких оставшихся программистах идет речь. Я видел проект, который начинался в середине 70-х. До сих пор активно пилится.
Это я в самом дечале карьеры хотел все, что видел, к чертям переписать.
Однажды поучастствал в таком переписывании.
Здравствуйте, Privalov, Вы писали:
P>Не понимаю, о каких оставшихся программистах идет речь. Я видел проект, который начинался в середине 70-х. До сих пор активно пилится.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вот теми, кто не помер с тех времен, и пилится.
В том-то и дело, что нет.
Мне, кстати, тоже довелось однажды участвтвать в проекте, начавшемся, по слухам, до моего рождения или около того. Вот в нем были фрагменты, с которыми я не разобрался. Суровый матан, минимизация довольно злобного функционала, ссылку на математику авторы почему-то не оставили. Плюс идентифиикаторы, читаемые только математиками.
Здравствуйте, Privalov, Вы писали:
P>Вот в нем были фрагменты, с которыми я не разобрался. Суровый матан, минимизация довольно злобного функционала, ссылку на математику авторы почему-то не оставили. Плюс идентифиикаторы, читаемые только математиками.
выходит, что Вы профнепригодны. Ну и я, разумеется, тоже — бывает, что в упор не могу уяснить, как именно работает код всего из нескольких тысяч строк, чтобы в голове сформировалась цельная картинка. Банально уставал отслеживать переходы внутри мелких подпрограмм с неясным (для меня) смыслом. "Угадал все буквы, не смог прочитать слово". Взялся бы скрупулезно все выписывать, рисовать граф переходов и зависимостей, использовал бы какие-то технические средства анализа — скорее всего, преуспел бы. Но терпения и усидчивости, при отсутствии насущной потребности, не хватало. Не моё.
выходит, что Вы профнепригодны. Ну и я, разумеется, тоже — бывает, что в упор не могу уяснить, как именно работает код всего из нескольких тысяч строк, чтобы в голове сформировалась цельная картинка. Банально уставал отслеживать переходы внутри мелких подпрограмм с неясным (для меня) смыслом. "Угадал все буквы, не смог прочитать слово". Взялся бы скрупулезно все выписывать, рисовать граф переходов и зависимостей, использовал бы какие-то технические средства анализа — скорее всего, преуспел бы. Но терпения и усидчивости, при отсутствии насущной потребности, не хватало. Не моё.
Опять же все сильно зависит от предметной области. Суровый матан — вещь специфическая. Там без бутылки первоисточников не разобраться. И даже если они есть, надо знать не только матан, но и принципы именования математиками функций и переменных.
В описанном мною случае непосредственно матан править было не нужно. Требовалось сделать пару-тройку технтческих вещей. Файлы открыть, чтобы не падало сразу в случае чего. При чтении обработать ситуацию, если что-то не в том формате пришло. Положение осложнялось тем, что там не было отдельных процедур ввода-вывода. Математики все по месту писали. При этом они свободно ориентируются в пространстве 50 измерений, но открыть файл для них — это что-то непостижимое. Взаимодействуя с ними, я справился.
Граф переходов и зависимостей мне в свое время тоже пришлось делать. Но там тема знакомая была: принять из сокета, записать в БД, выполнив по дороге какие-то проверки.
И раз участвовал в полном переписывании проекта с отстойных инструментов и языков 80-х на передовые. Ну там только некоторые структуры были нужны. Остальное делали по документации.
Здравствуйте, Marty, Вы писали:
M>>>2) Posix прост как валенок по сравнению с богатством виндовых API => порт Posix->Win32 на порядок проще, чем порт Win32->Posix
IID>>ой не скажи... IID>>как начнутся танцы с форками, сигналами, потоками и синхронизацией — простота тут же испарится.
M>POSIX таки проще сделать через WinAPI, чем WinAPI через POSIX. Даже с танцами
Опять 25.
Нет, не проще.
fork ты через WinAPI не сделаешь никогда. Через NativeAPI — да, можно. Эту фичу винда поддерживала с рождения, т.к. подсистем там было изначально 3: WinAPI, posix, OS/2.
M>>>А десяточная консоль вообще без приседаний понимает escape'ы? IID>>Только флаг выставить. M>Что за флаг?
MSDN
M>Ну, если полноценный remote shell — неотъемлемая и/или ключевая часть проекта — то да. Иначе — можно просто выкинуть всё вот это
unixway
IID>>Например dmesg имеет параметр -L/--color. Пайпинг приводит к пропаданию цвета. Смена auto на always ВНЕЗАПНО возвращает ESC последовательности на выходе из пайпа. M>>>Я сделал проверкой, является ли консольный хэндл файловым, или как-то так, и в зависимости от этого раскрашиваю или нет. Так себе решение, но работает.
IID>>Параметр добавил ?
M>Нет. Автодетект.
Пля.
Читай что я пишу!
Параметр — для НАСИЛЬНОГО отключения говно-детектов.
M>В линупсовой версии isatty или как-то так, в виндовой — как-то аналогично над хэндлом stdio сделал.
Ты даже не потрудился посмотреть как оно работает...
Два запроса в гугл:
isatty -> _tcgetattr -> ioctl.
Ровно то, о чём я выше говорил:
IID>>Я не разбирался, но считаю что они просто перестают генериться, если выходной файл их не поддерживает. Проверка: какой-нить посылкой ioctl в out-хендл.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Ну давайте так: подпишетесь под утверждением, будто любой писатель, востребованный не самой маргинальной частью населения, способен быстро и грамотно анализировать чужие литературные произведения, независимо от их стиля и объема? То есть, сможет, бегло пробежавшись по тексту, выписать характеры персонажей, отметить возможные противоречия, нарисовать граф сюжетных линий, опять же выделив возможные нестыковки, очертить блоки повествования, классифицировать произведение по стилям и т.п.
Воу-Воу! Полегшэ!
Большинству достаточно что убийца дворецкий. Накрайняк сбоку припишут своё, что сосед-Мойша напел.
Профессиональная функция программиста — создавать код, а не "разматывать" его. То есть, если программист способен создать код в рамках заданных условий (задача, время, стоимость, надежность и т.п.) — он однозначно полностью профпригоден. Умение копаться в чужом коде и переделывать его — сугубо дополнительные способности.
