[javadoc] [code conventions] @author

Да, использую. Хотя всегда делаю шапку, в которой авторство и так есть.

А не возникало такой ситуации: класс/интерфейс объявляет один человек, потом в процессе разработки вся команда перекраивает его вдоль и поперек, и в конечном счете тэк @author начинает лгать? Или каждый, кто вносит существенное изменение в код приписывается к авторам?

Нет, я в команде код не писал, но, думаю, в такой ситуации следует в шапке написать имена всех авторов или же в теге указать название команды.

Обычно у каждого файлика делаю шапку, где написано кто автор, что за файлик, и что делают описанные в нем методы. Если авторов много - все они записаны в шапке.

Должен приписываться, а вообще про то кто поучайствовал в написании кода достоверно расскажет svn иличтоатмувас.

_________

//wfrr

Всегда смотрю в системе контроля версий. Тег автор - бред. Кто автор, если метод десять раз за несколько лет двумя десятками человек перекраивался?

тег автор вощет отражает авторов интерфейса (класса)

_________

//wfrr

Система контроля версий лучшее место для подобной информации.

>тег автор вощет отражает авторов интерфейса (класса)

ну это, как я понял, пока что единственное оправданное применение для этого тега

И на кой леший это нужно? Искать виновных в случае чего? :) No way.

подсказываю - при чтении javadoc к интерфесу можно узнать человека к которому стоит обратиться за разъяснениями по диазйну, предложениями и т.п. Так как в нормальных конторах автора интерфейса как правило и занимается его поддержкой, а еси автор оказался архитектором - то он решает можно ли вносить модификации и т.п.

не всеже бояться отвественности за свой программный шкод

_________

//wfrr

подсказываю - при чтении javadoc к интерфесу можно узнать человека к которому стоит обратиться за разъяснениями по диазйну, предложениями и т.п

Подсказываю, что через несколько лет перелопачивания кода самые актуальные знание у того, кто последний правил код. И вообще понятие авторства какое-то мутное.

. Так как в нормальных конторах автора интерфейса как правило и занимается его поддержкой

В нормальных конторах кроссфункциональность и вообще agile. А во всяких совковых клоповниках бюрократия, да.

>И вообще понятие авторства какое-то мутное.

- Кто этот говнокласс б**ть нашкодил?

- это agile, у него из зарплаты за провал проекта и вычитайте.

_________

//wfrr

Херня какая-то. Во первых вычитать из зп рядового за провал проекта только менеджер-долбо*б будет. Проект провавлился => не было релизов проектв до этого => виноват манагер. Во-вторых в системе контроля версий глянул блейм и ясно с кем нужно дальше общаться.

> Во-вторых в системе контроля версий глянул блейм и ясно с кем нужно дальше общаться.

А как быть, если глянул блейм, а там каждую строку коммитил разный программист? Кто тогда ответственный за класс/интерфейс? Все же возможно авторство должно приписываться к интерфейсу хотя бы, как было упомянуто выше, для возможности дальнейшего обсуждения архитектуры проекта?

Просто хочется, чтобы в комментариях было поменьше недостоверной информации.

Кто тогда ответственный за класс/интерфейс

Не нужно ставить телегу впереди лошади. Если нужно ввести ответственность за отдельный класс, то никто кроме владельца или без его ревью и не может комитить этот файл.

Если по файлу куча коммитов от разных людей, то тег автор нишиша на значит, ибо то звездешь. Какого-то единого автор у кода нет.

А повторяю сотый раз - не нужно выяснения никаких ответсвенностей. Поиск источника знаний по коду нужен, да. И этот источник это любой, кто комитил в этот класс.

для возможности дальнейшего обсуждения архитектуры проекта?

Ок. Вот написано в авторах Вася Пупкин. Класс написан 3 года назад. За это время в файл накомитили 2 десятка человек. Идешь ты к Васи Пупкину за разъяснениями. А он смотрит в код и понимает, что абсолютно не владеет ситуацией, так как много воды уже утекло. Правильное решение - смотришь в блейм, видишь, что последний раз активно над файлом измывался некий Петр Иванов пару месяцев назад. Вот к нему и топаешь.

За тупые ошибки и шкодинг в состояни алкогольнотабачнойспермонаркотической интоксикации из зп вычитать надо. За то что не протестировал юниттестом, за то в диалоге с ошибкой слово «х***я с сетью» (были преценденты) и прочую хрень. Но это реализация.

