я выявил два вполне серьезных косяка в процессе стройки
это вам очень повезло, что всего два
впоследствии оказалось, что без обмана строительная индустрия не работает
а вы думали, что шутки из ниоткуда появились?) эти ребята еще хуже чем ИТ.
для частного застройщика всё еще хреновше: он для экономии выбирает подрядчика без договора (с договором и ответственностью хотя бы на бумаге стоимость увеличивается в несколько раз). Даже с договором всё негладко — вы же хотите дом достроить, а не заниматься судебными тяжбами.
я только два приема нашел, как бороться с недобросовестностью строителей:
1. никогда не платить вперед, только за выполненную работу. так по крайней мере остается возможность удержать со строителей часть суммы для исправления проблем
2. никогда не доверять большой объем важной работы. пусть покажут себя на небольшом и некритичном участке. да могут сделать плохо, но это будут тактические ошибки, которые дешевле исправить
читая Вас, VolCh, я слышу вот что:
— у нас бывает код плохого качества
— ну это изза психологии, да и делать качественно оказывается дорого.
— аа, хорошо, оставим всё как есть
вы говорите, проблема психологического характера, а решения не предлагаете. то что вы делаете — это попытка объяснить происходящее и примириться с ним. вообще это один из способов решения проблем. пусть так.
я же на это смотрю так: вы можете пожертовать качеством, чтобы сделать быстрее/дешевле, пойти не полному процессу производства софта, а срезать углы. бородатая тактика управления содержанием проекта.
может быть те дефекты, которые появляются изза доработок, не влияют на бизнес, бизнес модель их демпфирует без последствий для продаж и клиентов. ну так и вообще всё замечательно в этом случае — не нужны тяжеловесные процессы, можно больше сфокусироваться на фичах и меньше на тест-активностях.
Важно помнить, что любой возврат кода на доработку не лучшим образом сказывается на качестве реализации.… Опыт показывает, что большинство таких ситуаций оборачивается багами именно в тех местах, где были правки по результатам ревью кода. Так работает человеческая психология.
это не психология, зачем вы так расплывчато описывает причину. это невнимательность или высокая самооценка разработчиков (может быть чтото еще, не знаю вашу команду). с вашими рассуждениями можно дойти до выводов, что вообще не нужно возвращать кода на доработку. или не стоит баги фиксить, потому что изза психологии разработчики добавят новых багов.
можно ли было баги, внедренные после доработки, обнаружить на второй итерации кодревью? может быть второе ревью было поверхностным? что если его усилить чек-листами, гайдлайнами, автоматизированными проверками
противоречивые шаги вы предлагаете: сначала «важно найти ошибку как можно раньше», а потом «отключайте все сообщения». начинается всё с характеристик качества продукта — что именно хотите проверять анализатором. предложили бы отключать некоторые классы сообщений, которые минорные с точки зрения уязвимостей. ну например, про дублирование кода. а то так можно сообщение про sql injection отключить, а потом и не вспомнить про него.
SQALE-пирамида, например, как раз один из способов приоритезации сообщений анализатора.
Как показывает практика, эти старые ошибки менее критичны, иначе приложение бы просто не работало.
может быть. а может быть проверяемый код до полноценного production'а не дошел, вот и не проявлялись такие ошибки. зависит от момента времени внедрения статического анализа в жизненный цикл продукта.
Кажется habradante довольно хорошо передал суть;)
Статья — не список рецептов типа «нанимайте черных, белых, женщин и детей», не стоит трактовать ее так. Автор говорит о том, что хайринг людей в компании происходит в том числе по критерию «а впишется ли кандидат в нашу тусовку? будет ли комфортно с ним работать?». То есть набирают подобных себе, и в этом нет ничего плохого. Проблема же может быть в том, что все ориентированы в некотором направлении, но в том ли, которое требует бизнес. Дело не только в хайринге — если в компании белых оказался цветной человек, и культура компании не принимает цветных, то вероятно со временем он уйдет, культура его выдавит, и разнообразие останется прежним.
А минус разнообразия — похожий взгляд на проблемы и их решения, никому и в голову не приходит посмотреть с других точек зрения. Что-то вроде низкой общей креативности всего коллектива.
Видел случаи когда пилили прототип, а потом заказчик сказал идти в продакшн.
а что заказчику обещали? production-ready систему или прототип на-посмотреть?
возможно ожидания у заказчика были выставлены неудачно
Всегда пишите так, как будто этот код — критически важен для проекта.
мне кажется, такой подход плохо сработает, если вы используете новые для себя технологии (библиотеки, инструменты — всё, что относится к разработке). Как бы не был важен этот функционал, будет трудно принимать решения «как лучше его реализовать», потому что в начале не хватает опыта. ИМХО, новая предметная область тоже может влиять — откуда бы мне, разработчику, знать, что вне РФ нет такой сущности как ИНН, так что я честно делаю ИНН ключом:)
я клоню к тому, что вы много времени потратите с таким подходом.
есть же прототипы, которые делаются только с целью proof-of-concept: разработали, научились, собрали ошибки, в следующем прототипе или в новой системе сделаете правильно в заданном контексте. на самом деле этот подход тоже небыстрый, но более эффективный с точки зрения вашего обучения и с большей обратной связью от пользователей/заказчика.
было б интересно узнать, как бороться с чрезвычайно активными людьми на митинге, которые либо уходят в глубокие детали по каждому вопросу либо рассказывают истории по каждому поводу. NataKo, как вы справляетесь с такими ситуациями?
понятно.
ваш пример искусственно уменьшает пользу от работы с рисками. вы почему-то считаете, что Estee тратит 1млн, а ущерб от попадание в банк не уменьшается. на 1млн можно построить филиал банка и половину денег перенести на хранение туда. Или построить кораблеубежища и складировать деньги в них. Или обнести этот банк «железным занавесом» из ню-плазмо-поля коль скоро у нас инопланетные корабли падают на Землю. А возможно биткоины уже единственная валюта, а банк на ЭДО, так что нам нужна миграция данных и диски Estee перевезёт на грузовиках.
хороший риск менеджмент может быть не заметен с первого взгляда. как и тестирование софта. может тогда и тестировать не стоит? и так всё работает, а эти тестеры и тест менеджеры только бюджет отъедают — если ошибки нет, то и ОК, а будет — так и не им исправлять. взгляните на тестирование как на меры против риска получить некачественный софт
странное у вас видение. логичнее бы сначала описать бизнес проблему, затем цели и ключевые показатели, и потом риски, которые будут нам сопутствовать от проблемного состояния до целевого.
потом были бы требования, ограничения, стейкхолдеры.
или тут есть какой-то скрытый смысл?
ну не всегда же справляются. и тогда отчеты по времени помогают понять, на каких задачах у сотрудников overbudget. Представьте, командная оценка по интеграции двух подсистем 1 человеко-неделя, а оказалось две, но вы не знаете, что ошиблись в два раза, как команда в следующий раз сможет избежать похожей проблемы? а так проведут ретроспективу (на которой все данные уже есть, не нужно выковыривать их из трекера, вспоминать, а сколько же мы потратили на интеграцию) и есть шанс понять причину. И для руководства хорошо — в следующий раз оно увеличит длительность на 1 неделю и не придётся перед заказчиком краснеть
если отдел состоит из людей, которые пришли отсидеть рабочее время, то им и таймшиты не помогут, как вы сказали, у них другай проблема)
это вам очень повезло, что всего два
а вы думали, что шутки из ниоткуда появились?) эти ребята еще хуже чем ИТ.
для частного застройщика всё еще хреновше: он для экономии выбирает подрядчика без договора (с договором и ответственностью хотя бы на бумаге стоимость увеличивается в несколько раз). Даже с договором всё негладко — вы же хотите дом достроить, а не заниматься судебными тяжбами.
я только два приема нашел, как бороться с недобросовестностью строителей:
1. никогда не платить вперед, только за выполненную работу. так по крайней мере остается возможность удержать со строителей часть суммы для исправления проблем
2. никогда не доверять большой объем важной работы. пусть покажут себя на небольшом и некритичном участке. да могут сделать плохо, но это будут тактические ошибки, которые дешевле исправить
— у нас бывает код плохого качества
— ну это изза психологии, да и делать качественно оказывается дорого.
— аа, хорошо, оставим всё как есть
вы говорите, проблема психологического характера, а решения не предлагаете. то что вы делаете — это попытка объяснить происходящее и примириться с ним. вообще это один из способов решения проблем. пусть так.
я же на это смотрю так: вы можете пожертовать качеством, чтобы сделать быстрее/дешевле, пойти не полному процессу производства софта, а срезать углы. бородатая тактика управления содержанием проекта.
может быть те дефекты, которые появляются изза доработок, не влияют на бизнес, бизнес модель их демпфирует без последствий для продаж и клиентов. ну так и вообще всё замечательно в этом случае — не нужны тяжеловесные процессы, можно больше сфокусироваться на фичах и меньше на тест-активностях.
это не психология, зачем вы так расплывчато описывает причину. это невнимательность или высокая самооценка разработчиков (может быть чтото еще, не знаю вашу команду). с вашими рассуждениями можно дойти до выводов, что вообще не нужно возвращать кода на доработку. или не стоит баги фиксить, потому что изза психологии разработчики добавят новых багов.
можно ли было баги, внедренные после доработки, обнаружить на второй итерации кодревью? может быть второе ревью было поверхностным? что если его усилить чек-листами, гайдлайнами, автоматизированными проверками
а «системный подход» не от слова «система»?
SQALE-пирамида, например, как раз один из способов приоритезации сообщений анализатора.
может быть. а может быть проверяемый код до полноценного production'а не дошел, вот и не проявлялись такие ошибки. зависит от момента времени внедрения статического анализа в жизненный цикл продукта.
Статья — не список рецептов типа «нанимайте черных, белых, женщин и детей», не стоит трактовать ее так. Автор говорит о том, что хайринг людей в компании происходит в том числе по критерию «а впишется ли кандидат в нашу тусовку? будет ли комфортно с ним работать?». То есть набирают подобных себе, и в этом нет ничего плохого. Проблема же может быть в том, что все ориентированы в некотором направлении, но в том ли, которое требует бизнес. Дело не только в хайринге — если в компании белых оказался цветной человек, и культура компании не принимает цветных, то вероятно со временем он уйдет, культура его выдавит, и разнообразие останется прежним.
А минус разнообразия — похожий взгляд на проблемы и их решения, никому и в голову не приходит посмотреть с других точек зрения. Что-то вроде низкой общей креативности всего коллектива.
ОК, но ваша fopen5 тоже принимает параметр по указателю — const char* mode. или есть на то причина? как с ним быть?
а что именно станет быстрее?
если эти фото такое впечатление оставили, посмотрите другие:
или приезжайте посмотреть — доступ свободный
а что заказчику обещали? production-ready систему или прототип на-посмотреть?
возможно ожидания у заказчика были выставлены неудачно
мне кажется, такой подход плохо сработает, если вы используете новые для себя технологии (библиотеки, инструменты — всё, что относится к разработке). Как бы не был важен этот функционал, будет трудно принимать решения «как лучше его реализовать», потому что в начале не хватает опыта. ИМХО, новая предметная область тоже может влиять — откуда бы мне, разработчику, знать, что вне РФ нет такой сущности как ИНН, так что я честно делаю ИНН ключом:)
я клоню к тому, что вы много времени потратите с таким подходом.
есть же прототипы, которые делаются только с целью proof-of-concept: разработали, научились, собрали ошибки, в следующем прототипе или в новой системе сделаете правильно в заданном контексте. на самом деле этот подход тоже небыстрый, но более эффективный с точки зрения вашего обучения и с большей обратной связью от пользователей/заказчика.
ваш пример искусственно уменьшает пользу от работы с рисками. вы почему-то считаете, что Estee тратит 1млн, а ущерб от попадание в банк не уменьшается. на 1млн можно построить филиал банка и половину денег перенести на хранение туда. Или построить кораблеубежища и складировать деньги в них. Или обнести этот банк «железным занавесом» из ню-плазмо-поля коль скоро у нас инопланетные корабли падают на Землю. А возможно биткоины уже единственная валюта, а банк на ЭДО, так что нам нужна миграция данных и диски Estee перевезёт на грузовиках.
хороший риск менеджмент может быть не заметен с первого взгляда. как и тестирование софта. может тогда и тестировать не стоит? и так всё работает, а эти тестеры и тест менеджеры только бюджет отъедают — если ошибки нет, то и ОК, а будет — так и не им исправлять. взгляните на тестирование как на меры против риска получить некачественный софт
странное у вас видение. логичнее бы сначала описать бизнес проблему, затем цели и ключевые показатели, и потом риски, которые будут нам сопутствовать от проблемного состояния до целевого.
потом были бы требования, ограничения, стейкхолдеры.
или тут есть какой-то скрытый смысл?
О каком решении идёт речь?
если отдел состоит из людей, которые пришли отсидеть рабочее время, то им и таймшиты не помогут, как вы сказали, у них другай проблема)