G-код. Или "особо качественный" код, уверен с ним сталкивались все, кроме не программистов. Концептуальный вопрос:
Что делаете, когда вдруг обнаруживаете, как наплели десяток функций по 8 параметров, связанных друг с другом как сиамские близнецы. С горем на пополам избавились от нотисов и вся эта "структура" как бы работает Будете ли переделывать, если придет в голову идея гораздо лучшего устройства? Или "и так сойдет!"?
И еще как, как избегаете таких ситуаций? (Про mvc , OOП знаю). Возможно какие-то схемы рисуете или еще какой-то метод используете?
Спасибо, главные вопросы выделил.
Спустя 36 минут, 40 секунд (2.01.2011 - 11:22) Michael написал(а):
Есть еще с функциями такой прикол, когда вложенность вызовов зашкаливает.
Т.е. одна вызывается из другой и так на глубину в 20.
Т.е. одна вызывается из другой и так на глубину в 20.
Цитата |
Будете ли переделывать, если придет в голову идея гораздо лучшего устройства? Или "и так сойдет!" |
Если платят, то надо переделывать, или например дальше тебе же с этим кодом работать. Вообще ситуация когда на один плохой код лепят заплаты для внесения функционала - опаснейшая вешь. Фирмы банкротятся из за этого.
Если же типа доделать, чтобы работало, подешевле - кто будет пионерить то?
Общий совет тут - погугли основы защитного программирования - как защищать код от проблем и легко идентифицировать проблемы. Работает и с чужим кодом.
Спустя 38 минут, 27 секунд (2.01.2011 - 12:00) sergeiss написал(а):
Цитата (T1mer @ 2.01.2011 - 11:45) |
G-код. Или "особо качественный" код, уверен с ним сталкивались все, кроме не программистов. |
Пару минут тупо смотрел на это высказывание и пытался понять его
Цитата (T1mer @ 2.01.2011 - 11:45) |
Что делаете, когда вдруг обнаруживаете, как наплели десяток функций по 8 параметров, связанных друг с другом как сиамские близнецы. |
Цитата (T1mer @ 2.01.2011 - 11:45) |
И еще как, как избегаете таких ситуаций? |
"Опыт - сын ошибок трудных". Чем больше "кодишь", тем реже такие ситуации возникают. И обычно переделываю
Избежать этого очень просто: надо хорошо продумать структуру приложения. Чем оно сложнее, чем "суровее" будет моя рекомендация нарисовать структуру на бумаге. Естественно, не всё предусмотришь, но чем меньше будет косяков, тем (психологически) легче переделать то, что накосячил (и сам же это понял).
Да и потом, по прошествии времени, нарисованная структура поможет быстрее вспомнить, что и зачем делал.
Спустя 1 час, 34 минуты, 49 секунд (2.01.2011 - 13:35) T1mer написал(а):
Цитата | ||
Пару минут тупо смотрел на это высказывание и пытался понять его |
Это я еще не переключился на человеческое письмо просто Продолжал лепить через не то место мысли.
Цитата |
Есть еще с функциями такой прикол, когда вложенность вызовов зашкаливает. Т.е. одна вызывается из другой и так на глубину в 20. |
Не, у меня больше 2х вложенностей не было Но все равно не легче вышло.
Цитата |
Общий совет тут - погугли основы защитного программирования - как защищать код от проблем и легко идентифицировать проблемы. Работает и с чужим кодом. |
Вот это похоже то что надо, на половине кода мозг заканчивает обрабатывать что где и для чего