15 октября, понедельник 20:51
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

Собственные разработки - организация работы

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Собственные разработки - организация работы

    В этой теме я не предлагаю обсуждать полезность/вредность самописного ПО в банках. Я прошу совета, основанного в первую очередь на личном опыте, - как правильно организовтаь эту работу. Рада буду ссылкам на полезные статьи.

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

    Данные проблемы при саппорте и доработке фирменного ПО решались:
    1. внедрением cvs
    2. наличием ТЗ и задокументированным решением
    3. очень помагало, что все работали над одним и тем же ПО, т.е. знали функционал досконально
    Чем больше связей, тем меньше степеней свободы.

  • #2
    Ну индивидуальная манера - это нормально, человек не винтик, тут просто грех сокрушаться. Хотя коль скоро работа идет в команде, то нужно разработать и соблюдать некие общие принципы, например, по названию переменных, программных блоков и т.п.
    Постарайтесь обязательно добиться максимального комментирования кода, чтобы комментировалось не только название процедуры, а все переменные, желательно каждый цикл, каждое ветвление.
    И вы сами правильно пишите про ТЗ и документирование решения. Сделано - описано. Внесено изменение - немедленно записано что и зачем сделано. Соблюдать беспощадно, вплоть до штрафа и увольнения. Иначе будете заложником автора.
    Jeca

    Комментарий


    • #3
      Чернушка
      Выделить отдельного чела на интерфейсы! И обязать всех пользоваться едиными библиотеками интерфейсов. А то какждый в свою сторону натанцует.

      Комментарий


      • #4
        каждый из программистов пишет свой код в своей индивидуальной манере
        А как им еще писать - человек существо индивидуальное. Теже циклические процедуры или работу с массивами можно реализовать абсолютно разными способами.

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

        нет взаимозаменяемости

        взаимозаменяемость это как - встали, поменялись местами и продолжили программировать

        нет совместной работы

        программист отвечает за свой кусок кода. За систему в целом (или подсистему)- руководитель проекта (подсистемы). Задача руководителя - согласовать интерфейсы, графики работ, технологии и т.д.

        Комментарий


        • #5
          индивидуальная манера - это нормально, человек не винтик, тут просто грех сокрушаться. Хотя коль скоро работа идет в команде, то нужно разработать и соблюдать некие общие принципы
          Да, именно. И я про это. Вопрос - какие общие принципы? Пока получается:
          - название переменных и прочих сущностей
          - интерфейсы
          - единые библиотеки, при чем, как я полагаю, не только интерфейсов, но и используемых функций. Иначе получится, что одну и ту же функцию каждый разработает для себя сам. Зачем приумножать сущности?

          взаимозаменяемость это как - встали, поменялись местами и продолжили программировать
          Нет, это когда одни заболел, а процесс не встал на пару недель, поскольку другой не может, не знает и т.д.

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

          Собственно, в этом и заключался вопрос - как адаптировать бест практис к небольшому сектору разработки из 2-4 человек.
          Чем больше связей, тем меньше степеней свободы.

          Комментарий


          • #6
            2 Чернушка:
            "...ох, нелегкая это работа
            из болота тащить бегемота..."
            (с)Корней Чуковский

            Такого рода разработки маленькими творческими коллективами всегда порождают несколько стандартных проблем:
            1. Связи. Было в свое время, еще в ГОСТе, такое понятие как "соглашение о связях". То есть каждый пишущий функцию должен четко и подробно задокументировать все входные и выходные параметры (а также побочные эффекты, коли такие нашлись).
            В небольшой группе аналогом соглашения о связях может служить блок-схема проекта, где на уровне блоков описаня эти самые входные и выходные параметры. Но... Схему нужно не только разработать, а постоянно актуализировать...
            2. Общие библиотеки. Ну правда, зачем 100 раз писать одну и ту же функцию. Но, опять та же проблема: кто-то должен поддерживать саму библиотеку и ее описание.
            3. Заменяемость. А вот тут проблема несколько больше. Если заменяемость делать засчет знаний работы коллеги, то возрастает нагрузка, а значит и фонд оплаты труда (ФОТ). А если иметь дублера, то растет штат, и как следствие, растет ФОТ.
            4. Тестирование. Доверить тестирование пользователям нежелательно. Они найдут не только ошибки, но и неописанные фичи... Держать своего тестера - накладно.
            5. Документирование. Те же проблемы, что и тестировании.
            6. Развитие проекта. Каждый проект (программерский) должен развиваться. То есть не только исправляться ошибки, а вводиться новый функционал и т.д. Для этого нужно вести проект, писать ТЗ, разбираться с предметной областью...

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

            Комментарий


            • #7
              Резюме: самописки хороши только для очень маленьких задач, где есть четкая постановка задачи, где четко видны границы проекта и предметная область не требует узкоспециальных знаний.
              Я же в первом сообщение просила не распыляться н тему хороши/плохи

              Тестирование и документирование (функционала) у меня возложено на саппорт. ТЗ - обязанность технологов. Как сухой осадок из вашего сообщения к

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

              Комментарий


              • #8
                Для Чернушка

                Хочется дополнить примерным и общим описанием софта, используемого по ходу разработки и сопровождения увесистого проекта и прочих сопутствующих работ небольшим коллективом:
                - приложение ведения текущих задач и проблем на основе доработанной под себя bug-ticket системы (можно, например, взять бесплатный и с исходниками zentrack, или keystone, или что-либо другое);
                - приложение учета исходных кодов и групповой работы с ними (VSS+своя среда разработки, или PVCS+среда разработки, или самописка);
                - приложение учета исправлений в разрезе сопровождаемых систем (когда, у какого продукта и что изменили) (как правило - самописка, желательна интеграция с продуктом или отдельно в каждом продукте интегрированный учет изменений).
                На эти приложения навешаны всякие самописные красивости: роботы регистрации проблем, роботы сборки изменений и пр.

                Интересно, что еще можно сюда добавить.

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

                Насчет литературы - вы имеете в виду что-нибудь вроде:
                Марри Кантор "Управление программными проектами. Практическое руководство по разработке успешного программного обеспечения", 2002г.
                Салливан Э. "Время - деньги. Создание команды разрабтчиков программного обеспечения", 2002г.
                Глюкоправ

                Комментарий


                • #9
                  Чернушка
                  Вот еще хорошая книжка про совместную работу: Ф. Брукс "Мифический человеко-месяц или как создаются программные системы", пусть она и про большой проект, но рецепт можно найти и там.

                  Комментарий


                  • #10
                    - единые приемы для решения сходных ситуаций - путь к взаимозаменяемгсти. Эти приемы нужно обсуждать.
                    - простой код. Каждая программная единица должна быть короткой и очевидной. Сложность должна быть поднята на уровень общей архитектуры, то есть решена ДО ТОГО как программист возьмется за дело. Чтобы уже не смог ничего испортить
                    - комментированность кода в разумных объемах. Не много, не мало, ровно столько сколько надо чтоб понять. За комментарий к оператору goto M в виде "переход на метку M" - сразу уволнять

                    Комментарий


                    • #11
                      Чернушка
                      Для начала следует озадачиться азами Той же венгерской нотацией (не сказать, чтобы я сам ее строго придерживаюсь, правда )

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

                      Проработанное ТЗ, документация - это азы

                      st@p
                      единые приемы для решения сходных ситуаций - путь к взаимозаменяемгсти. Эти приемы нужно обсуждать.
                      Именно так, нужно обсуждать Разговор про 'вот ты перепиши ка-давай, мы этим не пользуемся, хоть и работает у тебя в 2 раза быстрее ', не приемлем
                      Это все-таки проблема к вопросу общих библиотек Туда же стандартные заготовки под интерфейсы
                      Которые (библиотеки) могут гибко переписываться. ООП-то к чему придумывалось

                      Хранение кода - само-собой

                      Создание службы по учету разработанного (а лучше и внедренного ПО) Как ФАП в Сбере

                      Комментарий


                      • #12
                        Опыт работы в софтверной компании:
                        1. Манера может быть своя, но обязательно должен просматриваться единый стиль (именование переменных, процедур и функций). Каждая глобальная переменная/процедура должна быть комментирована её назначением. Запрещены наименования короче 5 символов, непонятные а так же матерные.
                        2. Каждая процедура/функция должна предваряться комментарием с описанием того, что она делает, указанием параметров вызова и возвращаемых результатов. Наличие комментариев внутри процедур желательно но является необходимой (при правильном именовании переменных и процедур код часто является самодокументированным, особенно на ООП языках ).
                        3. Главное форма (основная программа) должна быть фактически оболочкой для вызова процедур (подпрограмм/модулей).
                        4. В программе должны обязательно вестись логи, как минимум отладочный лог в который выводятся основные вызовы и параметры при запуске в режиме отладки, и ErrorLog, в который выводятся все ошибки.
                        5. Про интерфейсы уже писали...

                        В банках удавалось внедрять/контролировать в лучшем случае пункты 4 и 5.
                        Выводы, как в детском конструкторе - сделайте сами.

                        По литературе внесу свои пять копеек:
                        Одна из самых, на мой взгляд, фундоментальных книг - Иан Соммервилл «Инженерия программного обеспечения».

                        Очень не плоха, (опять же, ИМХО ) свеженькая - Дж. Ханк Рейнвотер «Как пасти котов. Наставление для программистов руководящих другими программистами.»

                        Про заведомо безнадежные проекты (та же не к ночи помянутая отчетность ) понравилась - Эдвард Гордон «Путь камикадзе»

                        На тему организации совместной работы еще можно поискать "Салливан Э. Создание команды разработчиков программного обеспечения.pdf" - гуглите.

                        Саппорт фирменного ПО в 99% случаев сводится к подтиранию соплей юзеров, если внедрение было проведено с тщательным тестированием функционала.

                        Комментарий


                        • #13
                          Сообщение от st@p Посмотреть сообщение
                          ...
                          За комментарий к оператору goto M в виде "переход на метку M" - сразу уволнять
                          Достаточно факта наличия goto

                          Комментарий


                          • #14
                            vsv, стесняюсь спросить, а что такое Венгерская нотация?

                            Проработанное ТЗ, документация - это понятно. Но что вы понимаете под документацией? Сначала ТЗ, потом ПО, потом или одновременно с ПО документация. Или это документирование кода?
                            Чем больше связей, тем меньше степеней свободы.

                            Комментарий


                            • #15
                              Чернушка а что такое Венгерская нотация?
                              Венгерская нотация — соглашение программистов об именовании переменных, констант и прочих идентификаторов в коде программ. Свое название венгерская нотация получила благодаря программисту компании Майкрософт венгерского происхождения Чарльзу Шимоньи (венг. Károly Simonyi), предложившего её ещё во времена разработки первых версий MS-DOS. Со временем, его система стала не только внутренним стандартом Майкрософт, но и широко распространённым правилом среди программистов всего мира.
                              http://ru.wikipedia.org/wiki/%D0%92%...86%D0%B8%D1%8F

                              очень полезно бывает иногда программистам дорабатывать задачки написаные др программерами, т е ротация достаточно бывает даж одного раза , именно тогда понимаешь важность комментариев в коде описания общих библиотек и тп
                              Дважды досчитал до бесконечности (с)

                              Комментарий


                              • #16
                                Достаточно факта наличия goto

                                Недостаточно.

                                GOTO ведущие строго вниз, например, многократные "goto ERROR" при обработке ошибочных ситуаций, гораздо понятнее для восприятия чем головокружительная вложенность if-then-else'ов.

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

                                Так что теория - теорией, а у жизни свои законы.

                                Комментарий


                                • #17
                                  Сообщение от st@p Посмотреть сообщение
                                  Недостаточно.

                                  GOTO ведущие строго вниз, например, многократные "goto ERROR" при обработке ошибочных ситуаций, гораздо понятнее для восприятия чем головокружительная вложенность if-then-else'ов.

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

                                  Так что теория - теорией, а у жизни свои законы.
                                  В первых, в посте смайл стоит.
                                  Во вторых, зависит от языка программирования. Например, в Delphi
                                  if условие then goto Error_Lab else goto OK_Lab резко повышает шанс программеру получить goto discharge Тогда как в *.bat или T-SQL это чуть ли не единственный способ ветвления.

                                  Однако в банках главный вопрос - КТО будет заниматься контролем качества кода? Штатной должности я не встречал...

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

                                  Комментарий


                                  • #18
                                    Чернушка
                                    Но что вы понимаете под документацией? Сначала ТЗ, потом ПО, потом или одновременно с ПО документация. Или это документирование кода?
                                    Под документацией я понимаю документацию К документированию кода это не имеет отношения Точнее, документирование кода - как одно из составляющих

                                    Т.е. во-первых - техническая документация Начиная с постановки задачи, далее ТЗ, далее описание идеологии решения etc. Ясно, что тут возможны разные варианты, но в принципе описание откуда это взялось, зачем, и каким образом иметь необходимо
                                    Во-вторых, документация для сопровожденцев Ну т.е. как ее ставить и т.д. 'Руководство администратора', в общем
                                    Во-третьих, пользовательская документация

                                    Ну это все в идеале, конечно

                                    Комментарий


                                    • #19
                                      Ну, про эту документацию все понятно. Сопровожденцы уже давно заряжены
                                      Чем больше связей, тем меньше степеней свободы.

                                      Комментарий


                                      • #20
                                        st@p ну не знаю, у нас с университета преподавателями в т.ч. деканом вдалбливалось, что использование goto - огромное западло. Нет ниодной задачи в функциональном программировании, тем более в ООП, которую можно (и нужно) реализовать без него.
                                        А в Вашем примере проще всего использоваться иключительные ситуации.

                                        P.S. Хотя внутри там же все на jump-ах . Парадокс-с
                                        Жить надо так, чтоб тебя помнили сволочи!

                                        Комментарий


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

                                          Комментарий


                                          • #22
                                            st@p От уже сколько лет работаю профессионально, ни одного не написал )))) кроме как в батниках, каюсь
                                            Жить надо так, чтоб тебя помнили сволочи!

                                            Комментарий


                                            • #23
                                              Мы начинаем с Requirements Gathering, т.е. со сбора требований. Дальше прототипируем и работает над создание GUI в спец программах. Потом уже переходим к разработке.

                                              Применяем итеративный подход, как в RUP описано.
                                              Everything comes to him, who waits.

                                              Комментарий

                                              Пользователи, просматривающие эту тему

                                              Свернуть

                                              Присутствует 1. Участников: 0, гостей: 1.

                                              Обработка...
                                              X