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

MTD>Здравствуйте, мыщъх, Вы писали:

М>>как можно программировать если сборка проекта занимает неделю многопроцессорного времени и потому осуществляется раз в квартал.
MTD>Ну это не важно. Сборка всего проекта != сборка отдельного компонента.
разумеется, сборку отдельного компонента можно осуществлять хоть каждый день. только смысла в этом нету. "компилируется != работает". это менят стиль разработки. что-то покрывается юнит-тестами, где-то пишутся функции-заглушки для тестирования вашего кода, который взаимодействует с сетевыми сервисами по XML-RPC, только доступа к сервисам у вас нету.

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

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

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

Здравствуйте, мыщъх, Вы писали:

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

Отлично.

М>только смысла в этом нету.

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

М>"компилируется != работает".

Кто бы мог подумать?

М>а если еще ваш модуль используется в over 9000 мест другими разработчиками, часть из которых юзает его как библиотеку, часть -- пишет враппер и вызывает из руби, часть -- вызывает из java, часть вообще его отбранчила и теперь мержит все ваши изменения самостоятельно.

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

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

Это обычный процесс разработки, ничего особенного.

М>начитались "умных" книжек и решили, что рефракторинг -- это хорошо, а это на самом деле очень плохо.

Таки, да — хорошо, но разумно.

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

MTD>Здравствуйте, мыщъх, Вы писали:

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


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

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

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

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


М>>а если еще ваш модуль используется в over 9000 мест другими разработчиками, часть из которых юзает его как библиотеку, часть -- пишет враппер и вызывает из руби, часть -- вызывает из java, часть вообще его отбранчила и теперь мержит все ваши изменения самостоятельно.

MTD>Это уже лирика. У каждой команды свой компонент, связи между компонентами задокументированы, все покрыто тестами. Другой команде в чужом коде делать нечего, пусть свой код бранчат.

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

М>>начитались "умных" книжек и решили, что рефракторинг -- это хорошо, а это на самом деле очень плохо.
MTD>Таки, да — хорошо, но разумно.
вот именно -- разумно. бездумный рефракторинг ради рефракторинга только вредит. и если что-то поломалось, то это аццкий труд искать лыжи в темной комнате. про бранчи я уже упоминал. изменения нужно мержить и чем дальше удаляется бранч от оригинала тем сложнее перетаскивать канат через игольное ушко, особенно если эти изменения носят стихийный характер с глобальной перестройкой структуры кода.

Здравствуйте, мыщъх, Вы писали:

М>только "официальная" билд система пишется отдельными людьми.

Всегда так было, в чем проблема?

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

Организационные проблемы

MTD>> Есть. Отдельные компоненты взаимодействуют между собой по документированным протоколам,
М>не факт.

Организационные проблемы

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

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

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

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

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

Да ладно — не все так страшно.

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

Это нормально, какие проблемы?

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

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

MTD>Здравствуйте, мыщъх, Вы писали:

М>>только "официальная" билд система пишется отдельными людьми.
MTD>Всегда так было, в чем проблема?
проблема в том, когда к вам приходит студент, который уже что-то написал и который совсем неглупый, а очень даже талантливый, но в институтах этому не учат, а типичная программа (смотрим мелкий опенсорс) собирается вручую. даже если это не мелкий опенсорс. взять, например, cuckoo -- инструкция по инсталляции напоминает книгу войну и мир, причем инструкция страшно косячная.

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

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

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

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


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

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

Здравствуйте, мыщъх, Вы писали:

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

По моему опыту, толковый студент, после непродолжительного объяснения, схватывает что к чему. Ничего сложного нет — make, посмотрели чего не хватает, собрали/дописали, повторили до победного (это если сборка не сломана, но мы же про этот случай).

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

Это проблема и как раз организационная. Что делать варианта три (чем дальше, тем хуже):
1. Решать проблему организационную — ставить ответственных за код, заставлять их учитывать пожелания
2. Слать патчи
3. Делать обвязку над уже имеющимся кодом, расширяющую его возможности
4. Бранчить и вести свою ветку

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

Да, есть спрос, правда в Москве небольшой, сильно меньше например спроса на яву.

М>ЗЫ. вы все-таки идеалист.

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

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

IO>Всё бы ничего, работа нравится и начальник добрый, но вот зарплата 35000р меня не очень устраивает.

Есть готовность программировать микроконтроллеры (программирование на C, без ОС, либо со специализированной ОС)? Базовые познания в электронике (как работает транзистор)? Умеете
программировать на C, знаете как работает libc и т.п. --> присылайте резюме: job@prosc.ru

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

