Стратегия программирования
Есть ли какие-то правила доработки проектов ПО?Да
Это называется архитектура. Её трудно внести в уже написанный как-то проект. А для кода комментарии надо писать и соглашения соблюдать.
Её трудно внести в уже написанный как-то проект.Ну вообще-то проще, чем сделать заранее. Ну т.е. ее не особо надо вносить, она там уже какая-то есть, надо ее описать. Тогда уже станет понятнее. Если еще переделать на что-то лучшее, то вообще супер (если хорошо переделать
)Описываемая тобой ситуация - типичная для любого проекта. Рано или поздно настает момент, когда система разрастается настолько, что переступает грань понимания.
А "стратегия" программирования (приемы построения архитектуры сложных систем) - это средство отодвинуть этот момент как можно дальше. В идеале - отодвинуть на бесконечность
В таких случаях, как твой, применяется два подхода: радикальный (переписать все с нуля как следует) и паллиативный (не пытаться понять всю систему, а решать проблемы по мере поступления).
Ну или комбинированный подход: разрезать программу на независимые куски, и составлять новую версию из них, а к кускам относиться как к черным ящикам.
А "стратегия" программирования (приемы построения архитектуры сложных систем) - это средство отодвинуть этот момент как можно дальше. В идеале - отодвинуть на бесконечность
В таких случаях, как твой, применяется два подхода: радикальный (переписать все с нуля как следует) и паллиативный (не пытаться понять всю систему, а решать проблемы по мере поступления).
Ну или комбинированный подход: разрезать программу на независимые куски, и составлять новую версию из них, а к кускам относиться как к черным ящикам.
Ну ты радикально, надо попытаться все задокументировать для начала. И вообще, сколько там строк кода, скажите, какие технологии используются?
могу порекомендовать книгу С.Макконел. Совершенный код.
зы: далеко не всем она нравится, много воды, но мысли там хорошие
зы: далеко не всем она нравится, много воды, но мысли там хорошие
И вообще, сколько там строк кода, скажите, какие технологии используются?Учти, что "предельный размер системы", он же "горизонт познания" определяется тремя основными факторами:
- (главный) архитектура системы
- качество кода (+ комментариев, документации к функциям)
- уровень программиста
Первые два тебе топикстартер, возможно, и объяснит, но выводы сделать ты все равно не сможешь, из-за неизвестного 3.
Ну там сейчас 400 строк, технологии какие - хз. Чтение файлов, арифметические действия, запись новых файлов. Используются winApi функции. Пишется все на Autoit.
Программа - фактически костыль для связи двух программ, одна из которых генерит входы для работы другой.
Программа - фактически костыль для связи двух программ, одна из которых генерит входы для работы другой.
400 строк - и вы уже не можете разобраться в коде программы?
Да эти 400 строк за два часа с нуля переписываются.
Да эти 400 строк за два часа с нуля переписываются.
Кто минусует? 400 строк — реально маловато, чтобы было нельзя разобраться. Переписывал на заказ и поболее программки
Кто минусует? 400 строк — реально маловато, чтобы было нельзя разобраться. Переписывал на заказ и поболее программкиМинусанул за "точную" оценку в два часа на переписывание. Слишком голословное утверждение.
Мой личный "рекорд": 3 недели переписывал 600 строк кода, причем первые дня четыре просто пытался его понять.
мои правила:
1)делить программу на изолированные куски. Чем сильнее эти куски изолированы, тем лучше
2)у каждого куска должен быть более-менее фиксированный интерфейс. Изменение интерфейса - это существенное обновление ПО.
Реализация этого интерфейса - черный ящик, о котором может знать только один программист из коллектива разработчиков. А вот описание интерфейса должны представлять себе все программисты.
3)отдельные куски постоянно жестко тестируются (например, при каждом билде чем больше case-ов тем лучше.
4)работа с репозиторием через систему контроля версий
5)проект разрастается, появляются требования, которые первоначально нельзя было предусмотреть. Значит пора сделать качественный скачок - обновить интерфейс "черных ящиков".
1)делить программу на изолированные куски. Чем сильнее эти куски изолированы, тем лучше
2)у каждого куска должен быть более-менее фиксированный интерфейс. Изменение интерфейса - это существенное обновление ПО.
Реализация этого интерфейса - черный ящик, о котором может знать только один программист из коллектива разработчиков. А вот описание интерфейса должны представлять себе все программисты.
3)отдельные куски постоянно жестко тестируются (например, при каждом билде чем больше case-ов тем лучше.
4)работа с репозиторием через систему контроля версий
5)проект разрастается, появляются требования, которые первоначально нельзя было предусмотреть. Значит пора сделать качественный скачок - обновить интерфейс "черных ящиков".
мои правилаА мои правила проще: не доверять руководство разработкой людям, у которых "с теорией (стратегией программирования) слабовато".
как определить, хорошо или плохо у человека со стратегией программирования?
как определить, хорошо или плохо у человека со стратегией программирования?Попросить кого-нибудь, у кого с этим точно хорошо, прособеседовать претендента.
ты повелитель рекурсии?
ты повелитель рекурсии?Не понял юмора.
Если Университет хочет узнать, насколько у студента хорошо с матаном, то Университет приглашает кого-то, у кого с матаном заведомо хорошо (например преподавателя матана и просит проэкзаменовать студента. Тут в точности то же самое.
у тебя плохо с юмором. говорю как человек, у которого с юмором хорошо.
ты повелитель рекурсии?Не обязательно же нанимать человека для того чтобы собеседование провести.
Оставить комментарий
roman-us
Есть некий проект разработки софта, который до конца не описан и не структурирован. Описана и реализована основная идея, постепенно дописываются куски кода, реализующие различные дополнительные функции.Постепенно код становится плохо читаемым, уже забывается, что делает тот или иной кусок.
Есть ли какие-то правила доработки проектов ПО? С теорией (стратегией программирования) слабовато потому что.