Недавно я участвовал в разработке и написании приложения, которому моя команда предъявила полные требования, и ему пришлось в основном проектировать и кодировать его - речь шла об автоматизации сторонней платформы распознавания рукописного ввода для взаимодействия с парой наших систем.Теперь, спустя несколько месяцев после того, как заказчик назвал, на первый взгляд, незначительную проблему, но после расследования выясняется, что все приложение требует редизайна, просто чтобы исправить эту неточность (его легче реструктурировать, чем пропатчить).
Лично я не думаю, что приложение было особенно плохо спроектировано с помощью какого-либо из этих пунктов, упомянутых в этой теме , но только потому, что у нас было много маленьких неизвестных, и похоже, что сейчаснакапливается в главном недостатке дизайна - то, что мы в основном не смогли увидеть.Все эти мелкие факторы на этапе проектирования казались несущественными и игнорируемыми, поэтому мы думали, что у нас все хорошо.Теперь, когда проблема возникла, это кажется глупым, что мы не смогли обнаружить ее во время разработки, но я думаю, что мы проигнорировали некоторые «мелкие» детали и нюансы, которые в конце концов оказались существенными.
Так есть ли какой-то подходбрать, когда вы входите в стадию разработки приложения, с которым вы не слишком знакомы, но его дизайн (ложно) кажется более или менее прямым (создание таблиц, запись BO, создание пользовательского интерфейса и т. д.), чтобы вы могли увеличить свои возможностишанс предвидеть этот тип подводных камней на этапе внедрения (или, по крайней мере, до развертывания клиента)?
PS: Иногда мы нанимаем экспертов, чтобы помочь, например, математик или географ, но кто может помочь нам включить стороннюю платформу в нашу, кроме нас