Рассуждения чересчур категоричны, но это неплохо для того чтобы обратить внимание на часто необоснованную сложность систем.
В поднятом вопросе я согласен с Макконнеллом, если принятые архитектурные или другие решения упрощают поддержку результирующей системы, то это качественные решения и наоборот: Программные проекты редко терпят крах по техническим причинам. Чаще всего провал объясняется неадекватной выработкой требований, неудачным планированием или неэффективным управлением. Если же провал обусловлен все-таки преимущественно технической причиной, очень часто ею оказывается неконтролируемая сложность. Иначе говоря, приложение стало таким сложным, что разработчики перестали по-настоящему понимать, что же оно делает. Если работа над проектом достигает момента, после которого уже никто не может полностью понять, как изменение одного фрагмента программы повлияет на другие фрагменты, прогресс прекращается.
Управление сложностью — самый важный технический аспект разработки ПО. По-моему, управление сложностью настолько важно, что оно должно быть Главным Техническим Императивом Разработки ПО.
Полезный материал, инструментов куча, не знаешь на что обратить внимание. Было бы здорово еще пару слов о стоимости добавить, понимаю, что информация есть на сайтах, но личное впечатления дорого/дешево было бы полезно, может какой-то freemium есть.
> Для зарегистрировавшихся пользователей у нас предусмотрен telegram-канал, в котором можно позадавать вопросы, пообщаться и предложить свои фичи.
В телеграм-канале я уже высказывал свое мнение. Одно занудное сообщение про сравнение цен с FirstVDS от меня было.
> Что же касается публичного бэклога, краткая выжимка сейчас есть на сайте, страница «О проекте».
Да, я видел, извините, но там обо всем сразу и непонятно в каком порядке и почему. Я предложил вам спросить у пользователей их мнения, делать это или нет, конечно решать вам.
Пока функциональных возможностей для пользователя еще совсем немного, но потенциал у продукта есть.
Может вам стоило бы больше рассказать про сам продукт, какие цели стоят, на какие вопросы еще не нашли ответа, ограничения, риски и т.п. Также можно выложить основные фичи из беклога для голосования, чтобы сравнить ожидания с пользователями? Я вот, к примеру, думаю, что вы планируете сделать местный digital ocean, а у вас может другие виды.
Я попытался описать среднюю температуру по больнице, представить как будут рассуждать про удаленку после эксперимента и почему.
Сам я работал и организовывал работу людей в разных условиях, и считаю, что удаленка — один из возможных вариантов, со своими плюсами и минусами. Однако этот обязательный период доверие к удаленке подорвет, и мне будет сложнее делать мою работу в результате, так как в том числе я помогаю и организовать разработку из удаленных сотрудников.
Для многих это ещё и постоянные коммуникации с командой, в том числе в фоновом режиме. Сидишь, в полуха слушаешь о чём народ говорит и в курсе происходящего, а то и вмешаешься.
Да, есть такое. И это относится к поддержанию информационного пространства, одна из задач руководства, которая делает работу руководителя удаленных сотрудников сложнее.
Получится не так, в описанном подходе комментарии оставляются при желании в самом исходном коде, а в интерфейсе гитхаба или аналогичной системы можно продолжить обсуждение.
Ну и ревью — это далеко не всегда задачи, это могут быть вопросы, либо указания на то, что сделано хорошо, или еще что-то.
Ваше непонимание говорит о том, что потребности в таком подходе у вас еще не родилось, наверное не было таких задач )
Комментарий хорош.
Добавлю, что ваша точка зрения мне очень симпатична, ее бы куда-нибудь в принципе сообщества вывести, лаконично и емко выражена.
Рассуждения чересчур категоричны, но это неплохо для того чтобы обратить внимание на часто необоснованную сложность систем.
В поднятом вопросе я согласен с Макконнеллом, если принятые архитектурные или другие решения упрощают поддержку результирующей системы, то это качественные решения и наоборот:
Программные проекты редко терпят крах по техническим причинам. Чаще всего провал объясняется неадекватной выработкой требований, неудачным планированием или неэффективным управлением. Если же провал обусловлен все-таки преимущественно технической причиной, очень часто ею оказывается неконтролируемая сложность. Иначе говоря, приложение стало таким сложным, что разработчики перестали по-настоящему понимать, что же оно делает. Если работа над проектом достигает момента, после которого уже никто не может полностью понять, как изменение одного фрагмента программы повлияет на другие фрагменты, прогресс прекращается.Управление сложностью — самый важный технический аспект разработки ПО. По-моему, управление сложностью настолько важно, что оно должно быть Главным Техническим Императивом Разработки ПО.Вот это правда и оттого ещё грустнее )
Начало интересное, посмотрю внимательней, спасибо!
С идеями согласен, донесено хорошо.
Было бы совсем круто, если бы приведи примеры хорошей или плохой документации, с указанием, что именно хорошо и плохо.
В телеграм-канале я уже высказывал свое мнение. Одно занудное сообщение про сравнение цен с FirstVDS от меня было.
> Что же касается публичного бэклога, краткая выжимка сейчас есть на сайте, страница «О проекте».
Да, я видел, извините, но там обо всем сразу и непонятно в каком порядке и почему. Я предложил вам спросить у пользователей их мнения, делать это или нет, конечно решать вам.
Пока функциональных возможностей для пользователя еще совсем немного, но потенциал у продукта есть.
Может вам стоило бы больше рассказать про сам продукт, какие цели стоят, на какие вопросы еще не нашли ответа, ограничения, риски и т.п. Также можно выложить основные фичи из беклога для голосования, чтобы сравнить ожидания с пользователями? Я вот, к примеру, думаю, что вы планируете сделать местный digital ocean, а у вас может другие виды.
В любом случае удачи в реализации проекта!
Ваша позиция вполне обоснована и понятна мне.
Я попытался описать среднюю температуру по больнице, представить как будут рассуждать про удаленку после эксперимента и почему.
Сам я работал и организовывал работу людей в разных условиях, и считаю, что удаленка — один из возможных вариантов, со своими плюсами и минусами. Однако этот обязательный период доверие к удаленке подорвет, и мне будет сложнее делать мою работу в результате, так как в том числе я помогаю и организовать разработку из удаленных сотрудников.
Да, есть такое. И это относится к поддержанию информационного пространства, одна из задач руководства, которая делает работу руководителя удаленных сотрудников сложнее.
Ну и ревью — это далеко не всегда задачи, это могут быть вопросы, либо указания на то, что сделано хорошо, или еще что-то.
Ваше непонимание говорит о том, что потребности в таком подходе у вас еще не родилось, наверное не было таких задач )
Даже нечего добавить, спасибо!
Спасибо за отзыв! Я предложил метод, а использовать или нет — ваше дело.