1037

Горшочек, не вари!

Был случай на одном проекте.

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

Тестеры поразбирались недельку с системой и начали заводить баги. Штук по 10 в день.

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

Закончилось тем что тестеров отправили обратно на родной проект, менеджеру их проекта объявили что "тут вам не здесь", мол, рано им еще с такими задачами работать.

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

Дубликаты не найдены

+38

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

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

раскрыть ветку 2
+10
Ох, сильно деморализируют такие проекты. У меня как-то три больших проекта подряд было таких, и думаешь и нахрена мне столько платили, если из этого выхлопа ноль.
раскрыть ветку 1
+1

ник у вас замечательный, серьезно. это слово давно крутится в голове, и я не знаю откуда оно взялось :)

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

+73
... ждать следующего эффективного менеджера.
раскрыть ветку 1
+26
Угук.
Иллюстрация к комментарию
+5

в том-то и суть ИТ, что 70% проектов в процессе их изготовления уже оказываются ненужными и хорошему управленцу как и раз и платят дохуя денег именно за то, чтобы он умел отличать нужно от ненужного. Но если проект оказывается нужен, то откупается в разы)))


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


А когда работал в 1С типичной ситуация была, когда завод внедряет SAP, тратит мешки денег, ничего не получается и потом переходит на 1С и все счастливы и стоит все в 10 раз дешевле.

+16

Пам-пам, и это ЕПАМ! фьюить!

раскрыть ветку 15
+10

Такая фигня не только в ЕПАМе. Лет 5 назад работал в компании одной (люди душевные, но платить деньги не любили) в качестве QA на проекте. И багов серьёзных накопилось под сотню. Я начал долбить РМ на тему "хватит пилить фичи, давайте начнём баги править в конце концов", и двухнедельных спринт полностью отдали на фикс. Ну и через две недели счастливый РМ вопрошает:

- Ну, что сколько багов осталось?

- чуть больше 200

- но ведь было 100 всего?

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


Проект так до сих пор и не сдали, на сколько я знаю.

Иллюстрация к комментарию
раскрыть ветку 1
+5

Дааа! Было пару раз что давали никем не тещщщенный проект в надежде что я проверю, скажу что всё ок и закрою задачи... А вместо этого я заводила ещё кучу багов ^_^ Правда в моем случае большинство из них постепенно правились

0
Все чаще натыкаюсь на хейт ЕПАМа, неужели там все так плохо?
раскрыть ветку 12
+10

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

раскрыть ветку 11
+7
Видел однажды как пилили под ТЗ заказчика, начал разбираться, проект явно отличался от запрошенного процентов на 70 всем, кроме основного функционала. Потом уже поели что в рамках этого бюджета еще 3 проект запилили... От такая херня малята
раскрыть ветку 2
-3

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

раскрыть ветку 1
+2
Вы не поняли, в гите клиента жили еще чужие проекты. Разрабы завышали часы и за бабки бигкомпанинейм пилили другим заказчикам.
+18
Иллюстрация к комментарию
раскрыть ветку 3
+31

что непонятного? тестировщики разрушали радостный мирок манагера. Он с ними пытался договориться - не вышло. По итогу, он всех послал на хуй, а сам аннигилировал.

-2
Похоже пикабу превращается в баш. Скоро здесь будет 90% такого юмора
раскрыть ветку 1
+8

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

Была в гостях у подруги (П). Она недавно переехала в съёмную квартиру, отмечали с друзьями новоселье. Нужно было разложить хозяйский стол, чтобы все поместились. Два парня ковырялись, ковырялись, да не выковырялись.
Я: Отойдите, давайте я сделаю. У меня муж инженер, я точно разберусь.
П: А ты думаешь, что это передается половым путём?
Передаётся не передаётся, а стол я разложила.

https://bash.im/quote/454598

+2

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

-10

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

раскрыть ветку 25
+10

Писать код с багами, это нормально. Они не хеллоу ворлд пишут, а сложный продукт, при создании которого баги неизбежны.

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