MTD>Здравствуйте, мыщъх, Вы писали:

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

MTD> Ничего сложного нет — make, посмотрели чего не хватает,
да, и вообще что сложного в программировании? посмотрели чего не хватает...

MTD> собрали/дописали, повторили до победного
MTD> (это если сборка не сломана, но мы же про этот случай).
огромное кол-во людей не в состоянии откомпилировать си-файл, потому что создают си++ проект в студии. огромное кол-во людей даже не догадываются переключить студию в релиз. и еще большее кол-во людей не знают что такое компилятор, линкер, библиотекарь и если они пишут библиотеку, то помещают все функции в один файл, надеясь, что линкер оснащен AI и выдерет их оттуда самостоятельно. а сколько людей знают почему байтовые символы лучше хранить в char, а возвращать в int, а для индексов есть size_t?


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

MTD>Это проблема и как раз организационная. Что делать варианта три (чем дальше, тем хуже):
MTD>1. Решать проблему организационную — ставить ответственных за код, заставлять их учитывать пожелания
поймите же вы наконец, что взаимодействие между отделами не может быть строиться по схеме "нам нужно -- вы делайте", т.к. руководитель чужого отдела не обязан (да и не должен) удовлетворять чужие потребности за счет своих ресурсов. такое возможно только в очень маленьких компаниях, которые по сути и есть один отдел с одним бюджетом и единым ресурсом. с ростом компании возникает неизбежное разделение и потому в ответ на запрос "нам нужно" последует ответ "а что нам за это будет?" и это в идеальном случае. на практике скорее всего скажут, что у нас составлен план на год вперед и все. и менять его никто не будет, т.к. он уже утвержден. если план постоянно менять, то будет бардак. а если переписывать уже написанный код, это нерациональное использование ресурсов и потому единственным приемлимым решением, устаривающим обе стороны является -- вот вам код, делайте свой бранч, а мы со своей стороны сделаем все возможное, чтобы облегчить и вашу, и нашу жизнь, т.к. в вашем бранче могут оказаться фичи полезные для нас и мердж будет двухсторонним.

MTD>2. Слать патчи
куда слать? вы что? система контроля версий.

MTD>3. Делать обвязку над уже имеющимся кодом, расширяющую его возможности
зачастую это невозможно без вмешательства в код. рассмотрим такой пример. web-сервис распознает фотографии, которые возможно содеражат скрытую инфу и возвращает инфу в xml в виде "имя файла", "результат". допустим, он так же поддерживает архивы. допустим, вы итегрируете его в свою систему, где имя файла это курам на смех и вам нужно хотя бы md5. но жопа в том, что вы не поддерживаете архивы, а потому не можете... эээ... посчитать md5 файла из архива. что делать? бранчить. и добавлять к xml еще и md5 и ссылку на головной объект, который может быть архив в архиве в архиве.

М>>ЗЫ. вы все-таки идеалист.
MTD>Нет, я знаю, что бардак есть везде, но стараюсь с ним бороться, так как парадокс разбитого окна присутствует.
кстати о парадоксе. рефракторинг, создавая порядок в одном месте, создает бардак в другом (в системе контроля версий). даже если забыть про бранчи и рассмотреть ситуации когда в версии 2.3.4 это работало, а в версии 6.7.8 -- сломалось, но когда именно сломалось никто не знает. согласитесь, что любые грандиозные перестройки и расчистки кода затрудняют расследование.

Здравствуйте, мыщъх, Вы писали:

М>у нас открыты вакансии на си. почему на си, а не на си++ -- объяснять долго. если есть интерес и желание мигрировать в штаты -- то можно обсудить детали.

Что за вакансии?
По какой визе ввозите народ?

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

T>Здравствуйте, мыщъх, Вы писали:

