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

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

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

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

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

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

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


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

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