Уникальные идентификаторы для связи исходников. Как?
Хочу странного, может подскажете способ сделать.
Итак, хочу вести список фичей (в репозитории, рядом с исходниками) и когда пишу логику (тесты, документацию, вёрстку) иметь возможность поставить какой-то идентификатор рядом с реализацией (тестом, документацией, вёрсткой). Дескать вот тут реализуется (тестируется, документируется, отображается) именно эта фича. И потом по этим кроссылками генерировать всякую полезную аналитику.
Фичей не в смысле больших user-story, а в смысле конкретных пунктов, реализацию которых надо контролировать. Например «имя гильдии должно быть уникально», «Это поле должно отображаться только залогиненому пользователю».
Фактически я уже так работаю, записывая каждую мелкую фичу в туду-листе и удаляя их по факту реализации. Не хочется, чтобы знания терялись. Логичный следующий шаг — хранить историю фичей и их реализации.
Вопрос вот в чём: как делать идентификаторы, которые будут связывать фичи с кодом?
Варианты, которые вижу:
- Писать руками. Проблемы: геморрой и простор для ошибок/опечаток.
- Плагин для emacs (любого другого редактора), который в файле с фичами генерирует уникальные идентификаторы, после чего копировать их куда надо. Проблемы: его надо сделать, нужно поддерживать уникальность между файлами, хочу фичи не только в отдельном файле, но и в коде, если это будет удобно.
- Литературное программирование: писать фичу сразу там, где реализуется. Проблемы: фича реализуется в нескольких местах (код, тесты, вёрстка, документация), поэтому идентификаторы всё равно нужны.
- Идентификатором делать сам текст фичи. Проблемы: занимает много места, текст может меняться и будет геморойно менять его везде.
О книге «Кровь, пот и пиксели» — производственные сказки на ночь
Один мальчик очень хотел сделать игру. Он закрылся на пять лет, жил за счёт своей девушки, много работал, очень много работал, выпустил игру, заработал миллионы и всё ещё отходит от стресса.
Несколько мальчиков и девочек хотели сделать свою игру, потому что на работе делали игры, но не те. Они уволились, очень много работали, немного поругались, помирились, выпустили таки игру и заработали миллионы.
Много мальчиков и девочек долго и упорно делали игры про джедаев, но у них как-то не получалось, потом у них начало получаться, но их купил Дисней и закрыл к чертям.
Про кражу результатов выполнения тестовых заданий
Каррикатура из неизвестного источника. Если вы знаете кто автор, сообщите, пожалуйста.
По правде сказать, меня всегда выбешивали опасения что кто-то там украдёт чью-то работу по тестовому заданию. А тут на DTF очередной пост по этому поводу , так что я решил высказаться.
Ну бред же, ей богу. Бред сивой кобылы.
У нашего ИТ (не геймдева), действительно, есть похожая проблема. Но она заключается не в том, что у соискателей работу воруют. Она заключается в том, что соискатели думают что их тестовое задание в принципе возможно использовать в чём-то, кроме оценки их компетенций. Сюда же можно добавить школоту, которая считает, что можно набрать таких заданий и собрать из них рабочий проект. Последнее реально чистая школота из вконтактика, поэтому даже говорить об этом нет смысла.
Проблема не в злых конторах, а в кадрах у которых квалификация катастрофически не соответствует ЧСВ.
А работы ваши не нужны потому, что в любом долгосрочном проекте важны не N строк кода (картинок, нот, etc.), а человек который их создал, который в голове держит концепцию их создания, план развития, связи с другими частями проекта и прочее. Без этой информации такая работа - камень на шее проекта, который тянет его на дно.
Кроме того, обвинять конторы в том, что они украли что-то и выпустили - ещё большая ерунда. Люди не случайно принимают решения, а мозгом пользуются. Ну, некоторые из них. Если вам пришла в голову какая-то идея, то она пришла и к десятку других людей. Если идея толковая, её уже делают. Посмотрите хотя бы на недавние анонсы игровых облачных платформ. Никто же не обвиняет Apple, Google и прочих, что они друг у друга идеи стырили. Нет, они делают то, что диктует рынок.
А идеям без реализации цена 10 центов за дюжину.
Изменение восприятия сложности
Написал философской рефлексии пост про изменение восприятия сложности за последние полвека.
Когда надо слушать пользователей
Вечные направления.
Первое, чему учат начинающего разработчика — это не слушать хотелки своих пользователей. Умение игнорировать чужие идеи даже важнее урезания фич, не говоря уже о какой-то там монетизации. Начнёте потакать им (или менеджменту, хе-хе) и всё, считай нет продукта, вместо него адская химера.
Конечно, в реальной жизни всё не так однозначно и данное табу полезно только для неокрепших умов. Мы же люди опытные, поэтому вместо безусловного запрета подведём небольшую теоретическую базу под этот вопрос. Ладно, не теоретическую базу, просто хочу сделать пару заметок.
Так кого и когда необходимо слушать при разработке ПО?