М>>у нас открыты вакансии на си. почему на си, а не на си++ -- объяснять долго. если есть интерес и желание мигрировать в штаты -- то можно обсудить детали.
T>Что за вакансии? По какой визе ввозите народ?
вакансии -- сетевой софт под никсы на си. визы -- весь доступный спектр. конечно, предпочтение отдается аборигенам, но учитывая уровень российских программистов, решение может быть вынесено в пользу российского программиста, особенно если он старой школы и крепкой закалки. поскольу, кадровыми вопросами я не занимаюсь, то ассортимент моих услуг сводится к пересылке вашего cv моему непосредственному руководству. не слишком большая помощь, но ТС задал вопрос очень в тему. нам как раз нужны "программисты C под встраиваемые системы, UNIX", но ТС не рассматривает выездной вариант, автоматически закрывая вопрос, хотя вакансии все еще открыты... и по этой причине, вот по этой причине, нормальные люди съе... еще в обед, чтобы серфить по волнам до понедельника. меня звали. сказали, что дочь расстроится отказу. а мне что делать? а мне работать все выходные, хотя предложение о серфинге поступило непосредственно от руководства, типа мне нужен отдых. какой там отдых... я ту ночь не спал и эту не посплю. так что я очень даже заинтересован в новых людях, главное, чтобы они хорошими были, а то мне уже объяснили в этой ветке, что неправильно когда бранчат мой код без моего ведома. "правильно" по ихнему это когда по доброте душевной я выполняю все их фич реквесты, наплевав на текущие задачи. с такими я в разведку бы не пошел.

Здравствуйте, мыщъх, Вы писали:

М>огромное кол-во людей не в состоянии откомпилировать си-файл, потому что создают си++ проект в студии.
Ты про какую студию говоришь?

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

Т>Здравствуйте, мыщъх, Вы писали:

М>>огромное кол-во людей не в состоянии откомпилировать си-файл, потому что создают си++ проект в студии.
Т>Ты про какую студию говоришь?
про ms. уже привык, что когда посылаешь людям си файл, то получаешь ответ: не работает. и даже не спрашивашь их что именно у них не работает, т.к. знаешь это заранее. создали новый си++ проект и скопипастили туда си программу. на фига они это сделали? а потому что по другому они не умеют. говоришь им cl file_name.c -- все равно не работает, т.к. переменные окружения не установлены.

Относительно скоро буду менять работу. Куда резюме слать?

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

KP>Относительно скоро буду менять работу. Куда резюме слать?
Обязательно укажи что можешь собрать C- файл мыщьха .

Здравствуйте, мыщъх, Вы писали:

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

Файл с расширением .С по умолчанию компилится как сишный, если явно не указано иначе в настройках.

М>создали новый си++ проект и скопипастили туда си программу.

Чтоб создать проект, в котором с файлы будут собираться как С++шные надо поковыряться ручками после создания проекта.
Если создать новый проект в MSVC и добавить в него .c файлы как есть, не меняя расширения — всё будет прекрасно.

Но судя по описанию тебе попались редкостные идиоты, которые создавали в студии новый файл (который если не указать расширение явно будет иметь расширение .cpp, и компилиться соответственно) и копировали туда текст из твоего файла.
В общем то на этом этапе уже становится всё ясно, кнопку билда можно и не нажимать.

Здравствуйте, мыщъх, Вы писали:

М>а сколько людей знают почему байтовые символы лучше хранить в char, а возвращать в int
байтовые символы всё таки лучше хранить в unsigned char

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

KP>Относительно скоро буду менять работу. Куда резюме слать?
шлите на английском на gleet#novabsdm^com, с пометкой, что от питона, а я перешлю руководству, что человека знаю по форуму и знаю, что он неглупый. если будете в наших краях (NOVA), то с удовольствем приглашаю на чай.

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

Т>Здравствуйте, мыщъх, Вы писали:

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

М>>создали новый си++ проект и скопипастили туда си программу.
Т>Чтоб создать проект, в котором с файлы будут собираться как С++шные надо поковыряться ручками после создания проекта.
смотря как добавлять файл.

Т>Если создать новый проект в MSVC и добавить в него .c файлы как есть, не меняя расширения — всё будет прекрасно.
это мне объяснять не надо. это надо объяснять тем, кто имея make файл не знает, что с ним делать. я редко запускаю студию, но насколько помню, она позволяет открывать make файлы, написанные под нее.

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

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

Т>Здравствуйте, мыщъх, Вы писали:

М>>а сколько людей знают почему байтовые символы лучше хранить в char, а возвращать в int
Т>байтовые символы всё таки лучше хранить в unsigned char
к _хранению_ это не имеет никакого отношения. а вот обрабатывать их принято в int. во всяком случае стандартные сишные библиотеки поступают именно так. взять тот же fgetc(). он же возвращает char, но в int'е. ну или getchar().

если вы будете хранить в char, который может быть signed, то strcpy работать не перестанет даже если символы вылезут за первую половину таблицы. а обрабатывать в int'е их удобнее потому хотя бы потому что это быстрее, да и появляется возможность вернуть -1 как ошибку.

Ушло. Если не получил — дай знать.

P.S. NOVA — это где?