А за кривой интерфейс, должен отвечать архитектор проекта, он его прорабатывает, и решает можно ли что-то менять, так как это влияет на интеграцию с другими (под)проектами, и такие решение выходцы из боклановриата не могут принимать, если это не гном или линукс какойнить.

За провал на рынке в силу хренового позиционирования и т.п. из зп менегеров.

Вотще любая работа подразумевает ответсвенность. А у вас совок какойто.

_________

//wfrr

>Если нужно ввести ответственность за отдельный класс

Научись отличать реализацию класса, от его интерфейса уже.

_________

//wfrr

А за кривой интерфейс, должен отвечать архитектор проекта, он его прорабатывает, и решает можно ли что-то менять, так как это влияет на интеграцию с другими (под)проектами, и такие решение выходцы из боклановриата не могут принимать, если это не гном или линукс какойнить.

Не завидую тем, кто так действительно пытается делать. Схему «архитектор пишет интерфейс, Вася реализует» мы между собой называем «архитектурой в вакууме» и это жесткий антипаттерн. Коль архитектор берется за интерфейс, он должен браться и за реализацию. Ну или по крайней мере ревьюить. Ибо несуществует никаких способов доказать валидность интерфейса кроме как его реализовать и проанализировать критический момент.

Научись отличать реализацию класса, от его интерфейса уже.

Ответил выше почему нельзя однозначно разделять интерфейс и реализацию. Они должны создаваться взаимиозависимо и итерационно. Поэтому ответственность за интерфейс <=> ответственность за класс.

>Схему «архитектор пишет интерфейс, Вася реализует» мы между собой называем «архитектурой в вакууме»

Вы можете ее хоть говном дражнить, но тот факт что вася не может продумать интерфейс, а опытный архитектор не имеет столько времени чтобы за всех вась писать код - это реалии из жизни, и коль у вас интерфесы пишутся васями из баклановриата, то и софт будет такимже.

_________

//wfrr

а опытный архитектор не имеет столько времени чтобы за всех вась писать код - это реалии из жизни

Согласен, в жизни так часто бывает. Хороших кадров всегда не хватает. Но факт остается фактом. Результат будет хорош только если и дизайн и его реализацию делает человек с мозгом. Это могу быть разные люди, которые дают друг другу фидбек, не суть. Но доверь реализовать интерфейс дебилу, результат ожидаем: ни фидбека о кривизне интерфейса от него не получишь, ни нормальной реализации не дождешься. Вот так и пишут конторы говнокод. Не говнокод пишут только в нормальных конторах, где у рядового квалификация не ниже архитектора в обычной быдло конторе. Даже у Брукса есть такое положение в его мифическом человека-месяце. А что касается agile, то роль архитектора там как раз специфическая, там архитектор на самом деле тренер-консультант по архитектуре, который учит команду архитектурить. А комманда уже архитектурит сама.

>Но доверь реализовать интерфейс дебилу, результат ожидаем: ни фидбека о кривизне интерфейса от него не получишь

хм, милый, речь не о клинических случаях, а о случаях низкой квалификации в области _проектирования_, если ты не знал, то знай что спроектировать stable интерфейс которы _не_ _потребуется_ (а не «не сможется») требует гораздо больше уровня нежели у штатного программиста, а нашкодить грамотную реализацию не сложно. Кромя того при юнит тестировании то.

А что касается agile, то роль архитектора там как раз специфическая, там архитектор на самом деле тренер-консультант по архитектуре, который учит команду архитектурить. А комманда уже архитектурит сама.

Про методологии отдельная тема для срача, особенно про сферические методологии в реальном мире 8)

_________

//wfrr

>которы _не_ _потребуется_ менять в будущем (а не «не сможется»)

фикс

_________

//wfrr

если ты не знал, то знай что спроектировать stable интерфейс которы _не_ _потребуется_ (а не «не сможется») требует гораздо больше уровня нежели у штатного программиста,

С точки зрения agile абсолютная глупость вводить в качестве метрики качества интерфейса его стабильность. Но чую тут водопад. Спорить дальше не интересно, так как это типичный холивар «водопад vs agile». И еще раз рекомендую почитать у Брукса про то, что дизайн и имплементация - это две одинаково СЛОЖНЫЕ задачи.

>Но чую тут водопад.

Это IRL. В RL ты выпадаешь из уюутненького мирка, и тебе приходится [s]трахаться[/s] интегрироваться со всяким сторонним говном, либо используя его интефейсы либо юзая свои, иногда задача создать платформу, да, да, а платформа с нестабильными интерфейсами - провал. Ну линакс с его феерией можно тоже вспомнить как пример.

