>> |
№81050
15226038447710.jpg
(36Кб, 640x640)
Показана уменьшенная копия, оригинал по клику.
>>81036 > Лишним, думаю, не будет. Рассказ на примере относительно мелкого проекта, без надобности обслуживать его десятилетиями и глубоко влезать в чужеродные потроха. Это применимо к запилу мобильного приложения, какого-нибудь софта для рабочего места кассира, сайта какого-нибудь ведомства (жадные и мелкие, или требовательные к нагрузке и безопасности, вроде банков и соцсетей сюда не входят), создание прошивок для трекеров общественного транспорта или автономных метеостанций и тому подобное. На самом деле, "товарные" задачи на сторону отдаются редко, ведь исполнитель может сам начать полученными девайсами или приложениями торговать, намного чаще это именно приложения для какой-нибудь службы такси или допил каких-то глубоко специфических штуковин, применяемых где-то в потрохах банков или соцсетей. Будешь смеяться, но транснациональные корпорации тоже любят криптозашквариваться и конфосгнивать, и не редкость заказы мессенджеров только для своих. Идиотизм, но кому-то хлеб с маслом. В приличных местах есть разделение труда, в неприличных могут быть совмещения, у фрилансеров все описанное часто должен тащить один человек. Начинается все с того, что продажники находят клиента и впаривают ему решение его проблем. Дальше по-хорошему составляется ТЗ, четко расписывается, за что отвечает исполнитель, тимлид который будет рулить исполняющей командой разбивает задачу на подзадачи и оценивает, что сколько человеко-часов займет. По-плохому, сроки и ответственность размыты и допиливаются в процессе. Как правило, заказчик долго тупит, иногда сравнивает где лучше условия, может месяцами динамить, а потом внезапно согласиться и внезапно поставить срок в пару месяцев, чаще полгода-год. Как правило, дольше года не длится, в таком случае проект дробят на более мелкие, и по возможности ищут разные параллельно работающие команды. После старта, достается прошлый проект, который наиболее похож на текущий, и задачи переформулируются в виде, как его надо доработать. Если повезет, нужно всего лишь проверить работоспособность имеющейся фичи, но везет редко. Тем не менее, все равно 99,9% работы уже берется ранее готовой, в остальном, задача все это дело связать в кучу под новые задачи. Каждый качает себе репозиторий с проектом на свой компьютер, собирает в прошлом варианте до работоспособного варианта. Убедившись, что ничего не сломано, копают свою часть кода, ищут что нужно поменять, гуглят, как те или иные компоненты вообще работают (обычно задачи очень разные, и на конкретные вопросы зачастую никто в команде ответа не знает, это нормально). Если повезет, решение находится за считанные часы, не повезет - уйдут недели, но чаще всего оно находится быстро, но работает не до конца правильно. Делаются правки, пересобирается все, тестируется, работать как надо. В случае мобильного приложения придется его каждый раз заливать на телефон, в случае прошивки для плат - возиться с программаторами и иногда тестером и осциллографом, и так далее. Где-то в устной форме, где-то письменно в багтрекере, где-то в общей конфе, где-то ежедневно, где-то еженедельно, нужно отчитываться о проделанной работе и состоянии дел. Обычно описывают все более-менее честно, лично мне не в напряг все писать, но других почему-то сильно напрягает объяснять свою работу. После того как фича получилась, код причесывается под местные требования и увы, они везде разные, часто отличаются в пределах одного и того же проекта в разных кусках, убираются лишние конструкции, пробелы на концах строк и тому подобное, а так же пишется своии словами описание, что сделано, как оно должно работать, как пошагово проверить что оно действительно работает, и какие подводные камни. Дальше делается проверка, не изменилась ли главная ветка в проекте, не внесены ли в ней за это время изменения. Если внесены - качаешь их себе, если повезет, это в одну команду делается. Если не повезет, и кто-то правил тот же кусок кода что и ты - руками разруливаешь конфликт, стараясь и свою функциональность не сломать, и чужие изменения не затронуть, тестируешь повторно все. После этого, формируется патч с твоими изменениями и комментариями, что собственно было сделано, и отправляется на оценку остальным. В случае претензий (обычно в логику работы вникают редко, придираются к визуальному оформлению или тонкостям языка) переделывается, пока не одобрят. Дальше кто-то другой из команды или специально обученный тестировщик берет твой патч, накладывает, собирает все с нуля, и смотрит, работает ли оно как заявлено. Если все совсем по уму делается, сайт/приложение/девайс прогоняется через автоматические тесты, чтобы отловить ситуации как недавно всплывал грузящий целое ядро процессора мигающий курсор после запила новой фичи. Если патч проходит и это без проблем, он вливается в основную ветку тимлидом, и переходишь к новой задаче. Весь этот цикл проходится в среднем за пару недель. Увы, на более-менее отлаженный конвейер могут накладываться форс-мажоры: заказчик может менять хотелки, другая команда, которая должна что-то предоставить не предоставляет, тимлид в командировке с продажником впаривает что-то клиенту, и распределять задачи и вносить изменения в основную ветку приходится кому придется, отвлекают на проведение собеседований и тому подобное. В редких случаях, заказчик хочет взять за жабры тимлида или испполнителя чего-то критичческого, или наоборот, приходится выбивать право взять за жабры кого-то из поставщиков сторонних компонентов с вопросами, почему не работает как заявлено. Однако имея возможность сравнить с наукой и преподаванием, тут посторонних задач все же не в пример выше. А если быть тестировщиком, нет нужды и особо напрягаться по части поиска проблем, правда, осваивать новый инструментарий все равно придется, ну и обычно на них сваливается больше задач, требующих общения с клиентами. Мда, коротко не получилось, как-то так. >>81047 http://rozen-maiden.ucoz.ru/
|