Comments 15
Любой разработчик приходит к таким рассуждениям. Потом с бОльшим опытом приходит к другим: есть заказчик и он хочет качественно через месяц, а качественно можно сделать только за 2, и невозможно заказчику ничего объяснить про долгосрочные последствия и недоделанность, ему нужно через месяц. Поэтому выбор между сделать плохо за месяц или не делать вообще.
Иногда еще метрикой "дорого" можно поиграться, но крайне нечасто. Дорого чаще всего означает привлечь людей с опытом и навыками подходящими под задачу. Но люди не машины, они не могут появиться ровно тогда, когда нужно. Люди после этой задачи дальше тоже чем-то должны заниматься. Долгосрочное обучение джунов возможно только для долгосрочных проектов. И т.д.
Мне кажется, речь в статье немного о другом
Или ты пишешь качественно, или нет, вот и все. Если качественно, то часто результат получается ещё и быстрее, потому что просто меньше косяков надо исправлять. И качественная архитектура (не код) тоже ускоряет последующую доработку продукта.
Я именно об этом. Качественно это всегда про долгосрок. Для срочной задачи, где нужно выдать какой-то результат уже сейчас, невозможно сделать и архитектуру и тесты и стиль и прочее. Если "пишешь качественно", то просто не успеваешь.
Речь конечно не идет о каких-то примитивных задачках, где действительно стиль, комментарии, тесты и документация сильно не повлияют на время реализации, но сильно упростят последующее сопровождение. В сложных же проектах, когда нужно интегрироваться с разными продуктами, когда нужно вносить изменения в существующую систему, разница между нормальной предварительной проработкой (архитектура, интерфейсы, планирование) и "хуяк-хуяк и в продакшен" очень большая.
В разработке, как процессе, нет никакого треугольника качества. Ты можешь делать либо быстро и качественно, либо медленно и плохо
Удивительное умозаключение, согласно которому качество софта прямо зависит от количества времени, данного на разработку.
Чтобы вообще начинать говорить о качестве, нужно определить термин. Качество, оно про что? Про соответствие спецификации? Про соответствие субъективным ожиданиям (!= спецификация/тз) заказчика? Про дешевизну поддержки? Про когнитивную сложность кода? Про перфоманс? Про конверсию?
Скорее всего, какая-то совокупность множества факторов, индивидуальная для каждого бизнеса/заказчика. Хрупкая, субъективная модель, которая сильно зависит от среды. Поменяли тех.директора/лида/руководителя/менеджера/потребителя/бизнес модель/инвестора/производственную методологию — сменились критерии.
Из этого вообще никак не следует, что качество и время выделенное на разработку, как-то связаны, а именно с этого нужно начинать разговор.
Быстро и качественно не бывает априори. А в аджайле где тебе в самом конце говорят что надо 70% переписать это ещё и означает что всё что до этого успели сделать надо переделать или выкинуть. Другое дело медленный подход когда каждый шаг продумываешь и переспрашиваешь, а нахера оно нужно и почему именно так, тогда в конце выйдет более менее похожее на то что заказчик хотел на самом деле и предусмотрены решения для будущих проблем и возможности расширения. Вот это и есть показатели качества. Если нет тестов то значит всё писалось на коленке не продумывая и последние изменения могут сломать вообще всё.
Код это то что в конце должно создать логичную модель бизнеса, но заказчик редко имеет у себя в голове такую модель, а если ещё начнёт новые куски лепить на это всё то без покрытия тестами всех кейсов + невалидные кейсы всё может в любой момент отвалиться. Поэтомы домейн дривен и тест дривен подходы нужны и именно они помогают найти проблемы в логике и самой модели.
Еще бы экспериментальные данные под это подложить статья была бы сильно полезнее. Тут еще можно играться с точкой пересечения. Как пример сдвинем ее правее и востребованность доработок\продукта может быть равна 0. Можно наложить рассуждения на две модели - для примера рассмотрел два варианта запуск стартапа и разработку коробочного решения с понятным функционалом и планом на 3-5 лет
На самом деле ты просто быстрее выложил задачу на прод, но не быстрее сделал задачу.
Нет, выложил на прод (для группы, работающей над программой в целом) или влил написанный кусок сделанного кода в общую программу (для конкретного разработчика) — это и означает сделал: эта конкретная задача уже решена
При этом у программиста есть масса способов сократить усилия (а, следовательно — и время) разработки за счет потери того, что обычно относят к «качеству». И отсутствие обработки достаточно редких ошибок — это только один из них. Есть и другие.
Например, можно оставить в программе «магиеское число» вместо того, чтобы заменить его именованной константой, назначение которой понятно из ее имени: экономится время на придумывание имени, на запись определения константы в нужное место программы (обычно это нужно делать где-то в другом месте). Можно скопипастить в несколько мест почти повторяющиеся куски программы и немного подправить их по месту, вместо того, чтобы оформить их в виде подпрограммы, годящейся для всех мест использования этого похожего кода. Можно даже написать спагетти-код, в котором управление передается туда-сюда вне всякой последовательности (промисы в JS или продолжения задач в C#, вкупе с вызовами подпрограмм/методов, определенных «где-то ещё», и передаваемых туда ссылок на методы, дают массу возможностей сделать это даже без использования банального goto). И так далее.
В отличие от отсутствия обработки редких ошибок программа при этом хуже работать не будет — но изменять ее будет труднее. То есть, прямо требуемый с работника-программиста результат будет достигнут — но за счет побочных эффектов.
И, кстати, такая экономия — она, вообще-то, как раз соответствует материальным интересам наемного работника-программиста: он сделал требуемое с него, пусть за те же деньги, но затратив меньше своих собственных усилий. Потому объективно контроль за надлежащим уровнем качества — это, если подходить объективно и материалистически есть исключительно проблема менеджера.
А побуждать наемного работника брать на себя решение этой проблемы — что по факту делается в этой статье — это попытка навязать работнику ложную потребность действовать вопреки своим материальным интересам.
Ты можешь делать либо быстро и качественно, либо медленно и плохо
Предлагаю автору сделать качественный аналог яндекса за месяц. Нет, за неделю - чтобы еще качественней... нет, за день, чтобы прям ух как качественно все было!
Если заказчик не знает, что он хочет (или у него хотелки меняются по пять раз на неделе), то это проблемы заказчика, а не программиста, вы не находите?
требовать при существенных изменениях требований использовать старый код (на который потрачены уже деньги), залепляя его синей изолентой и костылями
Я например, на уровне собеседования говорю, что без написания авто-тестов не работаю. А если на меня начнут морально давить на работе всякими неадекватными задачами - просто уволюсь.
Другое дело, что для многих россиян терпеть - это в крови.
Я сейчас открою один секрет, только ты не обижайся.
Качество и скорость никак не связаны. Это раз.
А во вторых если у вас отсутвует техническая документация на то что вы наваяли или она есть, но просто "для галочки", для неё нет процесса QA, или она его не проходит - качестао вашего "изделия" равно нулю.
Третье, если вы используете любую вариацию аджайла (еще лучше скрама) в его СНГ-ешной интерпретации, т.е. над ним не построено нормального полноценного водопада - качество вашего кода равно нулю. А еще скорее отрицательно.
Я старый разработчик и все эти рассуждения для меня настолько банальны, что задаюсь вопросом: неужели всё так деградировало, что эти банальности обсуждаются в статьях, блогах и т.д. Я бы постеснялся выкладывать на свет божий свою некомпетентность.
Ребята, а не пробовали уяснить такие понятия, как "проект", "управление проектом"? Не пробовали писать техническую документацию? Или вера не позволяет? Я имею в виду эджайл.
Отрезок качества