Почему-то этот тезис что надо делать все сразу и хорошо, чтобы не приходилось переделывать, слушается очень вкусно, и спорить даже не хочется. Но с другой стороны для разработки ПО это же убийственный тезис, представляю сколько денег нужно чтобы сделать все сразу и хорошо, т.к. понятие хорошо очень быстро меняется. Например 100 Мб дистрибутив совсем недавно было очень плохо, и чтобы сделать сразу и хорошо приходилось на его оптимизацию тратить большое количество ресурсов.
Может этот тезис пошел из каких-то других областей, например из строительства и разработчики его стали повторять.
Согласны ли вы что нужно все делать сразу и хорошо чтоб не приходилось переделывать ?
И в скольких проектах получалось достигнуть этого ?
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>Почему-то этот тезис что надо делать все сразу и хорошо, чтобы не приходилось переделывать, слушается очень вкусно, и спорить даже не хочется. Но с другой стороны для разработки ПО это же убийственный тезис, представляю сколько денег нужно чтобы сделать все сразу и хорошо, т.к. понятие хорошо очень быстро меняется. Например 100 Мб дистрибутив совсем недавно было очень плохо, и чтобы сделать сразу и хорошо приходилось на его оптимизацию тратить большое количество ресурсов.
это настолько зависит от проекта, что дискуссия не имеет смысла.
O>Согласны ли вы что нужно все делать сразу и хорошо чтоб не приходилось переделывать ?
проблема в том, что зачастую неизвестно, как это — хорошо.
поэтому система должна быть гибкой и допускать безболезненный рефакторинг.
F>это настолько зависит от проекта, что дискуссия не имеет смысла.
А можно примеры когда это зависит от проекта. Речь конечно только о софтверных проектах.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
F>>это настолько зависит от проекта, что дискуссия не имеет смысла. O>А можно примеры когда это зависит от проекта.
небольшие проекты с точно зафиксированными требованиями можно сразу сделать хорошо.
очень помогает, когда команда делает то, что уже знает, как делать.
с крупными проектами типа ОС, где требования плавают или не определены до сих пор, нереально сделать всё красиво.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, okon, Вы писали:
F>>>это настолько зависит от проекта, что дискуссия не имеет смысла. O>>А можно примеры когда это зависит от проекта.
F>небольшие проекты с точно зафиксированными требованиями можно сразу сделать хорошо.
Возможно, но на моей практике к таким фиксированным проектам относится что-то из решения какой-то конкретной прикладной задачи например формирования отчета, или какого-то робота по обработке массива данных, т.е. то что можно сделать за 1 присест, и то бывает что нужно что-то туда добавлять. Как правило такие мелкие программки пишутся наоборот плохо с т.з. дизайна, без тестов, классов и слоев, но быстро.
Все что больше, например интерфейс с 5-10 формами, как правило уже сильно подвержено изменениям со временем и сложно написать сразу и хорошо
F>очень помогает, когда команда делает то, что уже знает, как делать. F>с крупными проектами типа ОС, где требования плавают или не определены до сих пор, нереально сделать всё красиво.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
F>>это настолько зависит от проекта, что дискуссия не имеет смысла. O>А можно примеры когда это зависит от проекта. Речь конечно только о софтверных проектах.
Ну вот тебе два крайних примера:
1. Запуск спутника или космического зонда. Требования к софту заранее все известны сделать хорошо — можно. При этом запуск будет один, в него вложена куча денег, а возможность внесения изменений в софт после запуска будет невозможна или очень сильно ограничена. Тут надо делать сразу хорошо.
2. Бизнес хочет сделать себе автоматизацию работы, но у них царит определенный хаос, процессы не жесткие, хотя заодно хотят их формализовать, а потому требования к системе будут еще уточняться после ее внедрения. В результате тут система однозначна будет еще уточняться и переделываться за время своей жизни.
Здравствуйте, fmiracle, Вы писали:
F>Здравствуйте, okon, Вы писали:
F>>>это настолько зависит от проекта, что дискуссия не имеет смысла. O>>А можно примеры когда это зависит от проекта. Речь конечно только о софтверных проектах.
F>Ну вот тебе два крайних примера: F>1. Запуск спутника или космического зонда. Требования к софту заранее все известны сделать хорошо — можно. При этом запуск будет один, в него вложена куча денег, а возможность внесения изменений в софт после запуска будет невозможна или очень сильно ограничена. Тут надо делать сразу хорошо.
Тут только не понятно что значит хорошо, например в случае 2 хорошо это когда легко внести изменение, когда код можно сопровождать.
Но в случае1 спутника эти качества не очень нужны, хорошо в данном случае это когда код просто работает, может не очень оптимально, не масштабируем, но достаточно чтобы выполнить функции. Т.е. по большому счету отлаженный лапшекод в одной функции тут вполне подойдет.
F>2. Бизнес хочет сделать себе автоматизацию работы, но у них царит определенный хаос, процессы не жесткие, хотя заодно хотят их формализовать, а потому требования к системе будут еще уточняться после ее внедрения. В результате тут система однозначна будет еще уточняться и переделываться за время своей жизни.
F>Ну и между ними есть какие-то средние случаи.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>Тут только не понятно что значит хорошо
Какая разница?
Ты же спрашиваешь не о том, что такое "хорошо", а каково делать "сразу хорошо"?
Ну так не важно, как определяется хорошо для данного случая. Важно — можешь ты потом внести изменения, чтобы исправить то, что изначально получилось "не очень хорошим" или нет. Или, в общем случае, насколько проблематично будет потом внести эти изменения.
Здравствуйте, okon, Вы писали:
O>Возможно, но на моей практике к таким фиксированным проектам относится что-то из решения какой-то конкретной прикладной задачи например формирования отчета, или какого-то робота по обработке массива данных, т.е. то что можно сделать за 1 присест, и то бывает что нужно что-то туда добавлять. Как правило такие мелкие программки пишутся наоборот плохо с т.з. дизайна, без тестов, классов и слоев, но быстро.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, okon, Вы писали:
O>>Возможно, но на моей практике к таким фиксированным проектам относится что-то из решения какой-то конкретной прикладной задачи например формирования отчета, или какого-то робота по обработке массива данных, т.е. то что можно сделать за 1 присест, и то бывает что нужно что-то туда добавлять. Как правило такие мелкие программки пишутся наоборот плохо с т.з. дизайна, без тестов, классов и слоев, но быстро.
F>плохо быть тобой. и неэффективно.
Почему , если заказчик доволен сроками и работой Или плохо тем что цены сбиваю
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>Согласны ли вы что нужно все делать сразу и хорошо чтоб не приходилось переделывать ?
Закон Сантехника "Грамм, Градус, Копейка" на моей памяти ещё никому не удавалось обойти. Для нас он звучит как "Выбери два из трёх: время, качество, ресурсы.". Т.к. в теме речь идёт о качестве, то очевидно, что сделать сразу и хорошо можно только либо при неограниченных ресурсах, либо при неограниченном времени. И то, только в идеальных условиях, когда, например, банальная глупость менеджеров, архитекторов и разработчиков стремится к нулю.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, okon, Вы писали:
O>Согласны ли вы что нужно все делать сразу и хорошо чтоб не приходилось переделывать ?
Тут небольшое передёргивание, кмк. Чтоб и всё, и сразу, да ещё и хорошо — такого не бывает, см на треугольник MSF в изложении IT
. Или мы не допускаем его возникновения, или строим процесс разработки так, чтоб это не было значимым риском, или в итоге застреваем в "чтобы сделать A, надо сначала починить B, но тогда отвалится C".
Весь секрет мастера заключается в том, чтобы сдать проект до наступления третьего варианта
Я бы сказал так. Ключевое — это разработка новой системы или доработка существующего проекта.
Если новый проект, то можно сразу сделать "хорошо". Хотя часто бывает, что те кто придут за тобой с этим не согласятся.
Если доработка — то сразу накладывается куча ограничений. Да и обычно не даст никто полностью переписывать работающую систему. Соответственно при доработке у меня позиция
1. Нужно представлять — как оно должно быть и как оно должно работать.
2. Любое изменение должно приближать к идеальной картине системы.
3. Возможны исключения из пункта 2 — когда надо сделать что-то одноразовое и быстро. Но когда приходят с этим одноразовым во второй раз (а такое бывает в 90% случаев), то сделано должно быть по пункту 2
Здравствуйте, Sammo, Вы писали: S>1. Нужно представлять — как оно должно быть и как оно должно работать. S>2. Любое изменение должно приближать к идеальной картине системы. S>3. Возможны исключения из пункта 2 — когда надо сделать что-то одноразовое и быстро. Но когда приходят с этим одноразовым во второй раз (а такое бывает в 90% случаев), то сделано должно быть по пункту 2
Просто тут часто путают "должно" с технической точки зрения и "должно" с т.з. бизнесовой
Например какая-то операция которая делается 100 раз в день выполняется за 10 секунд. Т.е. где-то в общем набегает за день 15 минут рабочего времени.
Если посмотреть на нее с технической точки зрения то можно увидеть что там допустим используется не эффективный алгоритм и "должен" использоваться правильный быстрый алгоритм в результате чего операция будет выполняться <1 секунды.
Но с т.з. бизнеса это может быть и не нужно совсем, если 10 секунд на операцию бизнесу не мешают, например у вас поток клиентов такой что клиенты обращаются раз в 5 минут и 10 секунд тут не дают снижение пропускной способности. И с т.з. бизнеса идеальная картина мира — это сделать не дорогой и достаточный алгоритм не обязательно правильный с технической точки зрения
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>Согласны ли вы что нужно все делать сразу и хорошо чтоб не приходилось переделывать ?
Это зависит от проекта. Если проект простой, типовой и в нём с самого начала ясно, как что делать, то дешевле и быстрее может оказаться сделать сразу всё правильно.
Если уровень неопределённости велик, то попытка всё-всё заранее спланировать и сделать сразу в лучше виде с большой вероятностью проект прикончит.
Искусство управления проектом отчасти в том и состоит, чтобы для конкретного проекта выбрать баланс между предиктивностью и адаптивностью модели управления.
Или плохо тем что цены сбиваю 
Если нам не помогут, то мы тоже никого не пощадим.
