На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
[!] Как относитесь к модерированию на этом форуме? Выскажите свое мнение здесь
Модераторы: Qraizer
  
> Как правильно состыковать несколько программистов , Каждый себя считает умнее другого, в итоге нет желания взаимодействовать.
    Здравствуйте, подскажите пожалуйста, как бы правильно поступить.

    Разрабатывается достаточно крупный проект, даже не достаточно а крупный.

    Язык написания С.

    (я немного знаком с дельфей, но С для меня темный лес)

    Суть такая:
    Есть тимлид, который ведет основную разработку программной части.
    Он все делает с виду круто, по крайней мере мне так кажется, ничего не тормозит не глючит и тд. Все добавляется как надо сам угадывает то как бы это хотелось бы мне заказчику ну и так далее...
    Но есть маленькая проблемка, которая вылезла некоторое время назад. Эдак пару месяцев назад, я не выдержал и потребовал внедрение всех модулей разработанных подчиненными ему программистами в общий проект.
    Мне показывались все модули по отдельности, все с виду работает, но так как остальные модули были не в общем проекте я даже не предполагал что они написаны на С++.
    Когда выяснилось что модули не подходят к главному проекту, было сказано фиг с вами пробелм нет претензий то же, но переделываем все по одному стандарту чистое С, по скольку основная часть на нем, а использовать основную часть как какую то обертку как то бредово. Попререкались, все согласились. Проходит еще пара месяцев, еще 1 программист проделал кучу работы, второй тоже, ну и тимлид соответственно. Тимлид подтвердил, что да со всеми договорился и люди переписали все на чисто Си. и проблем со внедрением нет. Но как коснулось дело внедрения, он начал говорить примерно следующее:
    - Я этот код внедрять не буду, вы готовы на черный ящик в моем качественном коде и тд.
    - Тут все сделано у них криво
    - все отформатированно неправильно
    - все можно было бы оптимизировапть в 100 раз лучше
    - да и вообще тут мне все переделывать
    - и не лезте ко мне я лучше знаю как надо.

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

    Он посмотрел на этот код и выдал примерно следующее.. я не буду разбирать эту пртянку... тут все криво и тд тп тк

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

    А проект дошел до такого размера, что до вменяемого вида, 3 программиста его будут делать ближайшие 5 лет. (то есть один он сделает слишком мало что бы реализовать задумку, а так отрезав то се можно что-то получить пусть корявое неполное но что-то что будет соответствовать конечной цели)

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

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

        Вот я и спрашиваю совета профессионалов... не парят ли мне мозги... и как можно решить эту проблему которая возникла... что можно спросить и на что обратить внимание...

        Цитата

        огород вокруг разнородности проекта


        Я был в шоке когда это узнал. У меня даже мысли такой не возникало что это возможно.
        Сообщение отредактировано: Gen -
          Цитата Qraizer @
          Плюсы с Сями накоротке, проблем с интеграцией никаких быть не должно было.

          я тоже был раньше абсолютно в этом уверен, а теперь выяснилось,
          что это не всегда так.
          .. Оказалось, что в Linux С-программа не может так просто
          прицепить dll (.so-файл), написанной на c++, даже явной загрузкой !

          Добавлено
          Цитата Gen @
          Цитата

          огород вокруг разнородности проекта


          Я был в шоке когда это узнал. У меня даже мысли такой не возникало что это возможно.

          Если поручить отдельным разработчикам оформить свои опусы в dll
          с заранее оговоренным интерфейсом, то всё должно получиться.
          Не зависимо от разнообразия языков, компиляторов и сред
          разработки. Но это не дело, конечно.
          Главному манагеру проекта - пистон. С гвоздями.
          Сообщение отредактировано: ЫукпШ -
            Может вы посоветуйте какие нибудь стандарты написания, форматирования кода, использования памяти и тд...
            вот я нашел что-то на эту тему, но не уверен что это то.

            http://www.opennet.ru/docs/RUS/coding_standard/

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

            Цитата

            dll


            Я этот вопрос поднимал пару раз, я как понял тимлид считает что никаких dll быть не должно (типа проект относится к геймдеву и это будет сильно тормозить)

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


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

            Если тимлид не готов писать документ codestyle и говорит что у всех все плохо, это нормально?
            Если тимлид не готов слушать других, а хочет все делать только сам это нормально?
            Сообщение отредактировано: Gen -
              Цитата
              Я как заказчик прифегиваю

              А вам нужна дружная команда или завершенный работающий проект ?
              Если второе тогда, есть вариант:

              Оплата по факту создания готового протестированного проекта. Договор с одним человеком (исполнителем), а дальше он нанимает столько людей, сколько ему нужно в команду, чтобы уложиться по срокам, он устанавливает правила, ответственность и зарплаты каждому в рамках общего бюджета(больше людей - меньше зар.платы) Вам как заказчику не все ли равно через N месяцев вы получите готовый продукт и за это заплатите X $

              Есть возражения : что мол если работа на 2 года, а получать зар.плату в нашей стране привыкли каждый месяц. Есть выход: Каждому исполнителю открывается кредитная линия в банке. Т.е каждый работает в свой долг. Если наниматель принимает работу - он гасит долг за 2 года за участников. Если не принимает работу - значит исполнители имеют собственные долги.
              Сообщение отредактировано: Маршал -
                Цитата Gen @
                на смарку...
                  SCRUM с хорошим скрам-мастером
                    Темка старая....
                    Этот лидер - не тим лидер...
                    Все правила должны быть озвучены заранее, и проверять надо периодически.
                    Проект должен, имхо, делаться законченными мелкими частями, которые можно протестить.
                    Это как полный ремонт квартиры: придти не в конце всего ремонта, а минимум, после каждой комнаты, чтоб вовремя скорректировать или люлей дать.
                    По поводу форматирования... у меня у самого такой бзик, выбешиваюсь, когда люди в ворде или екселе пишут и оформляют как попало...
                    0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                    0 пользователей:


                    Рейтинг@Mail.ru
                    [ Script execution time: 0,0346 ]   [ 17 queries used ]   [ Generated: 29.03.24, 00:16 GMT ]