О, я имел в виду то, что это достаточно формализованный процесс. Но раз вам нравилось… Думаю, это проблема мировоззрения - мне претит излишняя бюрократия и формализм.
Насчёт развёртывания, так его уже давно можно говорить по-русски, все поймут. Деплоймент же меня смущает, знаете, как в книге, где переводчик затруднился перевести термин.
Ну, и если надо где-то развёртывать проект, то естественно изучить, что есть и что надо, поэтому план развёртывания нужен. Но воротить большой док с описанием всех процессов? Для этого надо иметь огромную команду с очень плохой координацией, либо очень плохие условия.
Я ещё раз повторюсь насчёт того, что определить, что необходимо получить в итоге - правильно и просто обязательно. Сюда, вполне естественно, входят требования к продукту и его архитектура.
Но описывать кто в команде чем занимается - это уже слишком. Это не команда, если её член не знает чем он занимается. Если же люди не знают, что делать и куда приложить силы, это проблема координации. И уж тем более, есть какая-то проблема, если кто-то в середине проекта вдруг стал недоволен.
Таким образом - предварительному планированию, сбору требований и созданию архитектуры - да. Описанию процедуры развёртывания, особенное если оно сложное - естественно да. А остальному - нет. Никаких описаний кто в команде чем занимается. Никаких попыток описать все процессы, выполняемые человеком и свести их в документ. Описать все процессы невозможно, а человек - не робот.
Напишите про гораздо более важные вещи, я почитаю.
Качество кода, естественно не определяет качество продукта полностью, но частично - точно.
Успех нужен не продукту, это вы привираете ;) Успех нужен верхнему эшелону руководства.
А если вернуться к исходной записи, то координация - необходимая вещь, даже если ты работаешь один. Естественно, что при большой команде координироваться надо лучше. Но для этого вовсе не обязательно переводить килограммы бумаги.
Ничего страшного, что вы посмотрели мой профиль в МоёмКруге, хоть какая-то от него польза ;) Восприятие средних и крупных проектов бывает разное, я затрудняюсь ответить. Документов у нас хватает, поверьте. Я уже горю желанием кое-что поменять в их системе. И я этого добьюсь ;)
Минимально необходимые документы - это план того, что нужно сделать. Называть его можно по-разному. Всё остальное тоже очень желательно, но план - нужен.
Чёткость должна быть, не спорю. Но представьте себе разработку по RUP? Это, знаете, такая беда больших компаний - излишняя формализация всего. Плюс, человек сам очень гибок, зачем его сковывать излишними методологиями?
Я понимаю, что не тотальная ;) Но долгий путь начинается с одного маленького шага. Воспроизвёл неточно, но суть осталась.
Да, конечно, для начинающих, которые хотят сразу встать на скользкую дорогу тотальных стандартизаций я написал пол страницы текста, не имеющего отношения…
1. Я говорил о контексте «В-третьих, для того чтобы не произошла ситуация, что оба программиста одновремено разрабатывают класс…»
2. Это естественно. Но всё же я считаю, что клиент не должен иметь решающего слова в определении качества, потому что, как я уже писал, разработчики неохотно работают над тем, что не удовлетворяет их стандартам качества.
3. Если команде нужны стандарты для описания зон ответственности и правила взаимодействия, то скорее всего это не команда.
4. Команда разработчиков - это команда разработчиков. Если вы приглядитесь, то увидите, что менеджеры всё-таки находятся в стороне, если, конечно, не принимают активное участие в проекте. А остальные товарищи представляют собой отдельные команды со своими проблемами.
Не зря вы представляете недовольные лица людей - предварительная подготовка необходима и полезна, спору нет. Стандарты тоже замечательны, пока их не слишком много. И про выбор частей вы правильно думаете.
А вот использовать стандарты для описания того, кто чем занимается - это как? Я не понимаю. Лист требований - это тоже не стандарты. Использование системы контроля версий естественно разрешает проблему с кодом. Если вы не хотите разрешать конфликты версий - что ж, координируйте работу людей. Как это они у вас пишут один участок кода?
Определить, что вы хотите получить в итоге - это правильно. Но по списку требований вы не определите качества никогда. В проекте есть два качества - то, которое определяют программисты и то, которое определяет клиент. Если вы заставите программистов работать над продуктом, качество которого определяет клиент, они вряд ли будут довольны - качество клиента обычно ниже и из-за этого снижаются сроки. Из-за сниженных сроков программист вынужден писать менее качественный код, что противоречит его стандартам качества. Такой ситуации надо избегать - когда люди недовольны тем, что они делают, они делают это неохотно. Плюс, единственное. что будет волновать этих людей - когда же наконец выйдут из этого проекта.
Если у вас в середине проекта кто-то что-то говорит, значит:
Вы не знаете навыков своих людей
Вы не умеете ими управлять
Люди не хотят делать этот проект
Третий пункт наиболее важный - что-то случилось, из-за чего люди хотят избежать работы над проектом.
Вы же, вместо того, чтобы анализировать ситуацию и привести её в порядок, чтобы люди хотели работать над проектом, лишь добавляете бумажек, думая, что это спасёт ваш проект. А как у вас с текучестью кадров?
Дело тут не в разработчиках вовсе - то, что вы описали, надо сделать с каждым ныне живущим. Потому как я сильно сомневаюсь, что кто-то вообще много думает о людях с ограниченными возможностями. К сожалению это данность.
Кому-то рано, а кому-то нет. Согласен, что многие ещё не дошли до чистого кода. Чистый код, в моём понимании, это как раз и есть семантичный код, когда каждый элемент использован по смыслу.
А про alt… Что тут сказать. Его вообще стали писать лишь потому, что из-за него не валидируется код. Смысл же его - в предоставлении альтернативного описания.
1. Пишите на английском. Он роднее для html, чем русский.
2. Знаете, если всё в жизни стандартизовать, то жить станет трудно. Опечатаетесь - рано или поздно заметите и поправитесь. Если же вам надо, чтобы какое-нибудь интеллисенс выдавало список вариантов, то напишите расширение для своего редактора.
Текст ссылки обладает заметным в настоящее время преимуществом - его индексируют и учитывают поисковики. Ничто на свете не мешает парсить вместо rel/rev тот же текст ссылки, разыскивая в нем нужные слова. Мешает только лень (атрибут тэга куда как легче прочитать).
То, что текст индексируют поисковики - это преимущество для оптимизаторов, не более. А при парсинге, совсем ничто не мешает парсить rel вместе с содержанием ссылки. Единственное неприятное, что сложность человеческого языка будет затруднять «понимание» компьютером смысла содержания ссылки. Это касается и rel, но в меньшей степени - уже сейчас есть широко распространённые и принятые значения этого атрибута.
Все хотят кушать, а многие хотят ещё и экономить. Возьмём эти два хотения, положим их в шейкер и хорошенько перемешаем. Что получим на выходе? - конечно, ту самую свалку.
Интернет сейчас стал почти общедоступным, поэтому стоит привыкать к мысли, что мы здесь далеко не одни. Почему так случилось - снова, кто-то хочет кушать и, судя по масштабам, хочет кушать много ;)
У каждого своё внутреннее мерило необходимого качества. Поэтому, кто-то пойдёт и попросит знакомого начинающего (знакомые бывают всякие) веб-что-то-то-там'а сделать ему сайт или сам «сделает» сайт. Другой же пойдёт к более профессиональным разработчикам. Даже у самих разработчиков внутренние стандарты сильно разнятся - кому-то необходима валидность, а кому-то на неё наплевать.
Оптимизаторы, поверьте мне, появились совсем не от желания помочь людям в поиске.
А вообще, поймите, что ничто так не оттенит ваши таланты, как несостоятельность других. Но важно не останавливаться в развитии - это равносильно смерти.
Идея хорошая, правда не знаю, как у такого подхода с доступностью (accessibility).
Вот, посмотрел код. Лучше сделать так, чтобы js был ненавязчивым (unobtrusive), иначе такой подход сойдет лишь в веб-настольных-приложениях, в которых работают молодые и здоровые люди.
Насчёт развёртывания, так его уже давно можно говорить по-русски, все поймут. Деплоймент же меня смущает, знаете, как в книге, где переводчик затруднился перевести термин.
Ну, и если надо где-то развёртывать проект, то естественно изучить, что есть и что надо, поэтому план развёртывания нужен. Но воротить большой док с описанием всех процессов? Для этого надо иметь огромную команду с очень плохой координацией, либо очень плохие условия.
Я ещё раз повторюсь насчёт того, что определить, что необходимо получить в итоге - правильно и просто обязательно. Сюда, вполне естественно, входят требования к продукту и его архитектура.
Но описывать кто в команде чем занимается - это уже слишком. Это не команда, если её член не знает чем он занимается. Если же люди не знают, что делать и куда приложить силы, это проблема координации. И уж тем более, есть какая-то проблема, если кто-то в середине проекта вдруг стал недоволен.
Таким образом - предварительному планированию, сбору требований и созданию архитектуры - да. Описанию процедуры развёртывания, особенное если оно сложное - естественно да. А остальному - нет. Никаких описаний кто в команде чем занимается. Никаких попыток описать все процессы, выполняемые человеком и свести их в документ. Описать все процессы невозможно, а человек - не робот.
Ни один проект не начнётся без людей ;)
Качество кода, естественно не определяет качество продукта полностью, но частично - точно.
Успех нужен не продукту, это вы привираете ;) Успех нужен верхнему эшелону руководства.
А если вернуться к исходной записи, то координация - необходимая вещь, даже если ты работаешь один. Естественно, что при большой команде координироваться надо лучше. Но для этого вовсе не обязательно переводить килограммы бумаги.
Минимально необходимые документы - это план того, что нужно сделать. Называть его можно по-разному. Всё остальное тоже очень желательно, но план - нужен.
Чёткость должна быть, не спорю. Но представьте себе разработку по RUP? Это, знаете, такая беда больших компаний - излишняя формализация всего. Плюс, человек сам очень гибок, зачем его сковывать излишними методологиями?
Я понимаю, что не тотальная ;) Но долгий путь начинается с одного маленького шага. Воспроизвёл неточно, но суть осталась.
Впрочем, это моё восприятие.
2. Это естественно. Но всё же я считаю, что клиент не должен иметь решающего слова в определении качества, потому что, как я уже писал, разработчики неохотно работают над тем, что не удовлетворяет их стандартам качества.
3. Если команде нужны стандарты для описания зон ответственности и правила взаимодействия, то скорее всего это не команда.
4. Команда разработчиков - это команда разработчиков. Если вы приглядитесь, то увидите, что менеджеры всё-таки находятся в стороне, если, конечно, не принимают активное участие в проекте. А остальные товарищи представляют собой отдельные команды со своими проблемами.
А вот использовать стандарты для описания того, кто чем занимается - это как? Я не понимаю. Лист требований - это тоже не стандарты. Использование системы контроля версий естественно разрешает проблему с кодом. Если вы не хотите разрешать конфликты версий - что ж, координируйте работу людей. Как это они у вас пишут один участок кода?
Определить, что вы хотите получить в итоге - это правильно. Но по списку требований вы не определите качества никогда. В проекте есть два качества - то, которое определяют программисты и то, которое определяет клиент. Если вы заставите программистов работать над продуктом, качество которого определяет клиент, они вряд ли будут довольны - качество клиента обычно ниже и из-за этого снижаются сроки. Из-за сниженных сроков программист вынужден писать менее качественный код, что противоречит его стандартам качества. Такой ситуации надо избегать - когда люди недовольны тем, что они делают, они делают это неохотно. Плюс, единственное. что будет волновать этих людей - когда же наконец выйдут из этого проекта.
Если у вас в середине проекта кто-то что-то говорит, значит:
Третий пункт наиболее важный - что-то случилось, из-за чего люди хотят избежать работы над проектом.
Вы же, вместо того, чтобы анализировать ситуацию и привести её в порядок, чтобы люди хотели работать над проектом, лишь добавляете бумажек, думая, что это спасёт ваш проект. А как у вас с текучестью кадров?
А про alt… Что тут сказать. Его вообще стали писать лишь потому, что из-за него не валидируется код. Смысл же его - в предоставлении альтернативного описания.
2. Знаете, если всё в жизни стандартизовать, то жить станет трудно. Опечатаетесь - рано или поздно заметите и поправитесь. Если же вам надо, чтобы какое-нибудь интеллисенс выдавало список вариантов, то напишите расширение для своего редактора.
То, что текст индексируют поисковики - это преимущество для оптимизаторов, не более. А при парсинге, совсем ничто не мешает парсить rel вместе с содержанием ссылки. Единственное неприятное, что сложность человеческого языка будет затруднять «понимание» компьютером смысла содержания ссылки. Это касается и rel, но в меньшей степени - уже сейчас есть широко распространённые и принятые значения этого атрибута.
Интернет сейчас стал почти общедоступным, поэтому стоит привыкать к мысли, что мы здесь далеко не одни. Почему так случилось - снова, кто-то хочет кушать и, судя по масштабам, хочет кушать много ;)
У каждого своё внутреннее мерило необходимого качества. Поэтому, кто-то пойдёт и попросит знакомого начинающего (знакомые бывают всякие) веб-что-то-то-там'а сделать ему сайт или сам «сделает» сайт. Другой же пойдёт к более профессиональным разработчикам. Даже у самих разработчиков внутренние стандарты сильно разнятся - кому-то необходима валидность, а кому-то на неё наплевать.
Оптимизаторы, поверьте мне, появились совсем не от желания помочь людям в поиске.
А вообще, поймите, что ничто так не оттенит ваши таланты, как несостоятельность других. Но важно не останавливаться в развитии - это равносильно смерти.
Вот, посмотрел код. Лучше сделать так, чтобы js был ненавязчивым (unobtrusive), иначе такой подход сойдет лишь в веб-настольных-приложениях, в которых работают молодые и здоровые люди.
Удачи.
Цитати из Человеческого фактора, который я сейчас читаю. И я вполне согласен с Листером и ДеМарко.
Для почитать - глава 4.