Так что, милый, тут все сложно, и фанатизм в любой области, в том числе и фанатичное стремление равняться на любимую методологию, стольже разрушительно как и любой другой вид глупости.

ps. кстати, а на каких сайтах сталкиваются лбами фанаты различных методологий, интересно почитать.

_________

//wfrr

да, да, а платформа с нестабильными интерфейсами - провал.

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

ps. кстати, а на каких сайтах сталкиваются лбами фанаты различных методологий, интересно почита

В каментах на быдлохабре. Искать по словам «водопад, спецификация, agile» и т.п. Еще в каментах всяких жжешников, но конкретные что-то не припомню.

> Так что, милый

Выфер, ты пидр чтоли?

>А я говорю, что провал - платформа со стабильными интерфейсами :)

Я слышу слова не юноши но студента-фанатика свежепрочитаной книжки про «щас я вам расскажу как надо».

Только их двигать нужно в правильном направлении.

Чудо, клиенты твоей платформы нихрена двигать не будут, они свалят с нее и все.

Архитектор с архитектурил, а что в интерфейсах есть изъян, который нужно как можно скорее исправлять ему никто не скажет, ибо не хватит квалификации этот изъян распознать.

Даже тупой догадается, что что-то не так когда ему покажут универмаг костылей и подпорок для решения задачи. Проверено, разница в том что обычный программист эти костыли будет исправлять не самым элегантным образом.

Как делать проект со слабой командой я не знаю, и честно говоря, знать не хочу.

Это хорошо, закрыл глазки и спишь спокойно, только вот речь не о слабой команде, а о стабильных интерфейсах ныне 8) А о слабой команде речи нет, ибо если в сильную команду запихнуть новичка-студента (пусть даже умного) он будет слаб в силу отсутсвия опыта.

В каментах на быдлохабре. Искать по словам «водопад, спецификация, agile» и т.п. Еще в каментах всяких жжешников, но конкретные что-то не припомню.

Тоска, если мя на лоре забанили то в хабре вотще нефиг делать.

_________

//wfrr

Я Выфер и этим все сказанно.

И вообще, обращение «детка» и «милок» тебе не нравится, ты об этом меня предупреждал както и обвинял в дартаньянсве, обращение «милый» тоже вижу не по нраву, не ну что мне всех лор-овцами дражнить? Или перейти к официозу «гражданин» «коллега» «товарищ», это неинтересно 8)

_________

//wfrr

Я слышу слова не юноши но студента-фанатика свежепрочитаной книжки про «щас я вам расскажу как надо».

Оставь свои фантазии при себе.

Чудо, клиенты твоей платформы нихрена двигать не будут, они свалят с нее и все.

С линукса не сваливают. А вот бзд со своими хвалеными стабильными интерфейсами гниет.

И да, дизайн одними публичными интерфейсами не ограничивается. Публичные интерфейсы должны меняться, но щадяще. И вообще «про проектирование» интерфейсов я поверю только в контексте заказной разработки каких-нибудь унылых информационных систем. Для сложных проектов проектирование невозможно без прототипирования с последующими многократными рефакторингами, результатом которых будет выкристализация интерфейсов. Завиксировать предварительные интерфейсы в таком проекте означает смерть проекта, так как фиксация будет совершена тогда, когда меньше всего известно о правильности решения. Тут уж и высокая квалификация не спасет, тут не архитектор, а экстрасенс нужен :)

> Я Выфер и этим все сказанно.

Корона не жмёт?

Вообще у меня такое впечатление, что моя корона доставляет проблемы остальным, ты вот например меня по айпи забанил.

_________

//wfrr

Прально говоришь, до этого ты вообще утверждал что стабильность интерфейсов - зло.

А теперь скажи, в сем:

[quote]Для сложных проектов проектирование невозможно без прототипирования с последующими многократными рефакторингами, результатом которых будет выкристализация интерфейсов.[/quote] будет задестваована все 30 человек команды IRL, или 1-2 квалифицированных из 30, или студенты?

_________

//wfrr

Корбиновский динамический IP банить смысла нет, это кто-то другой.

Тогда извиняюсь.

_________

//wfrr

Мое видение нормальной команды такое: около 10 человек с мозгами, но разным опытом. Сложными архитектурными задачами с прототипированием занимаются время от времени все, но более опытные делают ревью менее опытным. Для не сложных задач всего 2 стадии: анализ задачи и реализация.