Сообщение Re[6]: Эмпирическое правило пересмотра архитектуры от 14.07.2015 12:05
Изменено 14.07.2015 12:32 alexzzzz
Я второй год в качестве хобби делаю проект игровой направленности. Задумка была такова, что никаких аналогов я не видел даже близко. Не на кого было ориентироваться, негде было поучиться. Я даже понятия не имел, как будет выглядеть конечный результат трудов, да и сейчас ещё не до конца понимаю.
Эдакий домашний исследовательский проект, в котором по мере развития постоянно сплывают всевозможные ограничения, которые было трудно предвидеть заранее и которые приходится обходить. Если бы был какой-то образец для подражания, делать его клон было бы в 20 раз проще.
LVV>>6 раз переделывалась именно архитектура — в первые 3 года.
DA>Типа круто?
Типа такое запросто может быть по объективным причинам.
LVV>>И сейчас развитие отдельных подсистем иногда подвигает на пересмотр базовых основ...
DA>Т.е. изначально полный угар.
Это как если бы заказчик менял ТЗ раз в месяц, только заказчик в этом случае ты сам. И перестать менять ТЗ ты не можешь, потому что иначе проект в связи с вновь открывшимися обстоятельствами перестаёт иметь смысл и его можно сворачивать.
T>>>Зло копипасты максимум в генерации ошибок, не преувеличивайте.
LVV>>1. Разбухание кода.
LVV>>2. Тиражирование ошибок, не выявленных в первоначальной копии.
2. Скорее, тиражирование ошибок, уже выявленных и исправленных в первоначальной копии.
3. У меня копипаста периодически ещё приводила к ситуациям, когда у тебя есть несколько вариантов примерно одинакового кода, который решает примерно одинаковую задачу, но немного по-разному с немного разными результатами. И через некоторое время я уже переставал понимать какой именно вариант мне нужен в конкретном случае.
Эдакий домашний исследовательский проект, в котором по мере развития постоянно сплывают всевозможные ограничения, которые было трудно предвидеть заранее и которые приходится обходить. Если бы был какой-то образец для подражания, делать его клон было бы в 20 раз проще.
LVV>>6 раз переделывалась именно архитектура — в первые 3 года.
DA>Типа круто?
Типа такое запросто может быть по объективным причинам.
LVV>>И сейчас развитие отдельных подсистем иногда подвигает на пересмотр базовых основ...
DA>Т.е. изначально полный угар.
Это как если бы заказчик менял ТЗ раз в месяц, только заказчик в этом случае ты сам. И перестать менять ТЗ ты не можешь, потому что иначе проект в связи с вновь открывшимися обстоятельствами перестаёт иметь смысл и его можно сворачивать.
T>>>Зло копипасты максимум в генерации ошибок, не преувеличивайте.
LVV>>1. Разбухание кода.
LVV>>2. Тиражирование ошибок, не выявленных в первоначальной копии.
2. Скорее, тиражирование ошибок, уже выявленных и исправленных в первоначальной копии.
3. У меня копипаста периодически ещё приводила к ситуациям, когда у тебя есть несколько вариантов примерно одинакового кода, который решает примерно одинаковую задачу, но немного по-разному с немного разными результатами. И через некоторое время я уже переставал понимать какой именно вариант мне нужен в конкретном случае.
Re[6]: Эмпирическое правило пересмотра архитектуры
Я второй год в качестве хобби делаю проект игровой направленности. Задумка была такова, что никаких аналогов я не видел даже близко. Не на кого было ориентироваться, негде было поучиться. Я даже понятия не имел, как будет выглядеть конечный результат трудов, да и сейчас ещё не до конца понимаю.
Эдакий домашний исследовательский проект, в котором по мере развития постоянно сплывают всевозможные ограничения, которые было трудно предвидеть заранее и которые приходится обходить. Если бы был какой-то образец для подражания, делать его клон было бы в 20 раз проще.
LVV>>6 раз переделывалась именно архитектура — в первые 3 года.
DA>Типа круто?
Типа такое запросто может быть по объективным причинам.
LVV>>И сейчас развитие отдельных подсистем иногда подвигает на пересмотр базовых основ...
DA>Т.е. изначально полный угар.
Это как если бы заказчик менял ТЗ раз в месяц, только заказчик в этом случае ты сам. И перестать менять ТЗ ты не можешь, потому что старое в связи с вновь открывшимися обстоятельствами перестаёт иметь смысл и тогда проект можно сворачивать.
T>>>Зло копипасты максимум в генерации ошибок, не преувеличивайте.
LVV>>1. Разбухание кода.
LVV>>2. Тиражирование ошибок, не выявленных в первоначальной копии.
2. Скорее, тиражирование ошибок, уже выявленных и исправленных в первоначальной копии.
3. У меня копипаста периодически ещё приводила к ситуациям, когда у тебя есть несколько вариантов примерно одинакового кода, который решает примерно одинаковую задачу, но немного по-разному с немного разными результатами. И через некоторое время я уже переставал понимать какой именно вариант мне нужен в конкретном случае.
Эдакий домашний исследовательский проект, в котором по мере развития постоянно сплывают всевозможные ограничения, которые было трудно предвидеть заранее и которые приходится обходить. Если бы был какой-то образец для подражания, делать его клон было бы в 20 раз проще.
LVV>>6 раз переделывалась именно архитектура — в первые 3 года.
DA>Типа круто?
Типа такое запросто может быть по объективным причинам.
LVV>>И сейчас развитие отдельных подсистем иногда подвигает на пересмотр базовых основ...
DA>Т.е. изначально полный угар.
Это как если бы заказчик менял ТЗ раз в месяц, только заказчик в этом случае ты сам. И перестать менять ТЗ ты не можешь, потому что старое в связи с вновь открывшимися обстоятельствами перестаёт иметь смысл и тогда проект можно сворачивать.
T>>>Зло копипасты максимум в генерации ошибок, не преувеличивайте.
LVV>>1. Разбухание кода.
LVV>>2. Тиражирование ошибок, не выявленных в первоначальной копии.
2. Скорее, тиражирование ошибок, уже выявленных и исправленных в первоначальной копии.
3. У меня копипаста периодически ещё приводила к ситуациям, когда у тебя есть несколько вариантов примерно одинакового кода, который решает примерно одинаковую задачу, но немного по-разному с немного разными результатами. И через некоторое время я уже переставал понимать какой именно вариант мне нужен в конкретном случае.