Комментарии 291
Интересная статья, но на мой взгляд, применимо в основном для реализации собственных продуктов и выполнения мелких заказов. Для выполнения работ крупных заказчиков может появиться две сложности: 1) Заказчики не привыкли к такой работе и часть заказчиков потребует проект; 2) Даже если заказчик не требует проект, после утверждения прототипа следует заложить время на оформление документации, т.к. крупный не задокументированный проект через год-полтора доделать вряд-ли удастся.
1. Решаемо. Как именно не скажу с ходу, идеальной стратегии не существует.
2. Документация не нужна. Ваш код — лучшая документация. Однажды я уже пояснял почему так считаю, и могу повторить. Отсутствие документации стимулирует работников писать максимально понятный код, давать нормальные названия переменным, полям, таблицам, функциям; не сгружать в одно место тонны неразборчивого кода; не создавать неочевидных архитектур, которые требуют длительного времени для разбора их сути. Отсутствие документации вынужденно улучшает код проекта, ведь тебе, возможно, придется через пол года его переписывать или модифицировать.
2. Документация не нужна. Ваш код — лучшая документация. Однажды я уже пояснял почему так считаю, и могу повторить. Отсутствие документации стимулирует работников писать максимально понятный код, давать нормальные названия переменным, полям, таблицам, функциям; не сгружать в одно место тонны неразборчивого кода; не создавать неочевидных архитектур, которые требуют длительного времени для разбора их сути. Отсутствие документации вынужденно улучшает код проекта, ведь тебе, возможно, придется через пол года его переписывать или модифицировать.
1) Не всегда, особенно если Вы работаете с Госзаказчиком.
2) Документация нужна как минимум потому, что через полгода код переписывать будете уже не вы, а штатный программист заказчика, и вот тогда он вспомнит Вас благим матом, когда вместо того, чтобы сделать пару строк модификации кода, программист будет читать весь код и выискивать что и где находится.
2) Документация нужна как минимум потому, что через полгода код переписывать будете уже не вы, а штатный программист заказчика, и вот тогда он вспомнит Вас благим матом, когда вместо того, чтобы сделать пару строк модификации кода, программист будет читать весь код и выискивать что и где находится.
1. Работаю с Госзаказчиком. Сдельная оплата труда.
2. Не будет он ничего переписывать. Им не выгодно нанимать в штат кучу програмцов, если это быстрее можем сделать мы.
2. Не будет он ничего переписывать. Им не выгодно нанимать в штат кучу програмцов, если это быстрее можем сделать мы.
По поводу документирования — почитайте Макконнелла. Думаю, что если вы пишите, действительно очевидный и понятный код, наличие хотя бы небольшого количества комментарий сделает ваши исходники только лучше.
Плюс, иногда (вообще не иногда, а довольно часто), разработчик за полгода может участвовать в разработке очень большого количества проектов, и, когда придёт время перерабатывать исходный продукт, разработчик сам может забыть некоторые (или большинство?) аспектов работы программы. Так что комментарии нужны не только сторонним разработчикам, которые дорабатывают продукт, но и тому, кто писал исходный код.
Ещё вы пишите о том, что через полгода, продукт будет дорабатывать тот же человек, который его писал изначально, но вы не рассматриваете ситуацию, когда заказчик решит сменить разработчика и у новой компании будет куча поводов вспомнить добрым словцом первого разработчика и «поблагодарить» его за отсутствие какой-либо документации.
Плюс, иногда (вообще не иногда, а довольно часто), разработчик за полгода может участвовать в разработке очень большого количества проектов, и, когда придёт время перерабатывать исходный продукт, разработчик сам может забыть некоторые (или большинство?) аспектов работы программы. Так что комментарии нужны не только сторонним разработчикам, которые дорабатывают продукт, но и тому, кто писал исходный код.
Ещё вы пишите о том, что через полгода, продукт будет дорабатывать тот же человек, который его писал изначально, но вы не рассматриваете ситуацию, когда заказчик решит сменить разработчика и у новой компании будет куча поводов вспомнить добрым словцом первого разработчика и «поблагодарить» его за отсутствие какой-либо документации.
НЛО прилетело и опубликовало эту надпись здесь
Как жаль, что я не могу показать вам наши исходники. Там нечего комментировать. Комментарии были бы смешны
Дело не в комментариях к исходникам, я уверен у Вас исходный код на высоте.
Красивость и понятность исходного кода не стоит и ломанного гроша, если архитектура трещит по швам, объектная модель не до конца верно отображает суровую действительность, проект зависит от одного-двух таллантливых программистов, которые могут в любой момент уйти на другую работу.
Красивость и понятность исходного кода не стоит и ломанного гроша, если архитектура трещит по швам, объектная модель не до конца верно отображает суровую действительность, проект зависит от одного-двух таллантливых программистов, которые могут в любой момент уйти на другую работу.
Архитектура даже самого крутого проекта имеет кучу проблем. Даже с комментариями в коде и предварительным долгим проектированием.
О чем вы говорите? О проекте в 100 строк? А если у вас >300 классов хотя бы? Вы представляете сколько времени надо чтобы разобраться что с чем и как взаимодействует?
Попробуйте показать эти исходники 2-3 знакомым разработчикам и попросить их с ходу назвать назначение каждой функции и каждого класса.
Вы не поверите, все сходу ответят на все вопросы.
Значит присутствующим здесь остается только позавидовать таланту Вашей команды в написании программ, хотя, создается впечатление что Вы просто рьяно и упорно отстаиваете свою модель работы, даже не вникая в проблематику.
Аналогичное можно сказать про комментирующих тут. Никто не хочет видеть что-то за пределами своего теплого и уютного мирка.
Замечание.
Теплого и уютного мирка, который прекрасно функционирует в серьезных проектах и не приводит к провалу. Потому, чтобы разглядеть прелести Вашего мирка — задаем Вам компрометирующие вопросы (для того чтобы сравнить и в сравнении выудить полезные принципы), которые вы воспринимаете как непринятие Вашей теории. В результате — вы считаете, что Вашу гениальность никто не хочет видеть и что все вокруг тупые скупердяи, неспособные тонко чувствовать всей прелести разработки проектов.
Теплого и уютного мирка, который прекрасно функционирует в серьезных проектах и не приводит к провалу. Потому, чтобы разглядеть прелести Вашего мирка — задаем Вам компрометирующие вопросы (для того чтобы сравнить и в сравнении выудить полезные принципы), которые вы воспринимаете как непринятие Вашей теории. В результате — вы считаете, что Вашу гениальность никто не хочет видеть и что все вокруг тупые скупердяи, неспособные тонко чувствовать всей прелести разработки проектов.
Не могу говорить за других, но могу сказать за себя, что мне приходилось и приходится работать с чужим кодом без каких-либо комментариев. И, вне зависимости, от понятности именования методов и переменных, а так же чистоты кода, мне ещё не встречался проект, в котором комментарии были бы лишними и мешали бы работе с проектом.
Плюс, уже несколько раз в комментариях упоминали Макконнела и его «Совершенный код», в этой книге есть глава, в которой рассказывается о «споре» между несколькими типами разработчиков. На мой взгляд, там доходчиво рассказано о том, почему комментировать нужно, но так же, нужно знать меру в этом.
Плюс, уже несколько раз в комментариях упоминали Макконнела и его «Совершенный код», в этой книге есть глава, в которой рассказывается о «споре» между несколькими типами разработчиков. На мой взгляд, там доходчиво рассказано о том, почему комментировать нужно, но так же, нужно знать меру в этом.
комментарии это хорошо
мне кажется тут говорили, что документация это плохо…
мне кажется тут говорили, что документация это плохо…
«Как жаль, что я не могу показать вам наши исходники. Там нечего комментировать. Комментарии были бы смешны»
Это цитата автора поста. Вот ссылка на комментарий: habrahabr.ru/blogs/pm/107655/#comment_3398536
Кстати, не знаю, как в других языках программирования, но в AS3 есть такая клёвая штука, как ASDoc — это такие комментарии, на основе которых можно генерировать документацию. Иногда, комментирование == документирование.
Это цитата автора поста. Вот ссылка на комментарий: habrahabr.ru/blogs/pm/107655/#comment_3398536
Кстати, не знаю, как в других языках программирования, но в AS3 есть такая клёвая штука, как ASDoc — это такие комментарии, на основе которых можно генерировать документацию. Иногда, комментирование == документирование.
ну и в java есть javadoc
но иногда комментарии к методам особенно сообразительные программисты создают по такой схеме
/**
* Set number of evil
*/
public setNumberOfEvil(double numberOfEvil)
согласитесь, бред? :)
но иногда комментарии к методам особенно сообразительные программисты создают по такой схеме
/**
* Set number of evil
*/
public setNumberOfEvil(double numberOfEvil)
согласитесь, бред? :)
Для себя, я понимаю, что, наверно, тут комментарий излишен, но я бы тоже написал комментарий даже к такому простому методу. Мне кажется, что постоянство — это хорошо, и если для других методов комментарии пишутся, то чем этот хуже =)
Так иогда делают, чтобы успокоить какую-нибудь систему контроля кода. Особенно, когда руководство свято верит в циферки метрик.
Вы правы, не поверю.
Разве что в ваших проектах < 10 классов каждый из которых состоит из < 10 методов.
Разве что в ваших проектах < 10 классов каждый из которых состоит из < 10 методов.
У вас ООП головного мозга. Все, даже самые сложные вещи, можно описать простыми методами.
Скажите, а что означает «ООП головного мозга»?
Вы все задачи решаете при помощи ООП, и если что-то не укладывается в ваше мировозрение, то вы приводите все к ООП, и решаете задачу привычным образом.
Я работаю Flash разработчиком, и AS3 является ООП языком, поэтому действительно, изъясняюсь в терминах ООП. Не знаю, как в вашей работе, но в Flash не применяя классы и ООП можно написать только маленькую и/или очень запутанное приложение.
Кстати, я не могу понять, как это относится к тому, что вы против комментариев к коду, а я за них.
Кстати, я не могу понять, как это относится к тому, что вы против комментариев к коду, а я за них.
Писал на AS2 флеш-игру. Можно применять ООП, а можно пользоваться событийной моделью кейфреймов. Сама архитектура Flash вносит свои изменения в процесс разработки.
Если ваш проект заканчивается на Flash'е, то это одно, а если флеш выступает в роли интерфейсного решения некого программного комплекса, то это уже другое.
Если ваш проект заканчивается на Flash'е, то это одно, а если флеш выступает в роли интерфейсного решения некого программного комплекса, то это уже другое.
В AS2 многие вещи считались «нормальными» и разработчики с небольшим опытом часто ими пользовались. В частности, многими считалось, что писать код, разбросанный во-многих кадрах — это нормально, но с опытом все более-менее серьёзные разработчики приходили к тому, что код лучше писать в 1 кадре или, что более правильно, использовать ООП и работать с внешними классами, это было доступно уже в AS2.
В AS3 тоже можно писать в кадрах, но так уже почти никто не делает, так как всем понятно, что если ты создаёшь нечто, отличное от баннера, код в кадрах не приведёт ни к чему хорошему.
Если я правильно вас понял, то вы писали код исключительно в кадрах («событийная модель кейфреймов»), поэтому, скорее всего, у вас либо был очень простой проект, либо вы не обладали достаточными знаниями в Flash-разработках, чтобы использовать ООП.
«Если ваш проект заканчивается на Flash'е, то это одно, а если флеш выступает в роли интерфейсного решения некого программного комплекса, то это уже другое.»
Как это влияет на использование ООП в Flash-проектах?
В AS3 тоже можно писать в кадрах, но так уже почти никто не делает, так как всем понятно, что если ты создаёшь нечто, отличное от баннера, код в кадрах не приведёт ни к чему хорошему.
Если я правильно вас понял, то вы писали код исключительно в кадрах («событийная модель кейфреймов»), поэтому, скорее всего, у вас либо был очень простой проект, либо вы не обладали достаточными знаниями в Flash-разработках, чтобы использовать ООП.
«Если ваш проект заканчивается на Flash'е, то это одно, а если флеш выступает в роли интерфейсного решения некого программного комплекса, то это уже другое.»
Как это влияет на использование ООП в Flash-проектах?
Когда-то Flash был средством легкого создания анимированных роликов, делался для художников и предлагал небольшие бонусы вроде скриптов к кадрах. Если за него возьмется художник, то он будет оперировать понятными ему терминами — есть кард, в нем нужно действие — пишем код для кадра.
Никто не спорит, что человек будет пытаться разрабатывать продукт так, как он умеет это делать. Но это никак не повлияет на то, что писать код в классах более правильно и профессионально.
И я ещё раз не могу понять, почему тема ушла в сторону Flash, если изначально разговор был о том, что автор поста против комментирования и проектирования, а моя точка зрения не совпадает с его точкой зрения.
И я ещё раз не могу понять, почему тема ушла в сторону Flash, если изначально разговор был о том, что автор поста против комментирования и проектирования, а моя точка зрения не совпадает с его точкой зрения.
Flash просто к слову пришелся :)
Я хотел сказать, что не всегда стоит оценивать «профессиональность» использования чего-либо (технологии Flash в данном случае) с одной точки зрения. Конечный потребитель может найти собственную, удобную для него, модель применения.
Я хотел сказать, что не всегда стоит оценивать «профессиональность» использования чего-либо (технологии Flash в данном случае) с одной точки зрения. Конечный потребитель может найти собственную, удобную для него, модель применения.
Профессионализм в данном случае — это знание того, что ты можешь сделать с инструментом (в данном случае Flash) и способность выбрать удобный способ реализации задуманного. В случае с дизайнерами — они, в большинстве своём, просто не знают как работать с классами и, поэтому, пишут код в кадрах.
Ещё, профессионализм тут можно оценивать с точки зрения «повторного использования» исходников, как со всем этим будет удобно работать другим разработчикам и т.п. В случае создания более-менее серьёзной программы через написание кода в кадрах — об удобстве повторного использования и внесении модификаций можно забыть.
Ещё, профессионализм тут можно оценивать с точки зрения «повторного использования» исходников, как со всем этим будет удобно работать другим разработчикам и т.п. В случае создания более-менее серьёзной программы через написание кода в кадрах — об удобстве повторного использования и внесении модификаций можно забыть.
Да дизайнерам просто пофиг на классы. Они могут реализовать задуманное вообще не используя ООП. И все что вы только что описали не относится к ООП, это одинаково применимо к различным способам разработки.
Если честно, я не очень понимаю суть нашего спора.
Если вы мне всё ещё пытаетесь доказать, что создание более-менее серьёзной программы в Flash через написание кода в кадрах — это нормальная практика, то, на мой взгляд, вы не правы. Если вы действительно так считаете, то это, скорее всего, из-за недостаточного количества знаний в области Flash-разработок.
Так уж случилось, что использование ООП и отказ от написания кода в кадрах — это 2 взаимосвязанных понятия (так как не желая писать код в кадрах будет необходимость писать его во внешних классах, с которыми без ООП работать нельзя). Из-за этого, если оценивать профессионализм с точки зрения удобства повторного использования исходников, можно сказать, что люди, которые пишут более-менее серьёзные программы в кадрах — непрофессиональны, так как использовать их исходники и модифицировать их достаточно трудоёмко и напряжно.
Ещё раз повторюсь, что всё это не относится к баннерам и анимации, но относится к более серьёзным программам.
Если вы мне всё ещё пытаетесь доказать, что создание более-менее серьёзной программы в Flash через написание кода в кадрах — это нормальная практика, то, на мой взгляд, вы не правы. Если вы действительно так считаете, то это, скорее всего, из-за недостаточного количества знаний в области Flash-разработок.
Так уж случилось, что использование ООП и отказ от написания кода в кадрах — это 2 взаимосвязанных понятия (так как не желая писать код в кадрах будет необходимость писать его во внешних классах, с которыми без ООП работать нельзя). Из-за этого, если оценивать профессионализм с точки зрения удобства повторного использования исходников, можно сказать, что люди, которые пишут более-менее серьёзные программы в кадрах — непрофессиональны, так как использовать их исходники и модифицировать их достаточно трудоёмко и напряжно.
Ещё раз повторюсь, что всё это не относится к баннерам и анимации, но относится к более серьёзным программам.
Если у вас много анимации, и некоторые действия нужно делать только по окончанию анимации некого мувиклипа, то работа с кадрами упрощает модификацию кода в разы. Иначе вы будете делать двойную работу, сначала анимировать, а потом получившийся результат переводить в AS.
То, что вы описали — это чуть-ли не единственное, для чего может понадобиться продолжать писать код в кадрах и для AS3. К слову, за последний год мне приходилось прибегать к этому раз 5-10, думаю, не больше.
Кстати, есть и другие способы отследить окончание анимации, если программист хочет полностью избежать написание кода в кадрах.
Кстати, есть и другие способы отследить окончание анимации, если программист хочет полностью избежать написание кода в кадрах.
2. А вы что, вечные?
Нет ничего вечного.
Рукописи не горят! (с)
Это к тому, что документация будет жить дольше, чем команда разработчиков работать с проектом.
Это к тому, что документация будет жить дольше, чем команда разработчиков работать с проектом.
Самая точная документация содержится в коде.
Вот после таких реплик хочется вспомнить АСМ… там тоже по коду надо разбираться? Или ваша теория сразу обрастает кучей ЕСЛИ-ТО?
Вспомните может вообще времена, когда писали сразу машинными кодами.
Что значит вспомнить времена? По вашему мнению сейчас на ассемблере не программируют?
Вы сильно ошибаетесь.
Вы сильно ошибаетесь.
Программируют. Но покажите даже самый хорошо написанный ASM код с лучшими комментариями человеку, который видел только PHP, и он будет смотреть на него как баран на новые ворота. Это я к тому, что в каждой предметной области для работы нужно обладать неким набором обязательных знаний для понимания кода.
Когда я учился ассемлеру в универе — я его не знал.
И, если честно, несмотря на то, что втирал мне преподаватель, пока я не посидел над исходником с комментариями (в обратном случае рядом была книжка по асму) я не смог нормально сделать лабораторные работы на нем. И вы мне говорите про нормальность отсутствие документации?
И неужели к вам в компанию приходят только гуру знатоки PHP (к примеру)? и они досконально знают все фишки и особые приемы, которые работают быстрее, но понимаются сложнее? и способны сразу отловить извороты с несколькими классами и объектами?
И, если честно, несмотря на то, что втирал мне преподаватель, пока я не посидел над исходником с комментариями (в обратном случае рядом была книжка по асму) я не смог нормально сделать лабораторные работы на нем. И вы мне говорите про нормальность отсутствие документации?
И неужели к вам в компанию приходят только гуру знатоки PHP (к примеру)? и они досконально знают все фишки и особые приемы, которые работают быстрее, но понимаются сложнее? и способны сразу отловить извороты с несколькими классами и объектами?
1 «Документация не нужна»
Так давайте удалим MSDN! Он наверное никому не нужен, да?
Вы слишком категоричны.
2 «Отсутствие документации стимулирует работников писать максимально понятный код»
Да ну! отсутствие документации стимулирует разработчиков проводить часы/дни/недели в попытках понять чужой код.
3 «ведь тебе, возможно, придется через пол года его переписывать»
А возможно придется переписывать чужой код, который его автор считал идеальным
4 «не создавать неочевидных архитектур»
Чтобы архитектура стала легкой для понимания надо: и код и документация. Если хотя бы одного компонента нет — нихрена не очевидно.
Сравните:
#define TRUE FALSE
и
#define TRUE FALSE //счастливой отладки суки!
Вывод:
Только наличие и кода и комментария делает ситуацию очевидной.
Так давайте удалим MSDN! Он наверное никому не нужен, да?
Вы слишком категоричны.
2 «Отсутствие документации стимулирует работников писать максимально понятный код»
Да ну! отсутствие документации стимулирует разработчиков проводить часы/дни/недели в попытках понять чужой код.
3 «ведь тебе, возможно, придется через пол года его переписывать»
А возможно придется переписывать чужой код, который его автор считал идеальным
4 «не создавать неочевидных архитектур»
Чтобы архитектура стала легкой для понимания надо: и код и документация. Если хотя бы одного компонента нет — нихрена не очевидно.
Сравните:
#define TRUE FALSE
и
#define TRUE FALSE //счастливой отладки суки!
Вывод:
Только наличие и кода и комментария делает ситуацию очевидной.
Я не слишком категоричен. Вы просто не понимаете, что я хочу вам донести. Это пройдет :)
Будьте более конструктивны:
1 Люди не понимают, то что я хочу им донести
2 Они начнут понимать меня, как только я научусь доносить им то, что хочу
3 Мне нужно стараться излагать свою мысль более ясно, и четко аргументировать свою позицию
4 Я не буду встречать каждый комментарий в штыки, а задамся вопросом, почему у читателя сложилось такое мнение. Я хотел другого понимания ситуации, что я сделал не так?
5 PROFIT
Или создайте опрос на хабре:
1 Документация кода важна
2 Документация кода не важна
3 Документация кода не важна, вы просто не знаете почему.
Вы будете удивлены ответами.
1 Люди не понимают, то что я хочу им донести
2 Они начнут понимать меня, как только я научусь доносить им то, что хочу
3 Мне нужно стараться излагать свою мысль более ясно, и четко аргументировать свою позицию
4 Я не буду встречать каждый комментарий в штыки, а задамся вопросом, почему у читателя сложилось такое мнение. Я хотел другого понимания ситуации, что я сделал не так?
5 PROFIT
Или создайте опрос на хабре:
1 Документация кода важна
2 Документация кода не важна
3 Документация кода не важна, вы просто не знаете почему.
Вы будете удивлены ответами.
Прикольная логика.
Если люди не понимают, то что вы пытаетесь донести до них русским языком в комментариях, то я сильно сомневаюсь, что ваш «понятный код» расскажет что-то полезное любому кроме вас и вашей команды. Команда же его понимает, так как она — «команда». Все со временем привыкают к нюансам работы, реализации, стилю и т.д.
Вы пробовали работать в проектах, части которых передаются из отдела в отдел?
Что вообще будет с остальными людьми (не программистами):
Как конечный пользователь узнает все возможности программы?
Отдел Web Operations должен откуда-то узнать, как установить программу, настроить, какие параметры менять в случае изменения нагрузки?
Как отдел QA узнает, что хотел заказчик? Требования — это тоже документация. Еще в этом отделе нужна документация на ту же конфигурацию системы.
Как главный архитектор может составить и поддерживать целостную картину системы со всеми взаимодействиями между компонентами?
Если вы работаете в крупной компании с мало-мальски налаженными процессами, то вы в любом случае столкнетесь с большей частью перечисленных проблем. И все они решаются вовремя написанной документацией.
Если люди не понимают, то что вы пытаетесь донести до них русским языком в комментариях, то я сильно сомневаюсь, что ваш «понятный код» расскажет что-то полезное любому кроме вас и вашей команды. Команда же его понимает, так как она — «команда». Все со временем привыкают к нюансам работы, реализации, стилю и т.д.
Вы пробовали работать в проектах, части которых передаются из отдела в отдел?
Что вообще будет с остальными людьми (не программистами):
Как конечный пользователь узнает все возможности программы?
Отдел Web Operations должен откуда-то узнать, как установить программу, настроить, какие параметры менять в случае изменения нагрузки?
Как отдел QA узнает, что хотел заказчик? Требования — это тоже документация. Еще в этом отделе нужна документация на ту же конфигурацию системы.
Как главный архитектор может составить и поддерживать целостную картину системы со всеми взаимодействиями между компонентами?
Если вы работаете в крупной компании с мало-мальски налаженными процессами, то вы в любом случае столкнетесь с большей частью перечисленных проблем. И все они решаются вовремя написанной документацией.
«Документация не нужна. Ваш код — лучшая документация» — это сверическая ситуация в вакууме. В реальности же есть, во-первых, недобросовестные разработчики, которые считают, что лучше, извините, нах*ячить, чем выискать хорошую, самодокументирующую структуру кода и данных. Во-вторых, в любой системе со временем появляются различные неочевидные вещи, которые просто обязаны быть документированны. Ибо смотришь, например, на некоторый алгоритм расчёта, и думаешь — like, WTF? O_O
Гнать в шею таких недобросовестных.
Опять какие-то сферические кони в вакууме. Это называется musturbation — говорить о том, какой ситуация должна быть, игнорируя реальность. Кто выгонит человека, если он делает свою работу — пусть и не так хорошо, как мог бы сделать специалист высокого класса? Заметьте, я говорю о больших конторах, а не о мелких, где человека могут запросто пнуть на мороз и всё.
Я вам рассказываю как уже есть в нашей компании. И это реально работает. А вы про каких-то коней…
а что плохого в том, чтобы стремится к сферической цели? ) реальность не константа, её спокойно можно менять под себя. не выгонять «недобросовестных разработчиков, которые считают, что лучше, извините, нах*ячить, чем выискать хорошую, самодокументирующую структуру кода и данных» это прогиб под обстоятельства и показывает беспомощность в решении рабочих проблем
Документация нужна, хотя бы потому что если это крупный проект, состоящий из десятка, а то и больше модулей, то я сочувствую разработчику, который придет в проект через год после старта и постарается со всем этим разобраться, только «глядя на шикарный код».
Документация нужна как минимум на примитивном уровне:
1. какая общая архитектура (какие логические и физические слои, какие технологие)
2. какие модули за что отвечают и как взаимодействуют
3. как разнесена бизнес-логика по слоям.
На начальном этапе этой доки будет достаточно, а дальше можно писать больше, а можно и оставить так.
Документация нужна как минимум на примитивном уровне:
1. какая общая архитектура (какие логические и физические слои, какие технологие)
2. какие модули за что отвечают и как взаимодействуют
3. как разнесена бизнес-логика по слоям.
На начальном этапе этой доки будет достаточно, а дальше можно писать больше, а можно и оставить так.
Я рассказываю это в течение пары часов.
Сколько модулей у Вас в проекте? Большая база данных?
Не считал. База на сотни гигабайт.
Я видел базы на сотни гигабайт (заносилось по одной записи каждую миллисекунду)… и там проблемы не с моделью предметной области, а с оптимизацией, ибо надо как-то эти сотни гагабайт туда писать, а потмо оттуда считывать.
Под размером базы я понимал не количество метров, а количество сущностей предметной области, которые отражает база данных.
Плохо что Вы не считали модули, тем более что можете за пару часов это все рассказать. А представьте ситуацию — Вам предлагают отличное место работы, от которого нельзя отказаться, и Вы уходите из проекта. Как после Вас будет развиваться проект? Кто будет за пару часов рассказывать новичкам архитектуру? Да и Вам разве не жалко своего времени на эти рассказы?
Под размером базы я понимал не количество метров, а количество сущностей предметной области, которые отражает база данных.
Плохо что Вы не считали модули, тем более что можете за пару часов это все рассказать. А представьте ситуацию — Вам предлагают отличное место работы, от которого нельзя отказаться, и Вы уходите из проекта. Как после Вас будет развиваться проект? Кто будет за пару часов рассказывать новичкам архитектуру? Да и Вам разве не жалко своего времени на эти рассказы?
Любой из нашей команды сможет многое рассказать про архитектуру проекта. Потому что все знают зачем это писалось, почему было принято данное решение и какие подводные камни были.
Коллектив обладает знаниями, а не один человек.
Коллектив обладает знаниями, а не один человек.
значит ваш подход уже сразу имеет БОЛЬШОЕ узкое место.
как уже было упомянуто выше — Взамен того, чтобы писать систему — они должны будут объяснять новобранцу, а как этот тут все работает. Согласитесь — если бы была документация — можно было пнуть на нее, а потом уже в кулуарах обсудить что не понятно.
Кстати, а вы не пробовали излагать свои мысли в комментах. а потом генерировать из этого сопроводительную документацию по коду? или это тоже не эффективно?
и еще… Я пойму что ВСЕ знают о проекте ВСЕ. если проект маленький. Если он ппц огромный — вы еще устраиваете вечерние сходки для обсуждения сделанного? Если так — я к вам ни за какие деньги. Мне как-то с семьей вечерами приятнее сидеть.
как уже было упомянуто выше — Взамен того, чтобы писать систему — они должны будут объяснять новобранцу, а как этот тут все работает. Согласитесь — если бы была документация — можно было пнуть на нее, а потом уже в кулуарах обсудить что не понятно.
Кстати, а вы не пробовали излагать свои мысли в комментах. а потом генерировать из этого сопроводительную документацию по коду? или это тоже не эффективно?
и еще… Я пойму что ВСЕ знают о проекте ВСЕ. если проект маленький. Если он ппц огромный — вы еще устраиваете вечерние сходки для обсуждения сделанного? Если так — я к вам ни за какие деньги. Мне как-то с семьей вечерами приятнее сидеть.
Большое говорите? Я лучше его посажу рядом с опытным работником в пару, и он за один день научится большему, чем за недельное штудирование документации.
Спасибо Денису М., это работает чудесно!
Спасибо Денису М., это работает чудесно!
Простите, а как вы управляете рискам проектов? или у вас этой задачи нет?
Риски минимальные.
Спасибо за ответ. Вы вновь гнете свою линию.
habrahabr.ru/blogs/pm/107655/#comment_3398570
Вам PMBOK, к примеру, подарить?
habrahabr.ru/blogs/pm/107655/#comment_3398570
Вам PMBOK, к примеру, подарить?
Да, я гну свою линию, так как у меня есть реальные цифры за спиной.
Вы же не интересуетесь, что у нас за проект, как он построен, а опираетесь сугубо на свой опыт. Вы знаете все свои проблемы, и считаете, что у всех остальных обязательно должны быть аналогичные проблемы. Вы хотите поговорить про риски? Добро пожаловать в скайп, обязательно с вами обсужу, мало того, могу даже показать одним глазком на проект, который мы сейчас делаем параллельно.
Вы же не интересуетесь, что у нас за проект, как он построен, а опираетесь сугубо на свой опыт. Вы знаете все свои проблемы, и считаете, что у всех остальных обязательно должны быть аналогичные проблемы. Вы хотите поговорить про риски? Добро пожаловать в скайп, обязательно с вами обсужу, мало того, могу даже показать одним глазком на проект, который мы сейчас делаем параллельно.
Объем данных и структура — разные вещи.
Знаю. Спрашивали про размер базы данных, я ответил.
суть вопроса была очевидна.
Вы опять попытались очевидное вывернуть наизнанку и предложить свою трактовку, отобразив «особое» мировоззрение.
Вы опять попытались очевидное вывернуть наизнанку и предложить свою трактовку, отобразив «особое» мировоззрение.
Ну вы сейчас отвечаете как настоящий программист (математик) из анекдота «очевидно что вы в гондоле, сэры!».
Размер базы — это не только количество данных в байтах, но и количество отбражаемых объектов предметной области. Вы выбрали удобный для Вас ответ. Что ж, это правильно =)
Так сколько же все-таки в Вашей большой базе представлено сущнойстей предметной области? Ч не прошу говорить точно «439» — хотя бы примерно, больше сотни?
Размер базы — это не только количество данных в байтах, но и количество отбражаемых объектов предметной области. Вы выбрали удобный для Вас ответ. Что ж, это правильно =)
Так сколько же все-таки в Вашей большой базе представлено сущнойстей предметной области? Ч не прошу говорить точно «439» — хотя бы примерно, больше сотни?
Если вы не против, я конкретизирую вопрос (мне тоже жутко интересно)
1) Сколько таблиц
2) Сколько связей
3) Сколько триггеров
4) Сколько хранимых процедур
1) Сколько таблиц
2) Сколько связей
3) Сколько триггеров
4) Сколько хранимых процедур
И все-таки, хотя бы примерное число модулей в системе.
Точно более 30, но точнее смогу сказать позже.
Хм, а открыть документ «описание программы» (это если документация ведется по ГОСТ) и там посмотреть в соответствующем разделе — 30 секнуд :)
А какая цель? Что дает знание количества модулей? Продукт должен работать, а сколько в нем модулей — неважно.
Цель простая — быстрое восстановление знаний. Продукт сдали заказчику и положили на полку. А через год понадобилось даже не модифицировать, а просто заново развернуть. Или захотели вынуть кусок и повторно применить.
Что делать? Как ставить? Какие требования к железу? Какие модули должны быть в ОС и как потом это все удалить? Какое возможно влияние на сторонние продукты?
Если с документацией все Ок, то с полки снимается документация и читается. При грамотно написанных аннотациях и оглавлениях поиск данных занимает минуты, а не дни анализа кода.
Что делать? Как ставить? Какие требования к железу? Какие модули должны быть в ОС и как потом это все удалить? Какое возможно влияние на сторонние продукты?
Если с документацией все Ок, то с полки снимается документация и читается. При грамотно написанных аннотациях и оглавлениях поиск данных занимает минуты, а не дни анализа кода.
Я не отвечу сейчас на ваши вопросы, для этого мне нужна помощь друга.
А как же «рассказать за два часа»?
Основы логики и их реализация — разные вещи. Приведу вполне конкретный пример.
Основы логики — автомобилем можно управлять при помощи различных органов человека. Но это не значит, что обязательно должны присутствовать три педали, пара рычагов и руль. Можно управлять силой мысли, можно управлять джойстиком, или двумя рычагами. Это уже конкретные реализации. Но базис управления можно рассказать за пару минут: посылается сигнал системе управления автомобиля, на который она реагирует соответствующим образом. Интерфейс взаимодействия может быть механическим, может быть физическим.
Основы логики — автомобилем можно управлять при помощи различных органов человека. Но это не значит, что обязательно должны присутствовать три педали, пара рычагов и руль. Можно управлять силой мысли, можно управлять джойстиком, или двумя рычагами. Это уже конкретные реализации. Но базис управления можно рассказать за пару минут: посылается сигнал системе управления автомобиля, на который она реагирует соответствующим образом. Интерфейс взаимодействия может быть механическим, может быть физическим.
Не совсем понял как пример относится к моему вопросу, поясните пожалуйста.
Но по поводу этого примера: как раз автомобиль сначала проектируют долго и даже очень долго, потом делают прототип, потом делают пробную модель, ее обкатывают, вносят изменения и только потом запускают в серию.
Представьте сколько потребовалось бы вложить денег в изменения, елисбы вы сделали прототип спорт-купе, а вам заказчик сказал бы «замечательно, а давайте теперь перевезем мне холодильник на дачу»
Но по поводу этого примера: как раз автомобиль сначала проектируют долго и даже очень долго, потом делают прототип, потом делают пробную модель, ее обкатывают, вносят изменения и только потом запускают в серию.
Представьте сколько потребовалось бы вложить денег в изменения, елисбы вы сделали прототип спорт-купе, а вам заказчик сказал бы «замечательно, а давайте теперь перевезем мне холодильник на дачу»
А что, документация только для программистов пишется? Как тестер будет проверять ваши поделки? Откуда возьмется информация о том, как это должно работать на самом деле?
Разговор в курилке:
— Вась, Вась, твой код тесты не проходит!
— Где?
— Строка 15397 файл wtf.cs
— Что скармливаешь?
— Число…
— У нас теперь там строки. Чисел быть не может. Проверка в 1258 строке файла ckeck.cs.
— А сказать слабо было? Я отдельно библиотеку прогонял.
— Вот и дурак. Одно без другого в системе не будет в будущем работать… Все нормально, там попозже допишется.
— А-а-а-а. понял. Спасибо.
— Вась, Вась, твой код тесты не проходит!
— Где?
— Строка 15397 файл wtf.cs
— Что скармливаешь?
— Число…
— У нас теперь там строки. Чисел быть не может. Проверка в 1258 строке файла ckeck.cs.
— А сказать слабо было? Я отдельно библиотеку прогонял.
— Вот и дурак. Одно без другого в системе не будет в будущем работать… Все нормально, там попозже допишется.
— А-а-а-а. понял. Спасибо.
Мое мнение докуменатция это миф. В 80% заказчик явно не хотел за нее платить и в 20% платил но никогда не читал.
Help, Хорошо структурированный, однообразный и код, тренинги в команде etc работают а вот дока по архитектуре не работает. Я готов порассуждать почему но факт остается фактом.
Help, Хорошо структурированный, однообразный и код, тренинги в команде etc работают а вот дока по архитектуре не работает. Я готов порассуждать почему но факт остается фактом.
Вы как-то смешиваете заказчика и документацию по архитектуре. Интересно было бы услышать Ваши аргументы, почему документация по архитектуре не работает?
Блин я тут с женой и дочкой в магазин собираюсь — если сейчас буду отвечать, мне расстреляют за разбазаривание времени. Могу вечером вернуться и написать статью — почему не работает дока по архитектуре.
BTW сейчас медленно выползаю из текущего проекта — заказчик просит написать как оно все устроено (пост фактум что характерно), пишу порциями — но эффект небольшой
BTW сейчас медленно выползаю из текущего проекта — заказчик просит написать как оно все устроено (пост фактум что характерно), пишу порциями — но эффект небольшой
Вот такие высказывания меня всегда прикалывали. У вас идеальная память? Вы всегда помните ньюансы всех ваших проектов? Или вы всю жизнь работаете в одном проекте и поэтому все про него знаете? Как доки могут не работать? Вот пример из моей практики:
— более 200 классов
— куча таблиц в базе
— мне надо дописать всего одну проводку в код.
— разработчик (нанятая команда) уже давно сдали проект и занимаются другими.
Вы вообще себе представляете сколько надо времени чтобы разобраться что и как взаимодействует в этом проекте? Судя по вашему высказыванию нет. А взяв доку я за пару часв разобрался в структуре и сделал что от меня требовалось.
Документация это в первую очередь выжимка с информацией о проекте. Если она грамотно сделана, то она не может не работать. Другое дело, что она работает не всегда. Это как бекап, все его делают (ну почти все :) ), но реальная польза от него не у всех. Т.к. банально проблемы не постоянно возникают. Но уж если проблема возникла, то есть «парашут».
То же самое и с документацией. Пока вы работаете и в курсе дел, то от документации мало толку. Но вот если, не дай бог, вы решите перейти на другое место работы или по другим причинам вы не сможете передать свой опыт другому программисту… то вот здесь у заказчика будет большая жопа.
Поищите в инете. Есть куча примеров когда главного разработчика например сбивала машина (тьфу, тьфу, тьфу) и проект разваливался сразу… В общем доки это как страховка…
Вы руководили крупными проектами? Тогда представьте себе, что вы как всегда не ведеди доки и пара-тройка ваших лучших программеров уехали работать в тайланд… им предложили ЗП в 4 раза больше вашей и они просто взяли и свалили туда… просто утром не вышли на работу… Волосы на голове еще не зашевилились? Тогда у вас еще очень мало опыта… удачи вам в ваших начинаниях.
— более 200 классов
— куча таблиц в базе
— мне надо дописать всего одну проводку в код.
— разработчик (нанятая команда) уже давно сдали проект и занимаются другими.
Вы вообще себе представляете сколько надо времени чтобы разобраться что и как взаимодействует в этом проекте? Судя по вашему высказыванию нет. А взяв доку я за пару часв разобрался в структуре и сделал что от меня требовалось.
Документация это в первую очередь выжимка с информацией о проекте. Если она грамотно сделана, то она не может не работать. Другое дело, что она работает не всегда. Это как бекап, все его делают (ну почти все :) ), но реальная польза от него не у всех. Т.к. банально проблемы не постоянно возникают. Но уж если проблема возникла, то есть «парашут».
То же самое и с документацией. Пока вы работаете и в курсе дел, то от документации мало толку. Но вот если, не дай бог, вы решите перейти на другое место работы или по другим причинам вы не сможете передать свой опыт другому программисту… то вот здесь у заказчика будет большая жопа.
Поищите в инете. Есть куча примеров когда главного разработчика например сбивала машина (тьфу, тьфу, тьфу) и проект разваливался сразу… В общем доки это как страховка…
Вы руководили крупными проектами? Тогда представьте себе, что вы как всегда не ведеди доки и пара-тройка ваших лучших программеров уехали работать в тайланд… им предложили ЗП в 4 раза больше вашей и они просто взяли и свалили туда… просто утром не вышли на работу… Волосы на голове еще не зашевилились? Тогда у вас еще очень мало опыта… удачи вам в ваших начинаниях.
Ваша статья хороша, но слишком много исключений ее опровергающих. Вам нужно было описать в каких ситуациях прототипирование выигрывает у проектирования. А в каких — нет.
Представьте, что Microsoft пишет новую ОС. Зачем тут прототип?
Но, при этом, старую ОС вполне можно считать прототипом существующей.
С учетом этого, Вашу мысль можно выразить фразой «Приступая к проектированию, убедись что у тебя есть рабочий прототип.»
Представьте, что Microsoft пишет новую ОС. Зачем тут прототип?
Но, при этом, старую ОС вполне можно считать прототипом существующей.
С учетом этого, Вашу мысль можно выразить фразой «Приступая к проектированию, убедись что у тебя есть рабочий прототип.»
У вас внутренняя автоматизация. Для таких вещей по моему опыту длинные циклы разработки мало полезны.
Стив Макконнелл «Совершенный код». Читаем и понимаем, что проектирование важно, очень важно. Хотя бы потому, что исправление ошибок на этапе проектирования обходится гораздо дешевле, нежели на этапе конструирования или тестирования.
Очень важно, но тратить на него гигантские временные ресурсы совершенно не обязательно. Доказано личным опытом.
А никто и не говорит про гигантские ресурсы. Просто в вашем случае вы можете позволить себе работать без четкой архитектуры. А бывают ситуации, когда это просто невозможно/невыгодно.
Например?
Например, когда вы разрабатываете нечто, что будет повторно использоваться в других проектах (допустим фреймворк или библиотека для чего-то). Перед началом разработки необходимо решить, что вообще должен уметь фреймворк, как он это будет делать, как сделать так, чтобы ваша разработка была удобна в повторном использовании и как её можно будет гибко расширить при необходимости. Подозреваю, что если «с ходу» приступить к написанию кода, большинство проблем, которые были бы очевидны после нескольких часов проектирования на бумаге будут очевидны только через несколько дней/недель, и чем позже эти проблемы будут выяснены, тем дороже они могут обойтись, так как некоторые не заложенные возможности могут создать необходимость переработки почти всей архитектуры фреймоврка, а если вы уже потратили неделю на его создание у вас может возникнуть желание оставить всё как есть или придумать хак, так как выбрасывать уже написанный код жалко.
Большие (по-настоящему большие) распределенные проекты, в которых команды разработчиков измеряются десятками. Я не знаю вашей специфики, но например, крупные аутсорсеры, например, ЕПАМ, очень часто сгонят на проекты крупных заказчиков сразу несколько команд по 10-15 человек каждая.
Как без документации передавать знания? Как заставить разработчиков создать единую систему, а не лезть кто в лес, кто по дрова? Как обеспечить единую цель, единый взгляд на архитектуру, бизнес-логику, другие вещи?
Ответ один — создать документацию. Целые команды специалистов высокого уровня получают нехилую зарплату лишь составляя «бумажечки», по которым потом работает множество народу.
И вот тогда уже вылезает тот самое «лучше найти ошибку в плане, нежели в прототипе». Потому что на прототип какой-нить подсистемы ушло 7 дней * 15 человек-в-команде, а на прототипирование 7 дней * 1 человек-проектировщик + 3 дня * 1 аналитик-по-качеству
Почувствуй разницу.
Как без документации передавать знания? Как заставить разработчиков создать единую систему, а не лезть кто в лес, кто по дрова? Как обеспечить единую цель, единый взгляд на архитектуру, бизнес-логику, другие вещи?
Ответ один — создать документацию. Целые команды специалистов высокого уровня получают нехилую зарплату лишь составляя «бумажечки», по которым потом работает множество народу.
И вот тогда уже вылезает тот самое «лучше найти ошибку в плане, нежели в прототипе». Потому что на прототип какой-нить подсистемы ушло 7 дней * 15 человек-в-команде, а на прототипирование 7 дней * 1 человек-проектировщик + 3 дня * 1 аналитик-по-качеству
Почувствуй разницу.
Проектировать все сразу и полностью вредно. Лучше спроектировать ядро, а дальше уже наращивать на него функционал. Иначе слишком высока вероятность ошибки при проектировании.
Ха, я посмотрю как вы будете пол дня проектировать систему, каждая ошибка в которой будет стоить 10-50% от стоимости :)
Вы просто взялись делать систему не имея опыта разработки подобных. И да, вместо порчения бумаги лучше было сделать прототип и с ним поиграться, тем самым получив минимальный но сфокусированный опыт. Имея же опыт намного выгоднее сначала прописать все на бумаге. В том числе и для дальнейших изменений.
Прототипирование нужно для уточнения ТЗ, особенно если Заказчик не имеет представления о предмете и не может сам сформулировать корректное задание. И с другими малоопытными в предмете разработки, например со своей командой, тоже поможет понять ТЗ. Но в целом это потеря времени, которая иногда меняется на ускорение создания или понимания ТЗ участниками.
Вы просто взялись делать систему не имея опыта разработки подобных. И да, вместо порчения бумаги лучше было сделать прототип и с ним поиграться, тем самым получив минимальный но сфокусированный опыт. Имея же опыт намного выгоднее сначала прописать все на бумаге. В том числе и для дальнейших изменений.
Прототипирование нужно для уточнения ТЗ, особенно если Заказчик не имеет представления о предмете и не может сам сформулировать корректное задание. И с другими малоопытными в предмете разработки, например со своей командой, тоже поможет понять ТЗ. Но в целом это потеря времени, которая иногда меняется на ускорение создания или понимания ТЗ участниками.
Да, это факт, мы взялись за разработку системы, про которую понятия не имели, как она должна работать. Сделали первую итерацию, потом вторую, потом третью, четвертую, и сейчас мы уже имеем и продукт, и понимание того, для чего мы ее делаем. Если бы мы проектировали, то сейчас у нас не было бы ничего.
И как это соотноситься с проектированием вообще?
Проектирование помогает определить многие базовые аспекты проекта — требуемые скилы, состав оборудования и/или работ. Также зачастую входит в требуемую документацию, потому что Заказчику потом это все эксплуатировать.
Также, с точки зрения проекта, помогает определить технические риски.
Если всего это нет, то двигаться на ощупь можно, если позволяет запас ресурсов и понимающий или пофигистичный заказчик. Но в целом, поскольку риски огромные, намного лучше нанять, пусть внешних, экспертов, которые помогут в начальный этап получить необходимые знания.
Проектирование помогает определить многие базовые аспекты проекта — требуемые скилы, состав оборудования и/или работ. Также зачастую входит в требуемую документацию, потому что Заказчику потом это все эксплуатировать.
Также, с точки зрения проекта, помогает определить технические риски.
Если всего это нет, то двигаться на ощупь можно, если позволяет запас ресурсов и понимающий или пофигистичный заказчик. Но в целом, поскольку риски огромные, намного лучше нанять, пусть внешних, экспертов, которые помогут в начальный этап получить необходимые знания.
Думаю, что в вашем случае проектирование — «зло», только потому, что вы не имели достаточного опыта/знаний, чтобы грамотно спроектировать систему до начала разработки.
На таких системах хорошо работают гибкие методологии с короткими итерациями.
Полностью согласен. Приведу анологию — когда стреляешь из винтовки — если ты целишься больше 5-и секунд то скорее всего промажешь.
Не реально спроектировать все в мелких деталях. Любая хорошая архитектура может быть придумана за день. Главное чтобы было понятно как ее потом расширять и менять.
Не реально спроектировать все в мелких деталях. Любая хорошая архитектура может быть придумана за день. Главное чтобы было понятно как ее потом расширять и менять.
Если Вы при проектировании не понимаете, что Вы получите в итоге, то это просто нехватка опыта разработки/проектирования.
В случае опытного специалиста, который уже решал подобные проблемы, задача проектирования сводится к формальным наброске эскизов на листе и постановке задачи в отдел производства (программистов). Причем опытный проектировщик создаст определенный задаток гибкости архитектуры, необходимый для решения встречных вопросов.
Сам таким опытом не обладаю, но встречал людей, которые в течении 1-2 часов обсуждают необходимый функционал (с допущением на один-два шага влево-вправо) и за 1 день выдают решение, которое как правило работает долго. Вызывает уважение.
В случае опытного специалиста, который уже решал подобные проблемы, задача проектирования сводится к формальным наброске эскизов на листе и постановке задачи в отдел производства (программистов). Причем опытный проектировщик создаст определенный задаток гибкости архитектуры, необходимый для решения встречных вопросов.
Сам таким опытом не обладаю, но встречал людей, которые в течении 1-2 часов обсуждают необходимый функционал (с допущением на один-два шага влево-вправо) и за 1 день выдают решение, которое как правило работает долго. Вызывает уважение.
У меня был печальный опыт с прототипированием. Однажды я начал делать внутренний проект с прототипа. Но так получилось, что вместо того, чтобы отложить прототип и начать делать реальную систему, фичи начали накатывать прямо на прототип. Это было неприятно. Впрочем, там во многом я сам был виноват. Вообще в таких случаях нужно чётко оговаривать, что это прототип и что в продакшн будет идти совсем другое и его ещё надо разработать. Ибо начальник может не понять и сказать — хуле, вы ж уже разработали, чо вам ещё надо. И сунет ваш прототип в продакшн.
Абсолютно согласен. С этой точки зрения прототип — очень опасная вещь. Как только глаза заказчика увидели что-то хоть немного работающее — он сразу начинает думать, что счастье не за горами. А вместо этого нужно разрабатывать всё заново.
И никогда ты ему не объяснишь, что прототип для тебя был просто средством уточнения требований.
И никогда ты ему не объяснишь, что прототип для тебя был просто средством уточнения требований.
Если вы не можете прототип использовать в качестве готового кода, значит вы что-то делаете не так.
Да и все равно, у вас перед глазами уже почти готовое решение, по кальке все делать намного быстрее, чем в первый раз.
Если начать презентацию прототипа со слов, что вы сейчас увидите прототип а не готовый функционал, то никаких проблем не будет. У нас, по крайней мере, никогда не возникало. Правда у нас прототипы на десяток другой процентов отличаются от конечного продукта. Переписывать особо ничего не надо.
Да и все равно, у вас перед глазами уже почти готовое решение, по кальке все делать намного быстрее, чем в первый раз.
Если начать презентацию прототипа со слов, что вы сейчас увидите прототип а не готовый функционал, то никаких проблем не будет. У нас, по крайней мере, никогда не возникало. Правда у нас прототипы на десяток другой процентов отличаются от конечного продукта. Переписывать особо ничего не надо.
Поэтому прототип нужно делать достаточно страшным, чтобы дать понять заказчику, что процесс идёт, но не давать слишком ранних надежд.
И есть интересный момент: как правило, разработчики хотят показать всем (и в первую очередь себе), на что они способны и что у них большие eggs, поэтому напрочь отметают решения конкурентов. А я вот по опыту знаю, что если вооружиться несколькими демо-роликами (демо-версиями) программ конкурентов (или просто похожих модулей другого ПО), то из них можно как раз извлечь понимание того, что нужно, как работает, а потом уже задуматься как это самому реализовать. Все уже давно сделано за нас, мы лишь это постоянно переделываем.
Вспомнился Брукс c IBM360 — долго проектировали, до сих пор народ не уверн хорошо ли было разделать сборку и линковку. Народ склоняется к мысли что отдельная линковка так сказать перебор.
НЛО прилетело и опубликовало эту надпись здесь
А у кого по другому бывало?
Расскажите, сколько человек входят в вашу команду, каков их возраст и стаж проектирования? При небольшом опыте проектирования, действительно есть существенные проблемы с тем, что далеко не все можно учесть заранее. Поэтому нужно находить золотую середину между проектированием и реализацией.
Имхо ребята сделали неправильный вывод. Из-за отсутствия обратной связи с клиентом решили, что проектирование не нужно.
А при чем тут обратная связь с клиентом к проектированию? Проектируете вы или нет, у вас все равно есть обратная связь. Вам все равно расскажут про все ваши ошибки и недочеты.
Обратная связь нужна на всем этапе проектирования и\или протитипирования. ТОЧКА!
Если Вы не общаетесь с заказчиком на самом начальном этапе проекта, то Вы напишете «сферического коня в вакууме», исходя только из свооих, в большинстве случаев неправильных, представлений о предметной области. Особенно если эту предметную область Вы и Ваша команда видете в первый раз. И этот сферический конь не будет иметь никакого отношения к реальной задаче — именно поэтому Ваш этап проектирования провалился. А когда вы начали по второму кругу, но уже прототипировать, Вы уже прошли по всем граблям на проектированиии и получили четкий фидбек от заказчика что не так и как должно быть. Это называется «Опыт».
Если Вы не общаетесь с заказчиком на самом начальном этапе проекта, то Вы напишете «сферического коня в вакууме», исходя только из свооих, в большинстве случаев неправильных, представлений о предметной области. Особенно если эту предметную область Вы и Ваша команда видете в первый раз. И этот сферический конь не будет иметь никакого отношения к реальной задаче — именно поэтому Ваш этап проектирования провалился. А когда вы начали по второму кругу, но уже прототипировать, Вы уже прошли по всем граблям на проектированиии и получили четкий фидбек от заказчика что не так и как должно быть. Это называется «Опыт».
Открою вам секрет, в нашей предметной области слушать конечного потребителя бесполезно. Они сами не знают, чего хотят. Практически все встречи заканчиваются словами «Вы предлагайте, а мы посмотрим, нужно нам это, или нет».
Что-то мне подсказывает, что очень редкий не-ИТ-заказчик не говорит аналогичных слов :)
Или начинают нести полный бред. В какой то момент его приходится остановить и сказать.
— «Стой! Давай лучше я расскажу свои мысли, по поводу того, что и как надо делать.»
Но беда в том, что ты не можешь идеально понимаешь предметную область заказчика. Поэтому если написать четкое и окончательное ТЗ, то ты все равно наделаешь в нем кучу проблем, и постановку задачи придется сильно корректировать.
— «Стой! Давай лучше я расскажу свои мысли, по поводу того, что и как надо делать.»
Но беда в том, что ты не можешь идеально понимаешь предметную область заказчика. Поэтому если написать четкое и окончательное ТЗ, то ты все равно наделаешь в нем кучу проблем, и постановку задачи придется сильно корректировать.
Знание предметной области хорошо, но не решает никаких проблем. Ну знаю я весь бизнес-процесс коллекторских компаний, почти все проблемы знаю. И что? Это ответит на вопрос, какой должна быть система по управлению их бизнес-процессов? Нет. Они все свои проблемы тоже прекрасно знают, и решают их так, как проще всего решать. Они не знают, как можно улучшить их бизнес-процесс, поэтому и говорят, что предлагайте решение.
Знание предметно области нужно чтобы мыслить в терминах этой самой предметной области, когда вы общаетесь с заказчиком, когда пишете проект, иначе получится разгвоор глухого с немым.
Количество небольшое. Опыт работников не знаю. Я проектировал до этого примерно год. Старался учитывать все. Потом плюнул, понял бесполезность затеи.
Не расстраивайтесь, и не опускайте руки. У Вас все впереди.
Всякое дело требует опыта. Доработаете вторую версию этого проекта, потом еще один проект на схожую тематику, и тогда будет опыт в этой области.
Просто не нужно углубляться и создавать детальную модель. Проектируйте на несколько шагов. При таком подходе не учесть всех тонкостей архитектуры, но главное, вы быстрее заметите, что неправильно выбран вектор развития проекта.
Всякое дело требует опыта. Доработаете вторую версию этого проекта, потом еще один проект на схожую тематику, и тогда будет опыт в этой области.
Просто не нужно углубляться и создавать детальную модель. Проектируйте на несколько шагов. При таком подходе не учесть всех тонкостей архитектуры, но главное, вы быстрее заметите, что неправильно выбран вектор развития проекта.
Зачем проектировать, если я не могу ответить на основной вопрос, а нужно ли это рынку. Я могу сколь угодно долго размышлять на эту тему, но ответ будет получен только после проверки теории на живом коде. Вот скажите, вы могли однозначно ответить, выстрелит ли Google Vawe или нет? Продукту пророчили успех, но он умер еще на старте. Это мертворожденный проект. И узнать это можно было только запустив его.
Вы правы, иногда нужно запустить проект, чтобы узнать, нужен он рынку или нет. У вас подобная ситуация?
Да. У всех такая ситуация. Выпуская что-то новое, все подвергаются риску быть отвергнутым.
Я вас прекрасно понимаю)…
С одной стороны, нужен быстрый старт, чтобы понять, есть ли смысл развивать проект.
Если старт оказывается успешным, руководство требует быстрого внедрения нового функционала, при этом доказать необходимость существенной доработки бывает сложно. Если не убедишь, проект так и будет расти на костылях.
С одной стороны, нужен быстрый старт, чтобы понять, есть ли смысл развивать проект.
Если старт оказывается успешным, руководство требует быстрого внедрения нового функционала, при этом доказать необходимость существенной доработки бывает сложно. Если не убедишь, проект так и будет расти на костылях.
«Порядка 95% компаний, а может даже больше...»
Дальше читать не стал. Думаю, вы догадались, почему.
Дальше читать не стал. Думаю, вы догадались, почему.
Нельзя так радикально судить — есть варианты, когда проектировать надо, а есть когда не обязательно.
Для внутренних разработок проектирование не всегда так важно, потмоу что разработчики обычно УЖЕ в курсе того что они хотят написать, и весь их опыт можно назвать «проектированием».
Если же Ваша компания берется за разработку нового проекта, то на первом этапе участвуют аналитики, которые делают ТЗ, предварительный анализ предметной области и проектирование совместно с архитекторами. После этого у компании (а не у программиста) есть представление о том, как будет выглядеть проект, как он будет разбиваться на модули и что в итоге надо заказчику. Затем уже эта вся информация передается группе программистов и ставятся задачи о разработке либо прототипов, либо уже непосредственно первой версии.
Возможен и другой вариант — программисты сразу начнут писать прототип, без этапа проектирования. Но тут возникает проблема — чтобы программисту уточнить какую-нибудь деталь, надо как-то выйти на заказчика и этот процесс обычно долгий. А если программист будет опять же писать прототип сферического коня в вакууме.
Опять же программист, который пишет код не всегда хорошо знает возможные архитектуры, а если и знает, то ему надо много платить, потому что это очень хороший программист. А чтобы содержать команду таких программистов, надо тратить гораздо больше денег.
Из своего опыта скажу: у меня опыт проектирования порядка 6-7 лет. И этот этап просто необходим. Система, ядро и архитектуру которой я спроектировал 3-4 года назад работает до сих пор как часы — она расширяема и мастабируема. Изначальная архитектура не претерпела никаких изменений с тех пор. И сразу скажу — система большая (всего уже порядка 30 модулей).
Для внутренних разработок проектирование не всегда так важно, потмоу что разработчики обычно УЖЕ в курсе того что они хотят написать, и весь их опыт можно назвать «проектированием».
Если же Ваша компания берется за разработку нового проекта, то на первом этапе участвуют аналитики, которые делают ТЗ, предварительный анализ предметной области и проектирование совместно с архитекторами. После этого у компании (а не у программиста) есть представление о том, как будет выглядеть проект, как он будет разбиваться на модули и что в итоге надо заказчику. Затем уже эта вся информация передается группе программистов и ставятся задачи о разработке либо прототипов, либо уже непосредственно первой версии.
Возможен и другой вариант — программисты сразу начнут писать прототип, без этапа проектирования. Но тут возникает проблема — чтобы программисту уточнить какую-нибудь деталь, надо как-то выйти на заказчика и этот процесс обычно долгий. А если программист будет опять же писать прототип сферического коня в вакууме.
Опять же программист, который пишет код не всегда хорошо знает возможные архитектуры, а если и знает, то ему надо много платить, потому что это очень хороший программист. А чтобы содержать команду таких программистов, надо тратить гораздо больше денег.
Из своего опыта скажу: у меня опыт проектирования порядка 6-7 лет. И этот этап просто необходим. Система, ядро и архитектуру которой я спроектировал 3-4 года назад работает до сих пор как часы — она расширяема и мастабируема. Изначальная архитектура не претерпела никаких изменений с тех пор. И сразу скажу — система большая (всего уже порядка 30 модулей).
Пост нужно переименовать в «Про бесполезность длительного проектирования без понимания предметной области»
Если предметная область незнакома, то нужно потратить время на ее исследование. В вашем случае это исследование проходило одновременно с «длительным проектированием». В нормальной ситуации исследование и проектирование — это два обязательных процесса, которые разнесены во времени.
Если предметная область незнакома, то нужно потратить время на ее исследование. В вашем случае это исследование проходило одновременно с «длительным проектированием». В нормальной ситуации исследование и проектирование — это два обязательных процесса, которые разнесены во времени.
Вот ещё одна статья в стиле «какой я молодец, что не наступил на детские грабли».
Тем не менее не могу не отметить, что нельзя эстраполировать свою малоопытность на все случаи жизни.
Прототипирование — это всего лишь один из методов уточнения ТЗ в рамках создания архитектуры. Собственно, вы занимались именно тем, от чего так страстно открещиваетесь: написание прототипа в данном случае есть планирование.
Прототипирование, кстати, мощный, но не единственный инструмент планирования. Когда отойдёте от восторгов по поводу того, как удачно избежали детских граблей, поищите в интернете такие слова, как «Имитационное Моделирование», «Реконструкция» и «Обратная Разработка». Они тоже имеют отношения к планированию.
Тем не менее не могу не отметить, что нельзя эстраполировать свою малоопытность на все случаи жизни.
Прототипирование — это всего лишь один из методов уточнения ТЗ в рамках создания архитектуры. Собственно, вы занимались именно тем, от чего так страстно открещиваетесь: написание прототипа в данном случае есть планирование.
Прототипирование, кстати, мощный, но не единственный инструмент планирования. Когда отойдёте от восторгов по поводу того, как удачно избежали детских граблей, поищите в интернете такие слова, как «Имитационное Моделирование», «Реконструкция» и «Обратная Разработка». Они тоже имеют отношения к планированию.
по своему опыту заметил что много нюансов вытекает на стадии разработки сложных проектов, все учесть не возможно на стадии проектирования, поэтому прототипы — это хороший способ «пощупать» проект и увидеть некоторые нюансы.
и ещё: «Все, что заслуживает быть сделанным, заслуживает того, чтобы быть сделанным плохо» © Золотые правила менеджмента.
и ещё: «Все, что заслуживает быть сделанным, заслуживает того, чтобы быть сделанным плохо» © Золотые правила менеджмента.
Вы сделали несколько весьма «сильных» заявлений, особенно если вырвать их из контекста:
"… Мы сели проектировать. Это было самой главной нашей ошибкой..."
"… Пока вы будете пол года марать бумажки, ..., ваши конкуренты-прототипщики уже давно выпустят продукт..."
"… Мы сели проектировать. Это было самой главной нашей ошибкой..."
"… Пока вы будете пол года марать бумажки, ..., ваши конкуренты-прототипщики уже давно выпустят продукт..."
Извините, не дописал,
Я это к тому, что такой подход в некоторых случаях может работать. Но обычно серьёзное качественное программное обеспечение всё же проходит определённые более-менее классические стадии — написание требований, сбор пожеланий пользователей, разработка дизайна, кодирование, тестирование, документация… И все бумажки в общем-то помогают сделать именно то, что требуется. Причём эти «бумажки» должны писаться для себя и для программистов, которые будут в будущем поддерживать проект, а не для того, чтобы отчитаться перед начальством.
У меня есть опыт выпуска продукта через прототип в условиях ограниченного времени, но этот прототип сразу был нацелен на запуск в производство (и сопровождался какой-никакой документацией, по крайней мере было страниц сорок требований и десятка два страниц, описывающих сложные и нетривиальные места в дизайне).
Есть и негативный опыт — был сделан некий прототип, практически без документации, отложен на пару лет «в ящик» по разным причинам, а затем была сделана попытка реанимировать и продолжить разработку. Программисты чуть не умерли, разбираясь во всяких «заглушках» типа «а вот это мы отложим на потом», «а вот тут я рыбу заворачивал». Пришлось практически переписать всё с нуля. Как результат — небольшая задержка выпуска, и суммарно времени было потрачено больше, чем было запланировано.
Я это к тому, что такой подход в некоторых случаях может работать. Но обычно серьёзное качественное программное обеспечение всё же проходит определённые более-менее классические стадии — написание требований, сбор пожеланий пользователей, разработка дизайна, кодирование, тестирование, документация… И все бумажки в общем-то помогают сделать именно то, что требуется. Причём эти «бумажки» должны писаться для себя и для программистов, которые будут в будущем поддерживать проект, а не для того, чтобы отчитаться перед начальством.
У меня есть опыт выпуска продукта через прототип в условиях ограниченного времени, но этот прототип сразу был нацелен на запуск в производство (и сопровождался какой-никакой документацией, по крайней мере было страниц сорок требований и десятка два страниц, описывающих сложные и нетривиальные места в дизайне).
Есть и негативный опыт — был сделан некий прототип, практически без документации, отложен на пару лет «в ящик» по разным причинам, а затем была сделана попытка реанимировать и продолжить разработку. Программисты чуть не умерли, разбираясь во всяких «заглушках» типа «а вот это мы отложим на потом», «а вот тут я рыбу заворачивал». Пришлось практически переписать всё с нуля. Как результат — небольшая задержка выпуска, и суммарно времени было потрачено больше, чем было запланировано.
НЛО прилетело и опубликовало эту надпись здесь
Как в такой ситуации оценивать сроки реализации? Ну, допустим, для средней руки проектика, в 30-40 KLOC?
Сроки реализации привязаны к двухнедельным циклам.
это уход от ответа.
Извините, недопонял вопрос. Срок исполнения зависит от многих факторов. На него влияют и знания предметной области, и повторное использование ресурсов, и наличие готовых решений, и сработанность команды, да много всего!
Поэтому срок вы называете тот, который будет основан на предыдущем опыте.
Поэтому срок вы называете тот, который будет основан на предыдущем опыте.
То есть вы не можете дать предварительных оценок, потому что для вашего метода «проб-и-ошибок» он не применим.
Такие дела.
Такие дела.
Любые сроки заведомо ошибочны. Это аксиома
Они ошибочны на эпсилон. И величина этого эпсилон как раз зависит от предварительных работ по проекту (то есть предшествующих кодированию).
Вы хоть раз сделали работу точно в срок? Хоть одну? Не раньше, не позже, а ровно в срок. Ну, без экстремумов, примерно до дня работы (или часа).
Вы умеете читать русские буквы и складывать их в слова? Известно, что сроки это = запланированный срок ± ошибка. Меня интересует: 1) как вы определяете базовый, запланированный срок; 2) как вы оцениваете возможный максимум модуля ошибки.
Или вы опять вопросом на вопрос ответите?
Или вы опять вопросом на вопрос ответите?
Запланированный срок = срок реализации первого прототипа. Ошибка(доработка) = разница между финальной версией реализации и сроком реализации первого прототипа. Мы не планируем сроки дольше чем на две недели.
То есть все-таки эта методология применима только к вашей бизнес-модели? Причем с обязательно готовым продуктом.
Как вы в банке, например, когда будете брать кредит на новый проект, будете защищать бизнес-план, когда там сроки не значаться? Потому что для банка «срок = срок реализации прототипа» это фуфло.
Как вы в банке, например, когда будете брать кредит на новый проект, будете защищать бизнес-план, когда там сроки не значаться? Потому что для банка «срок = срок реализации прототипа» это фуфло.
Банку пофиг на сроки и так далее. Им важно одно — какой риск того, что вы не вернете бабло. Если риски минимальные, то вы его получите с указанием сроков реализации или без.
Сказки такие сказки.
А вы составьте идеальный бизнес-план, и вручите его лицу, которое имеет судимости по «экономическим» статьям, и пойдите хоть копейку попробуйте выпросить. Сроки говорите?
Вы уже сами с собой сейчас беседуете? Ну, не буду отвлекать…
Я вам на конкретном примере показал, что банк ставит риски на первое место. Вы не согласны? Тогда поясните, почему при идеальных сроках и идеальном бизнесплане такому человеку не дадут ни копейки денег?
Хорошо. Не верите? Сделайте залогом ликвидное имущество или текущий бизнес. Уверен, что денег вам дадут без вопросов, даже если бизнсплан будет хромать на четыре ноги.
Хорошо. Не верите? Сделайте залогом ликвидное имущество или текущий бизнес. Уверен, что денег вам дадут без вопросов, даже если бизнсплан будет хромать на четыре ноги.
Далеко ходить не нужно, сегодня первый день сдачи проекта (всего 3 дня). А дата была запланирована… не помню точно договора, месяца полтора назад.
Рискую оказаться банальным, но позволю себе процитировать книгу «Совершенный код» Стива Макконнела:
«Исследование последних 25 лет убедительно доказали выгоду правильного выполнения проектов с первого раза и дороговизну внесения изменений, которых можно было бы избежать.
Ученые из компаний Hewlett-Packard, IBM, Hughes Aircraft, TRW и других организаций обнаружили, что исправление ошибки к началу конструирования обходится в 10-100 раз дешевле, чем ее устранение в конце работы над проектом, во время тестирования приложения или после его выпуска.»
Ваш случай как нельзя лучше согласуется с этим утверждением, ведь вначале Вы допустили ошибку на стадии планирования, которую решали уже в коде, и уже осознав это, вы пересмотрели архитектуру и приступили к прототипированию.
«Исследование последних 25 лет убедительно доказали выгоду правильного выполнения проектов с первого раза и дороговизну внесения изменений, которых можно было бы избежать.
Ученые из компаний Hewlett-Packard, IBM, Hughes Aircraft, TRW и других организаций обнаружили, что исправление ошибки к началу конструирования обходится в 10-100 раз дешевле, чем ее устранение в конце работы над проектом, во время тестирования приложения или после его выпуска.»
Ваш случай как нельзя лучше согласуется с этим утверждением, ведь вначале Вы допустили ошибку на стадии планирования, которую решали уже в коде, и уже осознав это, вы пересмотрели архитектуру и приступили к прототипированию.
Ваша статья доказывает бесполезность проектирования, если был пропущен этап сбора требований.
Вы взялись автоматизировать внутренние процессы компании. Для этого процессы должны быть задокументированы и это должны быть устоявшиеся процессы (и, кстати, если эти процессы неэффективны, то результат автоматизации будет тоже неэффективен). Судя по статье, вы в процессах не особенно разобрались (а ведь стоило всего денёк посидеть рядом с простым менеджером или саппортером и позадавать вопросы), но решили, что готовы делать биллинг.
Вы взялись автоматизировать внутренние процессы компании. Для этого процессы должны быть задокументированы и это должны быть устоявшиеся процессы (и, кстати, если эти процессы неэффективны, то результат автоматизации будет тоже неэффективен). Судя по статье, вы в процессах не особенно разобрались (а ведь стоило всего денёк посидеть рядом с простым менеджером или саппортером и позадавать вопросы), но решили, что готовы делать биллинг.
Увы, но в процессах я как раз разобрался. И это была моя ошибка. Я слушал не того человека и решал не те задачи.
У меня еще был один момент. Делал предварительную проектировку системы одной финансовой компании. Так вот, пока мы пол года проектировали и зарисовывали бизнес-процесс компании, успели измениться базовые условия. Пришлось повторять по два раза одно и то же. Система до сих пор не запущена в эксплуатацию.
У меня еще был один момент. Делал предварительную проектировку системы одной финансовой компании. Так вот, пока мы пол года проектировали и зарисовывали бизнес-процесс компании, успели измениться базовые условия. Пришлось повторять по два раза одно и то же. Система до сих пор не запущена в эксплуатацию.
Батенька, да вы что-то не то нам говорите. habrahabr.ru/blogs/pm/107655/#comment_3398597
Один из типов рисков — заказчик. Если рассматривать риски этой классификации (смены условий среды к примеру) и контролировать их — систему вполне можно запустить в срок…
Один из типов рисков — заказчик. Если рассматривать риски этой классификации (смены условий среды к примеру) и контролировать их — систему вполне можно запустить в срок…
Уважаемый автор, при написании статьи Вы кратко и очень частично изложили некоторые принципы экстремального программирования (XP), весьма спорного подхода к разработке по сей день.
Мое мнение — такой подход приемлем либо для некоммерческих, либо для небольших проектов.
Любой вменяемый заказчик при подписании договора потребует зафиксировать, каким будет его проект. Поэтому проектная документация должна присутствовать. Другое дело, в каком объеме и в какие сроки это будет разработано.
Если доходить до маразма, то разрабатывать документацию можно вечно.
Второй же тип документации — техническая документация для разработчика очень актуальна, когда после сдачи проекта нужно его дорабатывать (например, вам же). Особенно, если программистов, которые делали проект, уже у вас нет. При этом, никакой красивый-понятный код не поможет вам так, как документация. Если смотреть на код, программисту нужно интуитивно понимать и догадываться об архитектуре системы. Даже если код написан правильно.
Документация же помогает упростить и ускорить процесс понимания.
Так что мое мнение — всего нужно в меру. В меру документировать, в меру свободно разрабатывать на базе прототипов и т.п.
А еще такой подход (если не соблюдаются все принципы XP) смахивает на попытку подвести теоретическую базу под лень и расхлябанность в разработке.
Уважаемый автор, ничего личного, насчет последнего могу ошибаться.
Мое мнение — такой подход приемлем либо для некоммерческих, либо для небольших проектов.
Любой вменяемый заказчик при подписании договора потребует зафиксировать, каким будет его проект. Поэтому проектная документация должна присутствовать. Другое дело, в каком объеме и в какие сроки это будет разработано.
Если доходить до маразма, то разрабатывать документацию можно вечно.
Второй же тип документации — техническая документация для разработчика очень актуальна, когда после сдачи проекта нужно его дорабатывать (например, вам же). Особенно, если программистов, которые делали проект, уже у вас нет. При этом, никакой красивый-понятный код не поможет вам так, как документация. Если смотреть на код, программисту нужно интуитивно понимать и догадываться об архитектуре системы. Даже если код написан правильно.
Документация же помогает упростить и ускорить процесс понимания.
Так что мое мнение — всего нужно в меру. В меру документировать, в меру свободно разрабатывать на базе прототипов и т.п.
А еще такой подход (если не соблюдаются все принципы XP) смахивает на попытку подвести теоретическую базу под лень и расхлябанность в разработке.
Уважаемый автор, ничего личного, насчет последнего могу ошибаться.
Да, это XP. И это работает.
Парное программирование упрощает понимание и ускоряет процесс вхождения в курс дела. Проверено, работает!
Парное программирование упрощает понимание и ускоряет процесс вхождения в курс дела. Проверено, работает!
xp работает в условиях (вспоминаем классику):
*) большая сложность при устойчивых технических требованиях;
*) высокие требования к надёжности и безопасности
*) предсказуемое окружение
В других ситуациях может и не сработать.
*) большая сложность при устойчивых технических требованиях;
*) высокие требования к надёжности и безопасности
*) предсказуемое окружение
В других ситуациях может и не сработать.
А может и сработать. Разница ведь между сложными и простыми проектами небольшая.
Разница между сложными и простыми проектами огромна: появляется множество факторов, которые не надо учитывать на простых и коротких проектах, как например увольнение через полгода одного из главных программистов, который «знал все».
Дрквняя поговорка: Заствь дурака богу молиться — он лоб разобьет.
Все и всегда надо делать в меру.
А так любую идею можно до абсурда довести.
Все и всегда надо делать в меру.
А так любую идею можно до абсурда довести.
Не моя область, но с таким отношением к проектным технологиям в сфере ERP, я бы за милю не подпустил вас к заказчику.
Я бы не стал прямо так уверенно про 95% компаний говорить, у Гласса где-то упоминалось, что менеджеры думают, что их программисты используют такую классическую модель. А программисты просто делают, а менеджерам говорят то, что они хотят услышать.
Вообще рекомендую Гласса прочитать, у него и про проектирование есть. Он хорош тем, что даёт кучу источников для углубленного изучения темы.
Вообще рекомендую Гласса прочитать, у него и про проектирование есть. Он хорош тем, что даёт кучу источников для углубленного изучения темы.
Тогда вопрос автору. Вы программист или руководитель проектов (менеджер)?
Уточню, вопрос автору статьи.
Руководитель. Но и от разработки не отказываюсь, мне это нравится.
Хорошо, тогда мы поймем друг друга. Рассмотрим утрированную ситуацию (не SaaS, следовательно клиент не привязан к нам).
Организация Н заказывает у вас автоматизировать процесс обработки платежей. Бизнес процессы заказчика нам незнакомы, но с его слов мы понимаем, что этот процесс «критичный», т.е. простой означает убытки.
1. Руководителя проектов в первую очередь интересует финансовая сторона, творчество оставим программистам. Как без проектирования посчитать стоимость для клиента?
Организация Н заказывает у вас автоматизировать процесс обработки платежей. Бизнес процессы заказчика нам незнакомы, но с его слов мы понимаем, что этот процесс «критичный», т.е. простой означает убытки.
1. Руководителя проектов в первую очередь интересует финансовая сторона, творчество оставим программистам. Как без проектирования посчитать стоимость для клиента?
Стоимость проекта будет зависеть от компромисса между вашими желаниями заработать и реальными возможностями клиента.
Если вы привяжетесь к какой-то сумме, то любые ваши ошибки проектирования будут стоить вам денег, вы будете разрабатывать проект за свой счет.
Работу разбил бы на несколько этапов, на первом бы делал прототипы и ответил бы, сколько времени еще нужно на второй или другие этапы.
Если вы привяжетесь к какой-то сумме, то любые ваши ошибки проектирования будут стоить вам денег, вы будете разрабатывать проект за свой счет.
Работу разбил бы на несколько этапов, на первом бы делал прототипы и ответил бы, сколько времени еще нужно на второй или другие этапы.
По вашему, если я приду к заказчику и скажу:
«Я не знаю сколько это будет стоить, но давайте попробуем. Начнем делать, а там уже видно будет когда это закончится и сколько это будет стоить.»
Он ответит: Конечно, мои денежные и трудовые ресурсы в твоем распоряжении!
UPD. Мне это напоминает тарифы у ОПСосов, никогда не знаю во сколько мне выльется текущий месяц, даже на безлимитном тарифе :)
«Я не знаю сколько это будет стоить, но давайте попробуем. Начнем делать, а там уже видно будет когда это закончится и сколько это будет стоить.»
Он ответит: Конечно, мои денежные и трудовые ресурсы в твоем распоряжении!
UPD. Мне это напоминает тарифы у ОПСосов, никогда не знаю во сколько мне выльется текущий месяц, даже на безлимитном тарифе :)
Вы думаете, что этот способ продаж невозможен?
Возможен. Более того сам изначально работал именно так, пока не понял, что «проектные работы» это не просто куча бумажек, но и сэкономленные нервы и более высокий доход.
Точнее не сам понял, а жизнь научила, после одного проекта, который изначально посчитал легким, а в итоге отработали в хороший минус.
Точнее не сам понял, а жизнь научила, после одного проекта, который изначально посчитал легким, а в итоге отработали в хороший минус.
Не понимаю, как можно прогореть на сдельной оплате труда.
На сдельной оплате, это когда у заказчика в качестве наемного сотрудника, либо в договоре четкие сроки/часы обозначены. А у меня в том случае полная Ж… была — неустановленный срок, размытая сумма и куча не выявленных рисков.
Мог бы в отдельном топике рассказать, но там часто буковки 1С мелькать будут, могут за рекламу счесть.
Мог бы в отдельном топике рассказать, но там часто буковки 1С мелькать будут, могут за рекламу счесть.
Думаю, запросто, потому что все с кем в основном приходится работать (у нас в России), в конечном итоге все равно приводят оплату по рейтам/по факту к фикс-прайсу, и требуют утвердить этот самый фикс-прайс до начала работ.
Как только заказчики начнут хоть чуть-чуть понимать этот момент, и начнут соглашаться на гибкие условия — все сильно изменится. Впрочем, не верю, что в России с ее бюрократами это возможно. Им всегда надо «утвердить бюджет», без оного никак же ж! Getting Real в таких проектах не работает у нас.
Как только заказчики начнут хоть чуть-чуть понимать этот момент, и начнут соглашаться на гибкие условия — все сильно изменится. Впрочем, не верю, что в России с ее бюрократами это возможно. Им всегда надо «утвердить бюджет», без оного никак же ж! Getting Real в таких проектах не работает у нас.
Вы объявили хорошую проблему, поставили правильные вопросы, но уж как то слишком поверхностно ответили на вопрос проблемы. Примерно как — «едем на Запад», но как и зачем туда надо осталось без ответа. Хотелось бы больше примеров, описания инструментов, нюансов.
Требую расскрывания темы :)
Требую расскрывания темы :)
Ну правильно — на фиг проектирование, на фиг тестирование, потом получаются поделки, как у «Билайна» клиентский кабинет.
Не плохо было бы если вы еще полделились скриншотами: то что было и то что стало :)!
такое ощущение, что человек описывает свой первый проект. Необходимость проектирования и документирования приходит с годами или с опытом, как хотите. Такие «девелоперы» встречаются, все заканчивается тем, что их проекты кто-то либо доделывает либо переделывает, а они находят себе новую жертву, когда клиент невыдерживает уже того, что их система все время разваливается.
Мы сами себе клиент. И система не только не разваливается, но становится с каждой итерацией все элегантнее.
Обычная индуктивная логика (также именуемая женской): «Мы облажались при долгом проектировании, а значит, оно никому не нужно».
Хотите сказать, что чем дольше проектируешь, тем меньше ошибок?
Нет, чем лучше проектируешь, тем меньше ошибок. Бывают ситуации и проекты, когда быстрое проектирование не просто навредит проекту, а привнесет гигансткое колическо логических бомб, которые могут сдетанировать в будущем… а могут и не сдетанировать…
Меньше ошибок в вашем проекте. Но не в успешности, удобстве, качестве самого продукта. Как пример я приводил Google Wave, который наверняка был хорошо спроектирован, великолепно реализован, но нафиг никому не нужен. Реализовывать нужно то, что нужно рынку. А узнать это можно только реализовав.
Перед тем как реализовывать нужно спроектировать.
Спроектировать успешность продукта?
Спроектировать сам продукт.
А смысл его проектировать, если его может не принять рынок?
Ну потому что если не проектировать, то и принимать нечего будет. (ну если мы конечно говорим о чем-то сложнее чем «Hello World»)
Проектирование — совершенно не обязательный этап создания проекта.
Проектирование — самый важный и самый обязательный этап создания проекта. Может не быть прототипов, может не быть четкого ТЗ, может не быть итераций, но проектировать надо всегда. Сколько времени уделить проектированию (один день или один месяц) — это уже другой вопрос.
А я где-то с этим спорил? Вы видели в статье, что мы никогда не проектируем?
эм… а коммент выше с содержанием
Проектирование — совершенно не обязательный этап создания проекта.не Вы разве написали?
Я, но теперь поясню подробнее, что я имел в виду. Рынок требует решения проблем, а не проектирования. Нужен не продукт, а нужно решение. Решение может состоять из множества продуктов. Продукт может создаваться с нуля, а может быть конструктором, который всего лишь нужно настроить или соединить части вместе. Соединяя части получается новый продукт, но при его создании вообще не делается проектирование.
эм… не понял вот этого: «Меньше ошибок в вашем проекте. Но не в успешности, удобстве, качестве самого продукта.» Как эти два предложения связаны? В проекте может быть мало ошибок, но он будет плохого качества?
Проект может быть банально не нужен рынку. Если бы были прототипы, понятно было бы еще задолго до выпуска, что не так.
А как связано качество продукта и потребность рынка в нем?
Допустим, вы проектировали систему развозки пиццы. Вы взяли реальную модель логистики в городе, учли пробки, затраты на бензин, скорость остывания пиццы. Система была спроектирована до блеска. А оказалось, что сеть пиццерий была настолько успешной, что через пол года сеть разрослась, потребность в мотороллерах и сложной логистике отпала. Время доставки сократилось настолько, что скорость остывания пиццы уже никого не волнует. Зато начала волновать балансировка нагрузки. Понадобилась интергация с кассовыми аппаратами. Ваша изначальная структура программы уже не учитывает реалии рынка.
Так понятнее?
Так понятнее?
Это Вы сейчас так описали проектирование, которое не учло развитие и масштабирование системы. Если масштабирование и развитие системы не заложено изначально, то не важно делаете вы прототип или проектируете «марая клочки бумаги» — ваша система обречена на провал.
В случае, если развитие и масштабирование понадобилось ;) А если нет, то, вполне возможно, усилия, направленные на обеспечение расширяемости и масштабируемости, будут потрачены впустую и, как следствие, приведут к убыточности проекта.
если развитие и мастшабируемость не понадобились, значит система оказалась никому не нужна, ее не используют и не дорабатывают.
Система как раз нужна и полезна. Просто вы, вместо того, чтобы дать примитивный инструмент заказчику, проектировали его до посинения. Бизнес требует быстрой реализации проекта и минимизации временных затрат, а длительное проектирование обратно пропорционально этому.
Ну почему? Её использует заказчик по назначению, согласно ТЗ. Ничего большего ему не нужно (всё остальное — офис, браузер да типовой конфиг 1С), роста нагрузки не предвидится ни по числу транзакций, ни по числу рабочих мест, входные и выходные формы конфигурируются пользователем. Чисто теоретически можно было бы конечно повторить в проекте используемые возможности другого ПО, но чисто практически овчинка выделки не стоит ни для заказчика (может ему ещё разработку ОС оплатить?), ни для исполнителя (разрабатывать ОС даром тоже не хочется).
Хочу сказать, что делать выводы и тем паче давать советы на основе одного случая — плохая идея. Это как сходить в бассейн, встретить там НЛО, а потом утверждать «не ходите в бассейны, там этовот». Ну, почти так.
С проектированием люди сталкиваются уже много лет, написаны монументальные труды типа «Code Complete» Макконнелла… А у вас вот биллинг не получился, значит, нужно всё выбросить. Perfect!
С проектированием люди сталкиваются уже много лет, написаны монументальные труды типа «Code Complete» Макконнелла… А у вас вот биллинг не получился, значит, нужно всё выбросить. Perfect!
А мне статья очень понравилась.
С одной стороны, это success story. С другой стороны, довольно нетипичная, могло и не взлететь. А такого большого количества комментариев со смыслом я давно не видел. Спасибо всем!
С одной стороны, это success story. С другой стороны, довольно нетипичная, могло и не взлететь. А такого большого количества комментариев со смыслом я давно не видел. Спасибо всем!
Вот тут Fallout New Vegas вышел — баг на баге сидит и багом погоняет. Видимо, вместо продукта выпустили прототип. Побыстрее шлеп-шлеп.
Вроде как и игра классная, но вместо игры сидишь и тестируешь. И каждый квест проверяешь — ты ли тупишь или баг очередной.
Я в исходники заглянул — понял, что бардак при разработке творился. Даже стандартов именования нет.
Вроде как и игра классная, но вместо игры сидишь и тестируешь. И каждый квест проверяешь — ты ли тупишь или баг очередной.
Я в исходники заглянул — понял, что бардак при разработке творился. Даже стандартов именования нет.
Вначале хотел было возмутиться: как это, без проектирования! Но потом почитал ваши комменты и понял что вы имели в виду. Сам сейчас наблюдаю ситуацию когда на одном проекте команда (слава богу не наша) увязла в дотошном проектировании (ибо чистая работа по RUP-у). Прототип было бы сделать в разы проще и быстрее.
Как мне показалось то самое «проектирование», о котором все пишут, тыкая в «опыт» это просто примерная запись архитектуры сделанного уже аналогичного проекта с поправками на нового заказчика. Да, если бы я занимался разработкой таких типовых штук, то так бы и делал — писал проектную документацию. Хрен вы с проектируете систему, которую до вас вобще никто не делал.
Вы открыли для себя Agile, как он есть. Короткие релизы и быстрая обратная связь от заказчика. Желаю вам внедрить у себя и остальные практики Scrum и XP.
Я не открыл для себя, я три года уже успешно применяю. :) Но не многие разделяют моей радости, отсюда и негативное отношение к постам и лично мне в целом.
Т.е. вы намеренно опустили слово Agile, дабы не вызвать гневные отзывы?
Негативного отношения лично не имею, да и некоторые ваши посты запомнились положительно. Но вот последние три как-то, имхо, очень однозначны, не допускающие других вариантов, а ведь их всегда больше, чем один. Честно говоря, в данном посте (и многих комментах) вообще не понял в чём противопоставление: для меня лично прототипирование неотъемлемая часть (но не целое, есть и другие части) проектирования. Когда получаем устраивающий заказчика прототип, можно считать, что проектирование закончено и пора с чистой совестью начинать реализацию.
Гипербола нужна для усиления эффекта. Перегибаю палку намеренно, чтобы человек наверняка задумался над тем, что ему кажется чуждым. А что люди не понимают, то они отрицают. Законы природы.
По-моему, судя по комментам, эффект обратный: люди, в большинстве своем (сужу по себе, если что), не восприимчивы к революционным идеям, а предпочитают эволюционные. Например, автоматизированное тестирование облегчает жизнь разработчика при рефакторинге, да и просто проверку продукта на соответствие ТЗ. Вроде никто не спорит уже давно, а потом потихоньку приходят к мысли, что начинать нужно с разработки тестов, чтобы, в числе прочего, рефакторингу ничто (в частности разработка тестов «задним числом») не мешало. А скажи человеку, который сам дошёл до идей TDD, в то время, когда ему в голову ещё не пришла идея тестов вообще, что тесты могут стоять во главе разработки, так он с большой вероятностью только пальцем у виска покрутит.
Что касается TDD: написание тестов есть самое настоящее проектирование. И тут проблемы те же самые, что с обычным проектированием. Я обычно начинаю с прототипа, что бы разобраться со всеми незнакомыми технологиями, и сделать proof-of-concept каких-то моих решений. Затем пишу тесты практически параллельно с кодом и уже конструирую нормальную архитектуру. Иногда пишу тесты сразу после кода. Главное не откладывать написание тестов на потом, толку от них будет 0.
Не совсем согласен, что написание тестов, особенно задним числом, есть проектирование — тесты могут только отражать действительность, то есть подтверждать работоспособность. И не согласен, что написание прототипа проектированием не является — грубо говоря, прототипирование является методом оценки «адекватности» проектного решения, пускай и принятого только в голове.
>тесты могут только отражать действительность, то есть подтверждать работоспособность.
Сами по себе тесты ничего не подтверждают. Подтверждает работоспособность запуск тестов. А написание теста по сути дела это написание спецификации (конечно бывают и другие виды тестов, например на моках).
>написание прототипа проектированием не является
Является конечно. Я разве где-то написал обратное?
Сами по себе тесты ничего не подтверждают. Подтверждает работоспособность запуск тестов. А написание теста по сути дела это написание спецификации (конечно бывают и другие виды тестов, например на моках).
>написание прототипа проектированием не является
Является конечно. Я разве где-то написал обратное?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Про бесполезность длительного проектирования