То что манагер не дал выполнить качественно работу  - это ненормально, за это он поплатился.

раскрыть ветку 20
-3

Я понимаю если происходит нарушение логики работы ПО. Но логические ошибки по 10 багов в день, что то я сомневаюсь. А кодеры код влили, а проверять его типа не надо? Так принято? У меня кодеры постоянно код "забывают" проверить, приходится постоянно тыкать их носом, а потом они истерят, что их отвлекают уже от следующей задачи, чтобы убрать за собой говно. Но у нас по крайней мере, ребят уже это поняли и ошибок меньше.

раскрыть ветку 19
+1
Программисты не допускают ошибок просто так. Сейчас уже не ассемблере пишут и все ошибки, допускаемые по невнимательности, обычно, являются мелкими и некритичными. То, что в посте описано - это отсутствие требований. Тестеры, по сути, нашли не ошибки разработчиков, а пробелы в требованиях. И вот именно в такой ситуации баги сыпятся десятками и менеджер спорит насчет каждой. А программисты что - им на половину вопросов отвечают "забейте".
Без тз - результат хз.
раскрыть ветку 3
0

В посте описано отсутствие требований? Где? Я с тем же успехом могу придумать как у них работа устроена.

раскрыть ветку 2
ещё комментарии
-2

Как-то не смешно
Дядь @stavropol, это под тематику сооба подходит?

раскрыть ветку 3
+1
8. Пожалуйста, не удаляйте пост, который не подходит сообществу, но не нарушает общие правила сайта. С помощью кнопки возле заголовка поста вы можете перенести его в общую ленту. Если без удаления поста все-таки не обойтись, постарайтесь объяснить автору причину.
9. Просим не удалять неудачные / заминусованные посты по просьбе авторов или по своему желанию (например, если пост «разонравился» или «портит статистику сообщества»).
(с) правила Пикабу

Отаки дела, малята

Иллюстрация к комментарию
раскрыть ветку 2
0

А что не так? Я про то, чтобы вынести в общую ленту. Как-никак, это никак не юмор.

раскрыть ветку 1
-6
А как же тесты..по 10 багов в день ? Серьезно ? Из какого пту их выпустили..не подумайте что я это с пафосом..но по 10 багов в день это нужно левой ногой код писать. Да баги в больших проектах это норма, но даже если не использовать ddt методологию как можно ТАК накосячить ? Я думаю в этой ситуации вина в большей степени на 1) Тим лиде (если он вообще был) и 2) на разрабах. Ну и да..код ревью в больших проектах тоже маст хев и выявляет кучу подводных камней ещё на этапе feature ветке..
раскрыть ветку 12
+6
Code review? Тесты? Не смешите. На таких проектах отсутствуют ТРЕБОВАНИЯ. Ни один человек в команде не знает, что нужно разработать и как отличить баг от фичи. И ах если бы я сейчас, блин, утрировал!
раскрыть ветку 1
0
Это уже момент организации, тут согласен, зачастую "эффективному " менеджеру не объяснить важность этих моментов и для него это пустая трата денег
+6

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

В общем, не вижу в этом ничего особенного.

раскрыть ветку 1
+1
Серые будни, ни разу не что-то особенное. Проект без QA обречен.
+2

Как уже верно заметили выше - найти 10 багов за день в системе, которая побольше лендинга, и у которой не было тестировщиков до этого - как нефиг делать. Разработчик ВСЕГДА при проверке смотрит на результат своей работы со стороны программиста, а не со стороны конечного пользователя - и это нормально. В конце концов, если бы разрабы могли одинаково хорошо и писать код, и тестировать, то тестировщиков в принципе не существовало бы.

раскрыть ветку 7
-4
Или 1000 и 1 способ как оправдать дерьмовый код:) программист обязан думать о конечном пользователе..если он не пишет е2е тесты и нужен специальный человек который будет тыкать не кнопочки то..собственно не ошибся ли он профессией ? П.с. давно создание лендинга стало программированием?
раскрыть ветку 6
-6

