Задумаемся, насколько точно это определение: Ведь на ранних стадиях проекта и самой системы ещё нет — как можно говорить о ее свойствах? Только в качестве каких-то умозрительных представлений или описаний.
…
Соответственно, у всех остальных участников проекта тоже будут формироваться свои собственные (тоже умозрительные) представления, на основе одного и того же описания, сформированного аналитиком (причем, у каждого — своё, далеко не всегда и далеко не полностью согласованное с представлениями остальных участников).
…
Здесь как раз и проявляется слабость требований в привычном для аналитика смысле: Системные свойства в описаниях и умозрительных представлениях (и только). В противовес реальным свойствам "живой", пусть и через пень-колоду, но уже реально работающей системы.
Вот и получается, что аналитик "балуется игрушками", а тестер — занимается реальным делом с реальными вещами…
Мне кажется автор впадает в заблуждение или непонимание, считая требования аналитика к системе умозрительными, а работающую систему "живой" и более "реальной". Типа реально это то, что можно пощупать, а то что в головах, это все "придумки" и "умозрительные представления". Простите но "умозрительные представления" это требования заказчика оформленные в виде требований к системе, которая должна быть создана. Любая реальная работа начинается именно с таких "умозрительных представлений". Чтобы сделать шкаф, вы, или кто-то, придумывает его сначала в голове.
Другая проблема, чтобы эти требования были ясно изложены, и чтобы не возникало непонимания или искаженного толкования, это уже другая проблема аналитика. Возможно требующая отдельного обсуждения с участниками проекта.
Насчет проблем тестеров и тестирования. Требования к системе это уже по сути основа для написания тестов для еще не созданной системы! И правильнее как раз, еще до начала разработки, подключить тестера для написания тестов которые и будут проверять то, что система соответсвует вышеперечисленным требованиям. Это можно делать и параллельно с разработкой, но в этом случае возможна ситуация, когда тестер найдет какие-то несоответствия или противоречия, которые не заметил аналитик, и требования придется менять, включая разработку. Есть практика написания тестов до разработки, TDD, возможно тут как раз ей самое место.
Вообще ощущение, что автор работает в организации или проекте где нету такого понятия как командная работа, а есть атмосфера, где каждый конкурирует с каждым за звание быть самым умным и успешным. Это очень нездоровая атмосфера, которая в пределе может привести к краху организации или проекта.
Первый вопрос, который я бы задал, как такое может быть чтоб Владелец (С большой буквы!) продукта интересовался производительностью одного конкретного члена вашей команды. Можете объяснить?
И второй вопрос смысл этого опроса? Вы не уверены в своем решении? Хотите его аргументированно подать перед начальством? Разное?
Сейчас начал читать книгу Роберта Мартина «Чистая Архитектура» и возникает мысль что проффесионал, который хочет разбираться в архитектуре, не может этого сделать ничего не зная про бизнесс правила, например. Он не сможет правильно продумать архитектуру, правильно разделить классы между компонентами. Ничего не зная про предметную область, про потребности клиента, он не сможет адекватно и осознанно написать ни строчки кода под данную задачу. Он будет делать это слепо, механически. А любое слепое, механическое написание кода строго по спецификации может быть заменено на автомат, робот или ИИ с точки зрения парадигмы автоматизации процессов.
Любой проффесионал будет делать больше того, чем от него требуется на работе. Будет смотреть вокруг, что делается в его индустрии, какие тенденции и новые технологии появляются. Будет смотреть базу и основы тоже, в том числе и алгоритмы сортировки, деревья и связанные списки. Хотя бы потому, что это интересно и правильно разбираться в основах своей области, в ее истории. Ну и чтобы не изобретать велосипед, например. Более широкий кругозор всегда способствует поиску лучшего решения в своей повседневной работе.
В нашей команде был программист, который пользовался шифрованием не понимая как это работает и что есть открытый-закрытый ключ. Когда я ему об этом сказал, он посмотрел на меня очень круглыми глазами. Я даже сразу не понял что он этого действительно не знает и не понимает. Не нужно изучать две недели шифрование или язык ассемблер, но потратить немного времени для понимания что такое шифрование, какие виды его бывают и какое из них для чего, проффесионалу, я считаю, необходимо.
CRUD для простых запросов годится, но это не уровень проффесионала. Что вы со своим CRUD будете делать в базе данный где больше сотни таблиц и нужны сложные запросы?
Для того чтобы попробовать ML, я согласен, не нужно изучать углубленно математическую базу, но хотя бы понимать что происходит под капотом, какие возможности и ограничения дает эта технология, как правильно ее использовать и что нужно, чтобы самому обучить сеть.
«достойно и честно делать свою работу» — главная мысль статьи на мой взгляд, и я полностью под этим подписываюсь. Остальное все приложиться, и не будет погони за легкими и «раздутыми» деньгами, желанием побольше пустить пыль в глаза и перегретой экономики.
Не знал что есть такое, спасибо, возможно в этом есть дополнительные удобства организации и добавления тэгов, но самой программой tags4.info пользоваться неудобно, она зачем-то при тэгировании перетаскивает файлы в свою папку, плюс дает удалять сами файлы, тоже непонятно зачем. Я бы не рекомендовал эту программу в качестве каталогизатора. TaggedFrog выглядит получше, хоть и нету там иерархических тэгов.
Возможно это не совсем то что вы подумали, но из видео видно как в программе TaggedFrog работа с тэгами организована иерархически youtu.be/QTEd5cDNrmw?t=434
Мы тут с коллегами обсуждали как-то похожую ситуацию. Для одной знакомой нужно было найти подходящий способ организации её многолетней, многотерабайтной библиотеки видео файлов, хранящихся на разных носителях, с удобным поиском по разным критериям. В результате долгих споров отказались от идеи использовать напрямую файловую систему и пришли к выводу, что правильнее всего использовать каталог на основе тегов. В качестве более-менее удобного варианта остановились на программе TaggedFrog. Иерархический каталог тегов, запоминает файлы хранящиеся на сменных носителях. Единственное преимущество которое я увидел в вашей системе — доступ к каталогу через интернет с любого устройства. А так я не вижу причин почему вы не используете тэговую систему. Чем вас не устраивают тэги?
Ваша табличка доказала основную идею, к которой мы тоже пришли в результате споров и обсуждений — файловая система предназначена для хранения, а не для удобного извлечения файлов. Для извлечения нужен каталог. Кстати, как выяснилось, многие хранят этот каталог у себя в голове и у них вообще таких проблем не возникает ;) У них систематизированно хранилище и память настолько хорошая, что они просто помнят где в каких папках и что у них лежит, как книжки в домашнем шкафу ;)
Мне кажется автор впадает в заблуждение или непонимание, считая требования аналитика к системе умозрительными, а работающую систему "живой" и более "реальной". Типа реально это то, что можно пощупать, а то что в головах, это все "придумки" и "умозрительные представления". Простите но "умозрительные представления" это требования заказчика оформленные в виде требований к системе, которая должна быть создана. Любая реальная работа начинается именно с таких "умозрительных представлений". Чтобы сделать шкаф, вы, или кто-то, придумывает его сначала в голове.
Другая проблема, чтобы эти требования были ясно изложены, и чтобы не возникало непонимания или искаженного толкования, это уже другая проблема аналитика. Возможно требующая отдельного обсуждения с участниками проекта.
Насчет проблем тестеров и тестирования. Требования к системе это уже по сути основа для написания тестов для еще не созданной системы! И правильнее как раз, еще до начала разработки, подключить тестера для написания тестов которые и будут проверять то, что система соответсвует вышеперечисленным требованиям. Это можно делать и параллельно с разработкой, но в этом случае возможна ситуация, когда тестер найдет какие-то несоответствия или противоречия, которые не заметил аналитик, и требования придется менять, включая разработку. Есть практика написания тестов до разработки, TDD, возможно тут как раз ей самое место.
Вообще ощущение, что автор работает в организации или проекте где нету такого понятия как командная работа, а есть атмосфера, где каждый конкурирует с каждым за звание быть самым умным и успешным. Это очень нездоровая атмосфера, которая в пределе может привести к краху организации или проекта.
И второй вопрос смысл этого опроса? Вы не уверены в своем решении? Хотите его аргументированно подать перед начальством? Разное?
Сейчас начал читать книгу Роберта Мартина «Чистая Архитектура» и возникает мысль что проффесионал, который хочет разбираться в архитектуре, не может этого сделать ничего не зная про бизнесс правила, например. Он не сможет правильно продумать архитектуру, правильно разделить классы между компонентами. Ничего не зная про предметную область, про потребности клиента, он не сможет адекватно и осознанно написать ни строчки кода под данную задачу. Он будет делать это слепо, механически. А любое слепое, механическое написание кода строго по спецификации может быть заменено на автомат, робот или ИИ с точки зрения парадигмы автоматизации процессов.
Любой проффесионал будет делать больше того, чем от него требуется на работе. Будет смотреть вокруг, что делается в его индустрии, какие тенденции и новые технологии появляются. Будет смотреть базу и основы тоже, в том числе и алгоритмы сортировки, деревья и связанные списки. Хотя бы потому, что это интересно и правильно разбираться в основах своей области, в ее истории. Ну и чтобы не изобретать велосипед, например. Более широкий кругозор всегда способствует поиску лучшего решения в своей повседневной работе.
CRUD для простых запросов годится, но это не уровень проффесионала. Что вы со своим CRUD будете делать в базе данный где больше сотни таблиц и нужны сложные запросы?
Для того чтобы попробовать ML, я согласен, не нужно изучать углубленно математическую базу, но хотя бы понимать что происходит под капотом, какие возможности и ограничения дает эта технология, как правильно ее использовать и что нужно, чтобы самому обучить сеть.
Ваша табличка доказала основную идею, к которой мы тоже пришли в результате споров и обсуждений — файловая система предназначена для хранения, а не для удобного извлечения файлов. Для извлечения нужен каталог. Кстати, как выяснилось, многие хранят этот каталог у себя в голове и у них вообще таких проблем не возникает ;) У них систематизированно хранилище и память настолько хорошая, что они просто помнят где в каких папках и что у них лежит, как книжки в домашнем шкафу ;)