и да, что ты подразумеваешь под "архитектурой"?)

разбивку системы на контексты/больши модули?

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

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

неудобно ж

неудобно ж

что неудобно? опять со своими необоснованными заявлениями?

в draw.io хотя бы можно линку сразу отправть и обновлять по ходу. А сохранять html и отправлять - это рак

и да, что ты подразумеваешь под "архитектурой"?)

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

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

ну ты хоть только те штуки которые на границах модулей живут так описываешь?) не все подряд?) ну то есть мне просто реально интересно

в draw.io хотя бы можно линку сразу отправть и обновлять по ходу. А сохранять html и отправлять - это рак

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

ну ты хоть только те штуки которые на границах модулей живут так описываешь?) не все подряд?) ну то есть мне просто реально интересно

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

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

ну а у меня там надо раз в 10 секунд тогда сохранять html и отправлять кому-то. Ну и ни у кого из "у нас" небыло проблем со скоростью работы draw.io

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

тебе для этого лучше всего idef нотация подойдет

ну а у меня там надо раз в 10 секунд тогда сохранять html и отправлять кому-то. Ну и ни у кого из "у нас" небыло проблем со скоростью работы draw.io

рад за вас

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

а как определяешь на какой уровень декомпозиции надо описывать?

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

ну и есть ли разделение команды на "вот эти челики отвечают за эти модули а вот те за другие"?

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

не надо делать работу за программиста

ему станет не интересно работать

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

а у тебя есть вообще успешный опыт такой затеи?

чтобы вот так вот все строго по интерфейсам собралось и _заработало_ ?

Да, но только в своей команде, где ты и жнец и на дуде игрец.

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

это тоже минус

слишком много на себя берешь.. учись делегировать и проверять

сколько loc ?

Какое-то бюрократическое усложнение кмк

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

сколько раз такая ситуация возникала?

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

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

сколько раз такая ситуация возникала?

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

слишком много на себя берешь.. учись делегировать и проверять

вот тоже к этому пришел.

с удаленной командой все намного сложнее и по-другому

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

ну если с малыми ок получалось, то просто дели большое на малое и дальше - по накатаной.

да.. декомпозируй в черные ящики

по возможности )

с удаленной командой все намного сложнее и по-другому

да удаленщики вообще гады ?

Вот в этом основной косяк. На сложном может что-то пойти не так. И вот тут настанец абзац

да удаленщики вообще гады ?

я удаленщик )

Я тупо могу неправильно спроектировать что-то. К примеру упустить какую-нить деталь и все гг бб досвидания.

Вот в этом основной косяк. На сложном может что-то пойти не так. И вот тут настанец абзац

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

я удаленщик )

да я тоже, почти )

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

Это то да, на словах это все изи)

в идеале SOA но это сложно и дорого

Я тупо могу неправильно спроектировать что-то. К примеру упустить какую-нить деталь и все гг бб досвидания.

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

Это то да, на словах это все изи)

как и все остальное на словах )

Какое-то бюрократическое усложнение кмк

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

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

чем на меньшие (по сроку реализации) проверяемые блоки разбит функционал, тем меньше риски

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

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

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

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

гдеб его взять )

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

хорошо помогает на ревью кому компетентному требования отдать.

гдеб его взять )

да, я занят до середины мая, сорян пацаны ?

Я тупо могу неправильно спроектировать что-то. К примеру упустить какую-нить деталь и все гг бб досвидания.

waterfall не работает, agile не работает - работает чтото среднее между ними

waterfall не работает, agile не работает - работает чтото среднее между ними

Согласен, бывал во всех ситуациях)

русский вотерфлоуаджайл )

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

waterfall не работает, agile не работает - работает чтото среднее между ними

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

если будут погружены в проект

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

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

всем привет. кто нибудь встречался с проблемой настройки DNS на DigitalOcean?

всем привет. кто нибудь встречался с проблемой настройки DNS на DigitalOcean?

в чем проблема? у мня пет там крутится - проблем не было

а что не так?

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

waterfall не работает, agile не работает - работает чтото среднее между ними

есть хороший видос на эту тему

https://www.youtube.com/watch?v=UQOmGiv7rUk

ERROR: S client not available

как по мне лучший в этой категории

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

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

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

Подробно описывать задачу ж)

Ну вообще общаться это хорошо

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

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

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

опять всё свелось к ddd эванса.

в идеале SOA но это сложно и дорого

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

чувствуешь что идет не понимание - обговариваешь голосом

опять всё свелось к ddd эванса.

это ж не Эванс придумал)

больше говорить придеться

больше говорить придеться

так это ж хорошо!

если на митинге нет менеджера и он не рекуррентный - скорее всего он будет продуктивным и нужным)

не все понимают, а когда понимают уже поздно )

так это ж хорошо!

+

есть те кто пытался заспидапить behat?

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

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

это ж не Эванс придумал)

здравый смысл точно он не придумал

Мне кажется картинка в этой схеме что-то лишнее, ну или как минимум необязательное

вы можете ее начать рисовать сразу вместе

картинка поможет визуалам, а что с остальными типами людей делать?

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

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

http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf - где-то после схемки про ватерфол

5 страниц рассуждений "почему это не будет работать и какие риски несет и что можно сделать"

я иногда грущу что этому доку аж 45+ лет а народ все еще перегибает палку в сторону upfront design когда думать дальше уже нет смысла

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

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

картинка поможет визуалам, а что с остальными типами людей делать?

gherkin?)

на русском причем)

Подробно описывать задачу ж)

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

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

Ну опишите систему в целом)

Тем более имеет значение, кому ты ставишь задачу. Если человек опытный, то ноль проблем. А если нет?

Чего вы так на картинках зациклились