Тег "Сова - эффективный менеджер" в студию!

-5
И че?
-6

вроде и разрабы пострадали, теперь будут на ИМ еще сидеть, а вроде и сами тоже в чем то виноваты, норм спецы все равно должны как-то контролировать процесс

-5

Ни хрена не понятно...

-8

А перевод на простой обывательский можно?

Или это не переводимо?

раскрыть ветку 11
+8

Представьте себе это цехом по изготовлению тракторных педалей. У них сперва не было никакого отдела технического контроля. Затем взяли сотрудников ОТК из другого цеха, выяснилось, что нужно было не для тракторов, а для маршруток и не педали, а кулисы КПП. Начальник цеха сначала объяснял им, что это такая экзотичная брутальная форма кулисы, но те продолжали настаивать, что такая хрень абсолютно не подходит. И выгнали этих ОТКшников обратно, откуда те пришли, ибо нефиг умничать.


`````````````````````````ТНЕ ЭНД.

раскрыть ветку 10
0

Ты сейчас с кем разговаривал? Кулисы какие-то, театр и т.д.

-6

Так уже понятнее. Спасибо.

А если перенести действие, к примеру... на швейную фабрику...

чтоб и самым ограниченным слоям общества, в лице мну?

раскрыть ветку 8
ещё комментарии
ещё комментарии
Похожие посты
312

Вот это поворот!

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


И тут один игрок раскрыл мне глаза. Далее часть диалога, игрок - И:

И: ну, это напоминает Portal, Talos Principle и Witness

Я: что именно напоминает Portal?

И: нужно решать головоломки ... нужно ходить ... и еще я заметил у вас есть порталы

Я: где порталы? какие порталы?

И: ну вот эти (и показывает)

Я: так это же спец.двери

И: ну какая разница, ты же проходишь через них и куда-то попадаешь...


И тут мне уже нечего было ответить:

Вот это поворот! Игры, Тестирование, Игроки, Разработка, Инди, Gamedev, Реальная история из жизни, Портал, Альфа-Тест
36

Путевой лист Online

Я пару раз писал, про данный сервис. За это время он продолжал развиваться и дорабатываться.

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

Приехал ты на адрес (объект) ставить кондиционер/обслужить домофон/починить интернет и т.п.

Открыл сайт, жмякнул кнопку "добавить точку"

Путевой лист Online Без рейтинга, Тестирование, Сервис, Авто, Разработка

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

Путевой лист Online Без рейтинга, Тестирование, Сервис, Авто, Разработка

Остается нажать "сохранить" и точка уже в базе данных, все расчеты произведены.
Такие действия, выполняются на всех адресах по маршруту следования и к вечеру у вас готовый путевой лист со всеми расчетами.
Можно зайти на сайт с компьютера, скачать путевой лист в формате pdf или xlsx (Excel) и распечатать.
Пост не для рекламы ради, (сервис бесплатный) и не для рейтинга (тег присутствует).

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

Ссылка на сервис https://car-route.ru

Показать полностью 1
41

Что находится между идеей и кодом? Обзор 14 диаграмм UML

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Аве Кодер! Тебе пришла крутая идея продукта, но ты не хочешь увязнуть в коде и потерять целостную картинку из-за мелких деталей? Ты вот-вот присядешь за то, что крякнул корпоративный сервер и тебе нужно набить что-то крутое и айтишное?


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


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


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


Для тех, кому лень читать и кто предпочитает смотреть и слушать: https://youtu.be/0I9aIP5gKCg


Основные цели дизайна UML:

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

Обеспечить механизмы расширяемости и специализации для расширения основных понятий.

Быть независимым от конкретных языков программирования и процессов разработки.

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

Поощрять рост рынка объектно-ориентированных инструментов.

Поддержка высокоуровневых концепций разработки, таких как совместная работа, структуры, шаблоны и компоненты.

Интегрировать лучшие практики.


Диаграммы UML подразделяют на два типа - это структурные диаграммы и диаграммы поведения.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

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


Диаграммы поведения показывают динамическое поведение объектов в системе, которое можно описать, как серию изменений в системе с течением времени.


Теперь пару слов о каждой из них


Диаграмма классов

https://youtu.be/sVVJp5a41o4


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


Три наиболее важных типа отношений в диаграммах классов (на самом деле их больше), это:

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

-- Наследование, которое имеет непосредственное соответствие наследованию в Объектно-Ориентированном дизайне.

-- Агрегация, которая представляет из себя форму композиции объектов в объектно-ориентированном дизайне.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма компонентов

https://youtu.be/OiVyha3sf_I


На языке унифицированного моделирования диаграмма компонентов показывает, как компоненты соединяются вместе для формирования более крупных компонентов или программных систем.


Она иллюстрирует архитектуры компонентов программного обеспечения и зависимости между ними.

Эти программные компоненты включают в себя компоненты времени выполнения, исполняемые компоненты, а также компоненты исходного кода.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма развертывания

https://youtu.be/Yz8phtJoP7I


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

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


Диаграмма моделирует конфигурацию времени выполнения в статическом представлении и визуализирует распределение артефактов в приложении.

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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма объектов

https://youtu.be/tVW5oHNfAvc


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

Тем не менее, диаграмма объекта представляет собой экземпляр в конкретный момент, который имеет конкретный характер.Использование диаграмм объектов довольно ограничено, а именно - чтобы показать примеры структуры данных.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма пакетов

https://youtu.be/237BWanM4Ak


Диаграмма пакетов - это структурная схема UML, которая показывает пакеты и зависимости между ними.

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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма составной структуры

https://youtu.be/nsuJcMNaKeE


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


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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма профилей

https://youtu.be/qBws7AfvDL8


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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма прецедентов

https://youtu.be/BdAcxboG5No


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

Прецеденты позволяют связать то, что нам нужно от системы с тем, как система удовлетворяет эти потребности.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма деятельности

https://youtu.be/Z8PHBsNXAgc


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

Они описывают поток управления целевой системой, такой как исследование сложных бизнес-правил и операций, а также описание прецедентов и бизнес-процессов.

В UML диаграммы деятельности предназначены для моделирования как вычислительных, так и организационных процессов.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма состояний

https://youtu.be/ojCcUvGfpi8


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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма последовательности

https://youtu.be/ycg3njrkk1c


Диаграмма последовательности моделирует взаимодействие объектов на основе временной последовательности. Она показывает, как одни объекты взаимодействуют с другими в конкретном прецеденте.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма Коммуникации

https://youtu.be/KVLJj9xOq0E


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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма обзора взаимодействия

https://youtu.be/E0OJG8ojEAg


Диаграмма обзора взаимодействий фокусируется на обзоре потока управления взаимодействиями. Это вариант Диаграммы деятельности, где узлами являются взаимодействия или события взаимодействия. Диаграмма обзора взаимодействий описывает взаимодействия, в которых сообщения и линии жизни скрыты. Мы можем связать «реальные» диаграммы и добиться высокой степени навигации между диаграммами внутри диаграммы обзора взаимодействия.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Временная диаграмма

https://youtu.be/NKTyDQUkLoM


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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма
Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Зачем в UML столько диаграмм?


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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

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

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

Напротив, технический писатель интересуется поведением системы в целом и должен понимать, как функционирует продукт.

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



Аве!

Показать полностью 17
384

Стартап на кузове машины

Работаю водителем, но — прошлое даёт о себе знать, — и потому кузов моей служебной машины в ожидании очередной мойки собственноручно расписан (в промежутках между разгрузками-загрузками) всякими умными словами, типа «PHP», «MySQL», «Python», «JQuery» и пр. На днях возвращаюсь к машинке и вижу, как двое юношей, — лет по 14 каждому, —сосредоточенно дополняют роспись. Подхожу.

— Что рисуем, художники?

— Ой, это ваша машина? Извините! Да мы увидели, что у вас тут языки программирования написаны, ну и решили дописать название своего, всё равно хуже не станет.

— Своего?! Какого своего?!

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

Ребята, если вы рассказали мне правду и читаете это на Пикабу — не бросайте это дело! Вы молодцы! Если ваш Next войдёт в обиход — обещаю изучить и даже что-нибудь на нём написать. Может, и с работы водителя соскочу когда-нибудь благодаря вам. Только документацию нормальную сделайте.

2472

Может ли тракторист стать разработчикам игр? Сегодня релиз моей игры в Steam.

Всем привет.

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

Немного отступления:

Тем кто не знаком с моими постами на пикабу вкратце расскажу. Меня зовут Николай, я из Беларуси, по образованию слесарь по сельскохозяйственной техники и как дополнение тракторист(никогда не работал по профессии, максимум что умею это поменять колесо и свечи и то при условии что все легко открутится). Зачем пошел учиться в такую профессию? Да потому что мало кто в 17 лет сильно думает о будущем, тем более с моим аттестатом могли и туда не взять. Старшие классы школы это постоянные прогулы и зависание в компьютерных клубах играя в warcraft, CS и т.п.

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

Может ли тракторист стать разработчикам игр? Сегодня релиз моей игры в Steam. Steam, Gamedev, Длиннопост, Ужасы, Инди, Видео, Трейлер, Unity, Программист, Разработка
Может ли тракторист стать разработчикам игр? Сегодня релиз моей игры в Steam. Steam, Gamedev, Длиннопост, Ужасы, Инди, Видео, Трейлер, Unity, Программист, Разработка

История Генри Бишопа — это мистический триллер в котором герой может использовать предметы, решать загадки, не только прятаться, но и убивать врагов. На игру я потратил 3 года разработки, делал её в гордом одиночестве, откладывая деньги с зарплат, покупая недостающие модели, озвучку, переводы. Игра в данный момент озвучена на 2‑х языках — английский и русский, так же переведена на 8 языков(субтитры).

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

Может ли тракторист стать разработчикам игр? Сегодня релиз моей игры в Steam. Steam, Gamedev, Длиннопост, Ужасы, Инди, Видео, Трейлер, Unity, Программист, Разработка
Может ли тракторист стать разработчикам игр? Сегодня релиз моей игры в Steam. Steam, Gamedev, Длиннопост, Ужасы, Инди, Видео, Трейлер, Unity, Программист, Разработка

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

P.S.

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

Группа игры в ВК

Страница игры в STEAM

Может ли тракторист стать разработчикам игр? Сегодня релиз моей игры в Steam. Steam, Gamedev, Длиннопост, Ужасы, Инди, Видео, Трейлер, Unity, Программист, Разработка
Показать полностью 5
627

(284/366) 13 сентября - день программиста (но только в невисокосные годы)

(284/366) 13 сентября - день программиста (но только в невисокосные годы) Проекткалендарь2, Рисунок, Иллюстрации, Программист, Программирование, Баг, Фича, Костыли

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


PS_1: Кстати, на счет моего фейла с программированием. Я технарь до мозга костей, у меня всегда получались годные оптимальные алгоритмы для программ, но я был полнейшим лентяем, который уткнулся в стену синтаксиса и так и не смог его выучить, поэтому я за 30 секунд понимал как должна работать программа, а потом не мог написать и строчки кода, тк печатал медленно и не мог запомнить синтаксис... Для меня язык программирования был в первую очередь языком... Поэтому я, подумав своим неокрепшим мозгом, решил так: «не можешь срать - не мучай жопу», и ушел по собственному желанию (ну да, пришлось сгонять в армию)


PS_2: Для вновь прибывших: проект-то ежедневный! Я тут каждый день рисую по картинке )))


мой телеграм канал

Показать полностью
921

Забавные баги из Dwarf Fortress (Часть 1)

Привет! Как-то встретился пост про то как карп за мягкое место укусил ребенка, и написал вот этот комментарий и как ни странно - нашел отклик и пару подписчиков. Так что напишу пару постов, раз уж так.

Забавные баги из Dwarf Fortress (Часть 1) Гномы, Dwarf Fortress, Баг, Баги в играх, Разработка, Компьютерные игры, Игры, Забавное, Длиннопост

Кто не знает - Dwarf fortress это крайне объемная стратегическая игра с непрямым управлением, где мы держим крепость бородатых дворфов не имея вдобавок привычной в современном смысле графики, но имея огромное количество возможностей. Вдаваться в рассказы о самой игре не буду, только о том, что необходимо для понимания различных ошибок и забавностей, с игрой связанных. Поехали!



Баг с котами или её величество - КОТОСТРОФА


Перед началом похода для постройки крепости мы можем только несколько часов собирать экипировку и настраивать профессии нашего будущего контингента, в том числе мы имеем возможность взять с собой разнообразную живность, в частности котов. Так как в игре у каждого бородатого дворфа есть даже левый и правый носок и прочие мелкие части одежды, не удивительно, что в игре есть и различные паразиты, например мыши, которые запросто могут хозяйничать на наших продовольственных складах поедая трудом добытую пищу. Соответственно большинство игроков изначально берут с собой пару кошек\котов, чтобы такие вещи полностью исключить. При этом Dwarf Fortress игра достаточно масштабируемая и если начинаем мы всего горсткой в пол десятка дворфов, то в последствии наше поселение может разрастить и до 100+ жителей. И тут могут возникнуть миллион проблем, в частности - КОТОСТРОФА. За долгое или даже не очень время кошки могут запросто наплодиться настолько, что станет ужасно за этим наблюдать, как крепость из дворфской превращается в кошачью. B тут возникает логичной вопрос - Что делать? Проблема в том, что кошки потребляют какую-никакую еду и кроме всего прочего привязываются автоматически к какому-либо дворфу становясь его питомцем. Это приводит к тому, что если начать пускать излишки котов и кошек на фарш, дабы прокормить крепость, то хозяева кошек сильно огорчаются при их смерти, и если процесс вивисекции довольно глобальный может случиться состояние массовой истерии, когда все становятся расстроены настолько что начинается форменное безумие и кровь течет рекой, поэтому в таких ситуациях возможно вивисекция не только кошек, но и их хозяев, дабы хоть как-то избавиться от проблемы. Благо из-за жалоб на эту проблему добавили новую профессию - кастратора - которая позволила контролировать популяцию и недопускать такой дичи.


Раз уж пошло про кошек, то еще один из моих любимых багов:


Кошки довольно полезные животные, потому что они превосходно борются с вредителями, вроде мышей. И как мы уже выяснили у каждой кошки есть свой хозяин, поэтому не редка ситуация, когда кошка хочет перенести труп мышки к своему хозяину дабы похвастаться, но вот незадача, в давние времена, в коде игры было прописано - Чтобы что-нибудь перенести - тебе нужны руки, в то время когда у кошки прописаны 4 ноги. Соответственно кошка потихоньку думает - "Мне нужно перенести мышь!" - "Но для этого нужны руки" - "А у меня рук нет" - "А почему у меня рук нет!!??" - "ЗНАЧИТ МНЕ ИХ ОТОРВАЛО!", после чего она начинает истошно вопить в оповещения что ей оторвало руки, что правда ей не мешает заниматься дальше своими кошачьими делами.

Забавные баги из Dwarf Fortress (Часть 1) Гномы, Dwarf Fortress, Баг, Баги в играх, Разработка, Компьютерные игры, Игры, Забавное, Длиннопост

Для первой части хватит. Посмотрим как зайдет :)


Всем добра, играйте только в хорошие игры.

Показать полностью 1
341

Полезные блоги для IT-специалистов

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

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

Также укажу примеры постов, чтобы сразу можно было открыть и начать читать.

Если в будущем материал по приведенным ссылкам пропадет, ищите с помощью Wayback Machine - https://archive.org/web/



1) Блог Александра Бындю - https://blog.byndyu.ru

- "Работа с унаследованным кодом" - https://blog.byndyu.ru/2014/01/blog-post_8.html

- "Технические долги" - https://blog.byndyu.ru/2008/12/blog-post.html

- "Карьера в IT" - https://blog.byndyu.ru/2011/04/it.html



2) Блог Александра Алексеева - https://eax.me

- "Десять веских причин не тащить в продакшн новые игрушки" - https://eax.me/avoid-new-toys/

- "Почему эти ваши модные NoSQL решения не так уж хороши" - https://eax.me/avoid-nosql/

- "Советы и примеры задач, которые помогут вам в освоении нового языка программирования" - https://eax.me/programming-language-learning/



3) Евгений jdevelop - http://blog.jdevelop.com

- "SCRUM или шабаш ведьм" - http://blog.jdevelop.com/software/2014/03/25/lifestyle.html

- "SCRUM - светлая сторона" - http://blog.jdevelop.com/software/2015/06/28/scrum.html

- "Распознавание образов.. выбор конторы для работы" - http://blog.jdevelop.com/software/2015/11/30/tech.html



4) vit_r - https://vit-r.dreamwidth.org

- "Должен ли ИТ менеджер программировать" (в трех частях) - https://vit-r.livejournal.com/30889.html

- "Про то, как победила дружба, а люди стали рабами машин" - https://vit-r.livejournal.com/621261.html

- "Разговор с фининспектором о поэзии" - https://vit-r.dreamwidth.org/693549.html

- "Конечные автоматы" - https://vit-r.dreamwidth.org/634137.html



5) Блог Сергея Немчинского - https://dou.ua/users/sergey-nemchinsky/articles/

- "Что такое корпоративная культура и как она влияет на вас" - https://dou.ua/lenta/articles/company-culture

- "Enterprise разработка накануне провала традиционных методов" - https://dou.ua/lenta/articles/enterprise-dev

- "Что нам делать с Enterprise-разработкой" - https://dou.ua/lenta/articles/enterprise-dev-2



6) Статьи Игоря Ашманова

- "Словарь ненормативной лексики руководителя" - https://www.ashmanov.com/education/articles/slovar-nenormati...

- "Словарь ненормативной лексики программиста" - https://www.ashmanov.com/education/articles/slovar-nenormati...

- "Правила Ашманова" - https://www.ashmanov.com/education/articles/pravila-ashmanov...

- "Правила Ашманова-2. Управление проектами" - https://www.ashmanov.com/education/articles/pravila-ashmanov...



7) Блог Никиты Прокопова - https://tonsky.livejournal.com

- "Голые короли IT" - https://tonsky.livejournal.com/308320.html

- "Как спорить о языках программирования" - https://tonsky.livejournal.com/297610.html



8) plumqqz - https://plumqqz.livejournal.com

- "Серебряная пуля есть" - https://plumqqz.livejournal.com/116169.html

- "О философско-филологическом аспекте программизма" - https://plumqqz.livejournal.com/434244.html



9) Блог Сергея Теплякова - sergeyteplyakov на блогспот.ком

- "Культ карго в программировании" - http://sergeyteplyakov.<блогспот.ком>/2013/09/blog-post_24.html

- "Шпаргалка по SOLID принципам" - http://sergeyteplyakov.<блогспот.ком>/2014/10/solid.html

- "Книги" - http://sergeyteplyakov.<блогспот.ком>/2013/08/blog-post.html



10) Блог Максима Захарова - wolonter на блогспот.ком

- "О профессионалах" - https://wolonter.<блогспот.ком>/2016/09/blog-post.html

- "О менеджерах, тестировщиках и их отношениях" - http://wolonter.<блогспот.ком>/2016/06/blog-post_21.html



Дополняйте в комментариях, у кого тоже есть интересный материал

Показать полностью
Похожие посты закончились. Возможно, вас заинтересуют другие посты по тегам: