Инструменты и стандарты для технического [закрытого] документа дизайна
Быстрое расширение:
extension CGRect {
init(p1: CGPoint, p2: CGPoint) {
self.init(x: min(p1.x, p2.x),
y: min(p1.y, p2.y),
width: abs(p1.x - p2.x),
height: abs(p1.y - p2.y))
}
}
4 ответа
Причина, по которой любая проектная документация заключается в четком общении со всеми участниками. Таким образом, с этой точки зрения, какие бы инструменты вы ни выбрали как архитектор, готовый продукт должен быть прочитан как сейчас всеми участниками, так и позже разработчиками. Поэтому имеет смысл выбрать хотя бы несколько довольно стандартных инструментов, которые будут использоваться через несколько лет.
Тем не менее, проектная документация обычно используется для запуска проекта или системы. После этого будет достаточно хорошо документированного кода и некоторой базовой документации. Я бы, наверное, уделил больше внимания организации вашей документации, чтобы люди могли легко найти то, что они ищут в будущем. Это может помочь обеспечить некоторую стандартную структуру / систему репозитория для хранения документации, но не обязательно настаивать на всевозможных шаблонах для документации. Сосредоточьтесь на содержании, а не на инструментах.
Это может помочь обеспечить некоторую стандартную структуру / систему репозитория для хранения документации, но не обязательно настаивать на всевозможных шаблонах для документации. Сосредоточьтесь на содержании, а не на инструментах. Это может помочь обеспечить некоторую стандартную структуру / систему репозитория для хранения документации, но не обязательно настаивать на всевозможных шаблонах для документации. Сосредоточьтесь на содержании, а не на инструментах.Тщательное обсуждение между ведущими разработчиками или членами команды (возможно, записанное для дальнейшего на мой взгляд, ценнее любого документа. Дайте им полную свободу выбора своих инструментов и попросите их только на раннем этапе написать краткое изложение технических решений высокого уровня. Это может быть основой документации позже в проекте. Технический проектный документ слишком быстро устаревает и требует слишком много времени для написания.
Дайте им полную свободу выбора своих инструментов и попросите их только на раннем этапе написать краткое изложение технических решений высокого уровня. Это может быть основой документации позже в проекте. Технический проектный документ слишком быстро устаревает и требует слишком много времени для написания. Дайте им полную свободу выбора своих инструментов и попросите их только на раннем этапе написать краткое изложение технических решений высокого уровня. Это может быть основой документации позже в проекте. Технический проектный документ слишком быстро устаревает и требует слишком много времени для написания.Я думаю, что должен быть один набор инструментов и стандартов, определяемых во время архитектуры, которые описывают, как дизайн должен быть документирован. Очень важно иметь стандарт для документирования этих вещей; в противном случае они, как правило, уходят на второй план; и если проектная документация неоднородна, существует опасность того, что люди, которым действительно нужно знать о проекте как можно больше, не смогут найти информацию о конструкции, которая им действительно нужна, когда она им действительно нужна.
Тем не менее, выбор инструментов и стандартов полностью зависит от каждой отдельной организации; все, что работает для организации, подходит им. Пока стандарты (и в некоторой степени инструменты) согласованы, все, что выбрано для отдельной организации, подходит им. Это просто нужно решить,
Если ваши проекты не являются резаком для печенья, тогда имеет смысл применять лучшую комбинацию инструментов для текущей работы. Тем не менее, некоторые нечеткие (приблизительные руководящие принципы) или узкие (применимые к конкретным обстоятельствам) стандарты, вероятно, оправданы.