Программирование: Практики которые я возьму с собой

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

    В основном описаны моменты которые касаются поддержки процесса разработки программного обеспечения, не затрагиваются темы планирования хода выполнения работ. Также не затронут процесс программирования и полезные плюшки для него (например расслоение системы на уровни, использование шаблонов проектирования). Но все ниже приведенное было и остается полезным для меня лично, и я буду рад если и вам на что нибудь сгодится :)
    • В конце рабочего дня подведение краткого итога, и письменный ответ на три вопроса: что было сделано, какие проблемы возникли, что планируется сделать. Также неплохо предоставить данную информацию всей команде (электронная почта, внутренний блог), и если у них будет интерес, то они могут прочитать данный отчет. Полезность данной практики неоценима, каждый кто составляет отчет задумывается в конце дня над вопросом: а что он сегодня полезного сделал. И ради ответа на данный вопрос уже стоит использовать данную практику. Кстати, некоторые заметят что данная практика присутствует в Scrum методологии. Но я первый раз увидел ее на Иркутском Авиационном заводе, мне о ней рассказал один очень интересный человек.
    • Все материалы по проекту должны быть сосредоточенны в одном месте. Например, ссылки на логи общения с заказчиком или URL, для репозиториев исходного кода. Порядок никогда не бывает лишним, а порой очень сильно способствует повышению производительности.
    • Надо управлять требованиями заказчика. Что понимается под таким общим утверждением? Все просто, все запросы на изменения вносимые в проект от заказчика должны быть зафиксированны в электронном виде. В тяжелых случаях заказчик должен ставить подпись под каждым своим требованием. Да это бюрократия, да интереснее писать код, но без этого ваш проект имеет очень высокую вероятность провала. Хотя тут многое зависит от.
    • После получения задания от заказчика надо ему объяснить своими словами что он хочет. Данная вещь очень важна, без нее очень часто реализовываются вещи которые хочет разработчик, а не заказчик. Хоть это и звучит дико, но тут надо очень аккуратно согласовывать требования, ведь разработчик тоже не дурак и понимает к чему приведет реализация странных требований.
    • Повесить на общее обозрение диаграмму описывающую архитектурные особеннности проекта. В идеале рядом с ней повесить диаграмму с ходом движения работ по проекту. Это позволит поднять уровень коммуникации между членами команды на принципиально иной уровень. Главное не забывать тыкать пальцем в элементы диаграмм при обсуждении проекта. И не забывайте рисовать на доске ваши мысли для общего обсуждения :)
    • Исходный код проекта должен хранится в системе контроля версий. Порядок никогда не бывает лишним. Особенно это важно когда код пишет более одного человека, хотя я уже не представляю себе как можно писать код без системы контроля версий. Наверное у меня комплекс :)
    • Должна быть инструкция для настройки рабочего окружения по работе над проектом. Если данного документа нет, то получается истинный хаос при подключении нового человека в проект. Да и передача дел значительно затрудняется. Вики по проекту это идеальный вариант.
    • Использование системы управления задачами. Наличие данной системы позволит более продуктивно исправлять различные проблеммы и не забывать про них. Не забывать это хорошо.
    • Наличие описания сборки проекта. Если каждый раз сборка проекта это череда магических пасов, и собрать проект может только единственный гуру в команде, то это бардак. Если будет описание процеса сборки приложения хотя бы в текстовом виде, то это значительно упростит работу работу всех членов команды, и избавит от ряда глупых вопросов. Идеальный вариант когда процесс сборки приложения автоматизирован (например при помощи Ant или Maven), тогда счастье разработчиков поистине безгранично.
    • Использование системы непрерывной интеграции. Возможно вам это и не надо, но меня очень уж радует факт того, что каждый день происходит сборка системы, и возможно проходят все тесты. Это значительно повышает уверенность в разрабатываемой вами системе.
    • С опаской относится к независящим от вас системам. Интернет ненадежная штука.
    • Быть готовым к изменениям. Не все изменения одинаково полезны, но надо быть готовым принять разумные вещи и использовать их в своих целях. В том числе, надо критически воспринимать данный текст :)

    Надеюсь вы не зря потратили свое время на чтение данного текста, и что то будет вам полезным :) Кстати, черновик этого текста можно найти у меня в блоге :)
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 40

      +3
      скромный опыт. жалких 6 лет программирования. Это ж не опыт даже, тьфу.
      :)
        0
        В любом случае человек поделился с огромным сообществом тем, что ему кажется полезным и правильным. И Вы знаете, я возьму на заметку многие советы, так как они действительно полезны. Раз вам это не нравится, давайте же, поделитесь с нами подобным опытом (вы же этим так давно занимаетесь, намного больше «жалких шести лет»).

        Автор молодец, плюс ему за статью.
          +11
          Просто кто-то забыл табличку «сарказм».
            +2
            ну я примерно это и имел в виду ) у меня опыта намного меньше и человек с 6-летним опытом кажется мне гуру. Поэтому я намекнул автору на излишнюю скромность в начале поста, не более того. пост мне и самому понравился. Загуглите Ч/Ю — офигенная вещь, в жизни всегда пригодится :)
              +2
              Эх, хотел как лучше, а получил минус… ну не заметил я смайл…
                0
                Тоже не сразу понял, что Вы шутите и минусанул. Поправил в карму :)
                  +1
                  Вот так всегда, сначала плюнет, а потом думает )
                    –1
                    Дмитрий Анатольевич?
                    :)
              0
              Программист — это как хорошее вино. При приличных начальных данных лет через 6-8 его можно пить. Хотя, если изначально кислятина — ничего уж не попишешь.
                0
                Ну не все так однозначно. Опыт, конечно, растет, но с возрастом и думать начинаешь медленнее, да и зашориваешься в какой-то мере.
                  +1
                  Масштабнее начинаешь думать :) А внимание к мелочам уже на автомате включается.
                0
                Согласен, ерунда, а не опыт :) Кстати по зарубежным меркам это очень небольшой опыт, у них другие мерки :)
                +3
                мне показалось интересным, вынес кое что для себя
                  +1
                  Готов подписаться под всеми пунктами, но добавлю свой пять копеек
                  — относительно CI: Каждый день должна происходить не только сборка системы и прогон тестов но и автоматическая ее установка на доступный енвайронмент. Процесс деплоймента нужно тестить так же как и другие части системы.
                  — Также по кнопке нужно иметь возможность обновить установку системы на енвайронменте, используемом QA.
                  — Заказчик в любой момент времени должен иметь доступ к промежуточной версии системы. В частности если практикуются демонстрации раз пару недель (что кстати оч повышает результативность коммуникаций с заказчиком) то заказчик должен всегда иметь возможность «потрогать» то что было показано на последней демонстрации (линк если речь о веб, или файл инсталятора).
                    0
                    Не люблю я автоматические штуки. Затраты на их поддержание большие. Разве что кнопка спасет мир, но не всегда. Вот например структура БД изменилась и что? Автоматика иногда дает сбой.

                    Кстати промежуточный сервер полезная штука, особенно если там данные в БД адекватные :)
                      +1
                      Я на своих проектах держу скрипты по созданию БД в отдельном проекте. На каждый объект- скрипт для создания и для удаления (обновления и ролбэка до предыдущего релиза), отдельно скрипты с тестовыми данными плюс скрипты которые это все накатывают. При каждом автодеплойменте вызывается ролбэк потом апдейт. В результате имеем независимый контроль версий объектов бд и готовые деплоймент скрипты в любой момент да к тому же гарантированно рабочие и up to date ибо тестятся ежедневно.
                    +1
                    Все здорово, но не хватает терминов на английском и полезных ссылок (например на системы контроля версий, которые используются автором, на CIS системы, на таск трекинговые системы). Мало про тестирование. Это пожелание, а не укор автору. Полезность текста была бы выше и можно было бы им пользоваться как краткой справкой при таком подходе.
                      0
                      Если будет время процесс разработки нарисую, и ссылки дам :)
                      +1
                      Очень интересно, спасибо!
                      Кстати, С++ программисты, рекомендую почитать книгу «С++ для профессионалов(Professional C++)» Николас А. Солтер, Скотт Дж. Клепер
                      Там есть и про практику правильного развития проекта.
                        +11
                        статья интересная, спасибо!
                        а вот название показалось мрачноватым, в конце напрашивались слова "… в могилу" :-))
                          0
                          :)))) Точно

                          А по поводу скрам… Ну в скрам — это 5минутка, которая проводится утром перед самой работой. Какое настроение вы добиваетесь вечером? Чтобы не заснуть если сроки поджимают?
                            +1
                            я просто место работы меня, потому и название такое :)
                              0
                              *меняю
                            +10
                            Есть еще вот такая штука:
                            Тест Джоэла Спольски 12 шагов к лучшему коду

                            1. Пользуетесь ли вы системой контроля версий?
                            2. Можете ли вы собрать продукт за один шаг?
                            3. Выполняете ли вы ежедневные билды?
                            4. Используете ли вы базу данных ошибок?
                            5. Исправляете ли вы ошибки перед написанием нового кода?
                            6. Есть ли у вас актуальный план работ?
                            7. Есть ли у вас спецификация?
                            8. Предоставлены ли вашим программистам спокойные условия для работы?
                            9. Используете ли вы новейшее дорогое оборудование?
                            10. Есть ли у вас тестеры?
                            11. Пишут ли кандидаты на работу код во время собеседования?
                            12. Проводите ли вы коридорное тестирование удобства использования программ?

                            по странному стечению здесь тоже 12 рекомендаций.
                            хотя возможно это моя паранойя

                            кому интересно тут
                              0
                              В конце рабочего дня подведение краткого итога, и письменный ответ на три вопроса: что было сделано, какие проблемы возникли, что планируется сделать
                              Если есть разбивка на микротаски и управление ими, ответ на этот вопрос возникает сам собой

                              Исходный код проекта должен хранится в системе контроля версий и Все материалы по проекту должны быть сосредоточенны в одном месте. очевидно что ВСЁ должно хранится в системе контроля версий.
                                0
                                Должна быть инструкция для настройки рабочего окружения по работе над проектом в идеале должен быть скрипт или инсталяшка которая разворачивает проект для работы
                                  0
                                  Я об этом писал в «Наличие описания сборки проекта.» :)
                                    0
                                    я не про сборку приложения здесь говорю, я про разворачивание рабочего окружения.
                                      0
                                      ок, я немного не понял вашу мысль :) Но если по существу, то стоимость поддержки таких скриптов непонятна (сколько на это времени надобно?).
                                      И не стоит забывать что разработчик должен все сам уметь настраивать, автоматические средства это всего лишь средство, которое надо понимать.
                                        0
                                        выгода от наличия такого скрипта растет от:
                                        1) количеством разработчиков
                                        2) долгожительства проекта.
                                  0
                                  как понять этот механизм контроля версий? и как он выглядит? есть пример?
                                  0
                                  Классно! Наша компания проходит по многим тестам.
                                  Про три вопроса — недавно проводил для Вебинар по управлению временем, как раз про это говорил. Вопросов задаю гораздо больше, но уже на автомате. Анализ — великая весчь, да.
                                    +1
                                    Спасибо за советы, над несколькими пунктами серьезно задумался.
                                    В конце рабочего дня подведение краткого итога, и письменный ответ на три вопроса: что было сделано, какие проблемы возникли, что планируется сделать.

                                    Мы делаем это в начале дня, чтобы состыковывать планы. А подводим итог, соответственно, вчерашней работы.
                                      +2
                                      Не знаю почему, но верю в старую фишку, что подсознание хорошо кушает информацию к вечеру — а еще лучше прямо перед сном. За 15 минут перед сном пишу планчег.

                                      Поэтому можно вечером провести анализ, и, если условия меняются часто — накидать векторы на завтра, а утром уже определиться с деталями. IMHO
                                      +1
                                      Главное не переставать поддерживать порядок в голове и делах. :-)

                                      Это не каждому под силу.
                                        –1
                                        Спасибо за дельную информацию в топике и комментариях, что-то я уже использую, что-то уже хочу внедрить.
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                            –1
                                            А еще я бы добавил code review.
                                              –4
                                              Программист — это ещё слишком мало в отсутствии приличного менеджера (или лицо, испольняющего его обязанности). Ибо программирование не может быть только ради программирования.
                                                +1
                                                немного сумбурно, но я плюсовал от души

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

                                                а вот про 3 вопроса и обратную связь с заказчиком — это действительно разумный lifehack

                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                Самое читаемое