Программировать быстро или качественно?

В своей работе заметил, что временами впадаю в ступор, когда не могу решить, как лучше поступить при реализации какого-то функционала: то ли написать код быстро, лишь бы работало, или пытаться сразу делать все качественно (потратить время на продумывание архитектуры, реализовать сразу дизайн согласно спецификации, не дублировать код, создавать ясные названия методов, выносить строки в константы, использовать паттерны и т.д).

С одной стороны, если программировать быстро, тогда возникает диссонанс, что пишу говнокод и боязнь критики со стороны коллег, а с другой стороны есть риск, что не успею со сроками. Потом этот паралич решения приводит к тому, что начинается прокрастинация, а следом за ней подкрадывается неудовлетворенность работой и выгорание.

Есть идея попробовать принцип, который используется в рисовании: от общего к частному. Наверняка, у каждого был в детстве
такой опыт, когда увлекшись прорисовкой головы человека, потом оказывалось, что не оставалось места для рисования ног.

Интересно узнать, какие у кого подходы в своей работе, удается ли вам гармонично сочетать скорость разработки и качество кода.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

c2.com/...WorkMakeItRightMakeItFast
1. Make it working
2. Make it right
3. Make it fast

Лучше получить работающий вариант, а потом доводить его до ума. Пока получаешь работающий вариант можешь много нового узнать про задачу, и понимание того как оно должно быть сделано по-уму может измениться. Если сразу начнешь пытаться делать архитектурный долгострой, то рискуешь и задачу толком не сделать, да еще и понять что не так нужно было к ней подходить.

Это невозможно «сочетать». Здесь нужно чётко выбрать свой путь — либо ты по жизни работаешь качественно, либо huyak-huyak-и-впродакшен. Почему так: Выбрав любую из этих крайностей, ты растёшь и со временем всё больше получаешь.

Любое место посредине — выматывает тебя в тряпочку, и ты получаешь демотивацию по обеим пунктам. К тому же существенно больше работаешь (среднее качество требует 95-97% времени от высокого), но оплачивается только на 30-50% выше от говноделов, и то тебе приходится постоянно эту разницу доказывать. Со временем ты перестаёшь доказывать, просто приобретая постоянных клиентов (которые обожглись об реальных говноделов), но чувствуешь над собой потолок. С качеством же тоже перестаёшь сильно стараться, знаешь что не оценят. Вернее начинать-то ты начинаешь, но когда видишь в какое время это выливается — бросаешь.

Ещё момент: для качества как правило требуется узкая специализация. Так ты сможешь экономить — делая продукт среднего качества, но в требуемой области — высокого. Например, твои программы могут быть в 5 раз медленнее высококачественных, но пока у них не хотя бы десятка тысяч пользователей — это не так уж и критично. Если бы ты старался вылизывать каждую ямочку, у тебя бы и десятка пользователей не было. Если же проект реально «выстреливает», то тебе вообще кроме твоей узкой области и работы доставаться перестанет, на остальное наймут людей подешевле.

Ну и как бонус — качественнику вполне светит место CTO. Просто в какой-то момент где-то появляется проект, которому ну вот нужна именно его узкая специализация. Одно собеседование — и прежнему работодателю уже нечем крыть, вынужден отпускать.

У говнокодеров другой бонус — возможность работать путешествуя. Работа будет всегда, и работы будет много. А ещё будут тысячи отзывов, и среди них немало отзывов хороших. То есть грубо говоря, без работы не останешься, а своим портфолио легко вытеснишь середнячков с рынка. Большинство клиентов и не догадывается, что количество — конкурент качества, и догадаются только когда сами обожгутся. И даже тогда будут продолжать платить, ЕСЛИ им не с чем сравнить. Всё ведь в сравнении познаётся.

PS. На говнокод спрос всегда выше. Успех одного качественника порождает рабочих мест на 2-4 сотни говнокодеров, для тех заказчиков которые хотят «чтоб как пейпэл, но заплачу всего 4000$». С другой стороны, работа этих говнокодеров неизменно порождает спрос на продукт качественника — ведь КЛИЕНТЫ уйдут уже от заказчика говнокода. К кому уйдут — догадайся. Говнокодеры же в накладе не останутся, они своё получат почасово. В крайнем случае выучат пару новых трюков — и в бой, благо заказчиков «которые платят дважды» неистребимое множество.

PPS. Но на говнокодеров и предложение выше. И оно растёт, быстрее чем спрос. Так что если хочешь преуспеть — нужно быть говнокодером даже среди говнокодеров, то есть с наименьшими издержками на «продукт» ;)

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Из книги Роберта Мартина, «Идеальный программист. Как стать профессионалом разработки ПО».

Чтобы понять, во что вы по-настоящему верите, понаблюдайте за собой в кризисной ситуации. Если во время кризиса вы не отклоняетесь от своих рабочих методов, значит вы действительно убеждены в их эффективности.
Если вы следуете методологии разработки через тестирование (TDD) в обычное время, но отказываетесь от нее во время кризиса, значит вы не верите в полезность TDD. Если ваш код остается чистым в обычное время, а в кризис вы разводите в нем грязь, значит вы не верите, что
грязь замедляет вашу работу. Если вы используете парное программирование во время кризиса, но не в обычной ситуации, значит вы полагаете, что парное программирование эффективнее индивидуального.
Выберите те методы, с которыми вы комфортно ощущаете себя в кризисной ситуации. А потом используйте их постоянно. Использование этих методов — лучший способ избежать кризиса.
Не изменяйте свое поведение в напряженной ситуации. Если ваши методы действительно оптимальны, то они должны соблюдаться даже в самые тяжелые времена.

Остается только наработать те самые методы, и со временем качество перерастет в эффективность, и не нужно будет х2 к времени что бы тесты писать и тд.

Спасибо, что указали эту книгу. «Чистый код» Мартина читал, но про «Идеального программиста» не знал.

Интересная статья от Рето Майера о том, почему разработка программы неправильным путем может быть на самом деле правильным путем — medium.com/...t-1ef38a2b7196#.jrxlobkey. Там он еще показывает скринкаст, как он создает прототип приложения неправильным путем, написав простыню кода в одной активити, но максимально быстро.

Это невозможно «сочетать». Здесь нужно чётко выбрать свой путь — либо ты по жизни работаешь качественно, либо huyak-huyak-и-впродакшен. Почему так: Выбрав любую из этих крайностей, ты растёшь и со временем всё больше получаешь.

Любое место посредине — выматывает тебя в тряпочку, и ты получаешь демотивацию по обеим пунктам. К тому же существенно больше работаешь (среднее качество требует 95-97% времени от высокого), но оплачивается только на 30-50% выше от говноделов, и то тебе приходится постоянно эту разницу доказывать. Со временем ты перестаёшь доказывать, просто приобретая постоянных клиентов (которые обожглись об реальных говноделов), но чувствуешь над собой потолок. С качеством же тоже перестаёшь сильно стараться, знаешь что не оценят. Вернее начинать-то ты начинаешь, но когда видишь в какое время это выливается — бросаешь.

Ещё момент: для качества как правило требуется узкая специализация. Так ты сможешь экономить — делая продукт среднего качества, но в требуемой области — высокого. Например, твои программы могут быть в 5 раз медленнее высококачественных, но пока у них не хотя бы десятка тысяч пользователей — это не так уж и критично. Если бы ты старался вылизывать каждую ямочку, у тебя бы и десятка пользователей не было. Если же проект реально «выстреливает», то тебе вообще кроме твоей узкой области и работы доставаться перестанет, на остальное наймут людей подешевле.

Ну и как бонус — качественнику вполне светит место CTO. Просто в какой-то момент где-то появляется проект, которому ну вот нужна именно его узкая специализация. Одно собеседование — и прежнему работодателю уже нечем крыть, вынужден отпускать.

У говнокодеров другой бонус — возможность работать путешествуя. Работа будет всегда, и работы будет много. А ещё будут тысячи отзывов, и среди них немало отзывов хороших. То есть грубо говоря, без работы не останешься, а своим портфолио легко вытеснишь середнячков с рынка. Большинство клиентов и не догадывается, что количество — конкурент качества, и догадаются только когда сами обожгутся. И даже тогда будут продолжать платить, ЕСЛИ им не с чем сравнить. Всё ведь в сравнении познаётся.

PS. На говнокод спрос всегда выше. Успех одного качественника порождает рабочих мест на 2-4 сотни говнокодеров, для тех заказчиков которые хотят «чтоб как пейпэл, но заплачу всего 4000$». С другой стороны, работа этих говнокодеров неизменно порождает спрос на продукт качественника — ведь КЛИЕНТЫ уйдут уже от заказчика говнокода. К кому уйдут — догадайся. Говнокодеры же в накладе не останутся, они своё получат почасово. В крайнем случае выучат пару новых трюков — и в бой, благо заказчиков «которые платят дважды» неистребимое множество.

PPS. Но на говнокодеров и предложение выше. И оно растёт, быстрее чем спрос. Так что если хочешь преуспеть — нужно быть говнокодером даже среди говнокодеров, то есть с наименьшими издержками на «продукт» ;)

А потом по быстрому костыляю и велосипедирую.

Ну вот не попадается таких задач где нужно некачественно, и хоть стреляйся. Нужно быстро — да. Но мля каждый раз как поспешишь — потом приходится разгребать. Когда не поспешишь тоже приходится, но куда реже.

И да, у меня постоянно есть пиво. Не потому что я пиво люблю. Пиво любит админ. А я люблю когда админ.задачи делаются быстро и качественно :))

Кстати, по той же причине мой оптимальный рабочий день — 16 часов для рутиных задач, 4 часа — для сложных, и 20 минут — для сложных переговоров и конфликтов. Иными словами, после этого срока я буду дрыхнуть, даже если пожар. Для задач организационного класса — около 80 часов непрерывно приходилось, но тогда я делаю только то что знаю и не заставляйте меня думать.

Сейчас к примеру у меня небольшой перерывчик в конце 16-часового, щас ещё думаю взять кофе и задачку на пару часиков. Вроде можно и не брать, но блин, я ж на продакшен выставил версию, надо понаблюдать.

UPD: Ну вот, наблюдение показывает что таки качества не хватило. Вероятнее всего не у меня, но апдейте вскрыл косяки чужого кода.

Вот простой пример, над которым прямо сейчас работаю. Нашёлся ЧУДАК до меня, который по-быстрому написал биллинг. Это по-быстрому разумеется слетело, и... 4 дня не списывались деньги со счетов клиентов за платную услугу. Это я так думаю, что 4, щас буду выяснять сколько на самом деле.

Так он ещё и зашифровал эти поля, засунув с кучей других данных в JSON. Защита конечно от дурака, но достаточно чтобы не построить контрольный SQL-запрос. Зачем это было надо — знает лишь мудрец лохматый.

Тот же чудак решил, что достаточно простым апдейтом над полем сумма провести операцию списания — и дело в шляпе. Без какого бы то ни было логирования. Совсем. Тоже видать по-быстрому надо было, пока это через год жизни проекта не всплыло мохнатым ёжиком.

А есть другой чудак — я. Который заметил, что важные данные лежат в одной таблице. И который любит качество, и потому прописал БЭКАПИТЬ эту табличку каждый час, от 100 килобайт архива ещё никто не умер. И вот сейчас по факту эти полтысячи бэкапов — это всё что у меня есть. А могло не быть вообще ничего.

И да, чудак который решил расшифровать к ибеням таблицу чтобы можно было анализировать тренд — тоже я. Иначе бы утечку актива нескоро заметили, поскольку он не деньги, а виртуальная валюта.

Есть только одна причина, почему я так делаю. Я не люблю работать. Я люблю чтобы компьютер работал. И так, чтобы даже ежу понятно было что он делает и когда. И если когда-нибудь ежи станут платежеспособным контингентом — я без вопросов зашарашу им стартапчик для знакомств :)

Кстати, по той же причине мой оптимальный рабочий день — 16 часов для рутиных задач, 4 часа — для сложных, и 20 минут — для сложных переговоров и конфликтов.
вы киборг что ли? я бы после 10 часов любых задач уже бы соображать перестал

Вероятно, должно было быть как-то так

6 часов для рутиных задач, 4 часа — для сложных, и 20 минут — для сложных переговоров

Но не всё вместе. Эти 20 минут выведут меня из строя на целый день. Но за эти 20 минут я никого не убью, даже тех кто заслуживает, а как раз наоборот — смогу понять все обстоятельства и достаточно вменяемо разрулить.
Но если так оказывается, что какая-то сторона тупо не заинтересована разруливать, а желает самого конфликта — ну что ж, значит придётся расчленять труп, мыть стены от крови. Я привык. 16 часов рутиной работы.

У меня есть кросовки. Я их выгуливаю.

Ещё момент: для качества как правило требуется узкая специализация.

Спасибо, классно подметил. Чтобы качественно работать, нужно знать нюансы в своем направлении, а учитывая, что в программировании нужно постоянно изучать что-то новое и времени на все не хватит, то помимо специализации на каком-то стеке технологий, по-хорошему желательно еще более сузить специализацию, чтобы быть профессионалом, так как невозможно знать тонкости во всех технологиях.

Вот я, например, занимаюсь разработкой под андроид почти 5 лет, то есть опыт уже довольно неплохой, но все еще не удовлетворен знанием нюансов в этом направлении или даже каких-то простых вещей. Многое забывается из-за того, что не используется в проектах либо знания просто устаревают. И такое положение дел не может не расстраивать. Возможно, даже в рамках андроида стоит мне сконцентрироваться на более узкой области.

Часто приходится снова и снова возвращаться к тому, что и так хорошо знаю или очевидно на первый взгляд, чтобы найти какие-то новые детали, которые улучшат мое понимание. Как вот в случае с вопросом к названию темы.

Ставьте вопрос — к чему это приведёт? Гармония — это когда потом не жалеешь.
Знай цену каждого решения. Знать, например, что на собсно на нажимание кнопок идёт не так много времени. Больше сидишь и тупишь, думая, как сделать. И именно это и надо оптимизировать. Ещё раз: жать на кнопки — быстро, думать — долго. Потому где кнопкодавство помогает думать — кнопкодавить)
Всё перечисленное помогает и даже создано для того, чтоб ускорить разработку. Если не ускоряет, то вы делаете или не это или неправильно или не занимаетесь разработкой) А вот отход от этих метод как раз к ступору приводит.
Но прокрастинация обычно наступает, когда ОБА пути и «правильный» и «быстрый» кажутся плохими. И таки это обычно значит, что таки «правильный» путь — не такой уж и правильный) Вплоть до того, что реально правилен — быстрый. Взвешивайте достоиства и недостатки и на основании этого решайте. Да, вы можете ошибаться. Но взвешенное ошибочное решение помогает улучшить следующие оценки. В отличии от не взвешенных, у которых с опытом ещё и шанс оказаться неудачными много больше.
Из неочевидных недостатков, которые новички чуют, но списывают на лень — все эти методы также могут раздуть код. Размер кода не важен, но важна понятность (потому что думать — долго), которая тоже может от них пострадать, даже если размер стал меньше. Потому если понятность в минусе, а плюсов не видать — смело делайте «быстро».

Да проще все. «сделать быстро» = как уже знаешь. «сделать качественно» = как где-то слышал что другие пацаны делают. Если слышал, но не изучил как сделать качественно — будет вопрос и метания. Ответ простой: делать как знаешь, потом допиливать подчитывая всякое. Ибо больше времени уйдет на терзания, чем на делание.

1) Найдите среднюю скорость с которой вы выдаете приемлемое качество и опирайтесь на нее. Среднюю — потому что сделать идеально может и 10 лет не хватить. Выберите среднюю скорость. Качество — это соответствие продукта требованиям и ожиданиям, а не идеал (за идеалами — к перфекционистам)

2) Если вы по каким-то причинам делаете некачественно заказчик об этом должен знать (например это прототип и он сам попросил не заморачиваться)

3) Не думайте что написав быстро вы сэкономили время. Потом вы или другие потратите кучу времени на чтение этого кода, отладку, фиксы багов, поддержку, внесение изменений. Качественный код придумали не потому что так красивее, а потому что так меньше багов, быстрее потом его понимать, отлаживать, и изменять.

4) Вы хотите чтобы с вами еще сотрудничали или это ваш последний проект?

5) Если на вас давят по срокам, то так и говорите: могу быстро за неделю и качественно за две, вам как сделать? Но по умолчанию от вас ожидают «качественно» (без перфекционизма)

6) Те кто давно пишет качественно — уже привыкли и по-другому не умеют. Ну и есть же code style и code reviews на проектах.

В комментарии ниже (dou.ua/...orums/topic/17269/#915477) я немного дополнил, что я имею ввиду под скоростью разработки и качеством кода (внимание к деталям изначально). Повторю тот комментарий более кратко: если абстрагироваться от заказчиков, менеджеров и сроков, и предположить, что в целом вы знаете, как сделать свою работу качественно, то какой подход все же лучше выбрать: от частного к общему или от общего к частному?

Из того, что тут уже высказали, я склоняюсь ко второму варианту: писать код быстро — лишь бы работал, а потом по возможности находить время и переписывать некоторые участки.

Вы упомянули перфекционизм — в этом то как раз и состоит моя проблема. Это качество характера мешает мне часто в работе. Мне изначально хочется попытаться сделать все правильно.

Поняла. То есть вы сами себе и заказчик и команда и код ревьювер. Тогда отталкивайтесь от того, вы хотите выпустить продукт или хотите просто покодить «в стол». Если просто покодить хочется и не принципиально публиковать продукт, можно долго заниматься перфекционизмом.
Если хотите выпустить, делайте minimum viable product — минимально жизнеспособный продукт, выпускайте а потом улучшайте (итеративный подход).

Это принцип Microsoft )). Именно они внесли в массы важность патчей ))).

Если возникает такой вопрос, значит ваша квалификация низкая(надо «тратить время на продумывание» и тд). У меня все.

О, вы по одному вопросу можете определить квалификацию?! Это очень ценный навык для проведения собеседований.

Да. Если чувак задает вопрос «сделать быстро или качественно» значит о качестве у него понятие отсутствует (это запрос о доп расходе времени на почитать с неизвестным исходом на самом деле). Брать максимум на мидла таких неопределившихся. Нормальный чувак все сразу делает чотко.

ага, нормальный чувак все сделает «чотко» и без багов — одним словом хх-и-в-продакшн, как говорится. Наверно, такие чуваки, как единороги — мне лично не удавалось встретить.

Если вы далеки от программирования, то воздержитесь вообще от оценки хороший был вопрос или плохой.

С багами конечно сделает. Но не будет заливать фуфло что «быстро» делал вместо «качественно».

Я короче попроще выражусь для понятности — или говори что ошибся как мужик или ной как баба что «быстро делал». Выбор за тобой.

Ты это к своему начальному посту прилепи, будет сильно правильнее

Если уж так рассуждать, то нужно все проекты переводить на ватерфол. Чтоб долго и качественно, и без изъянов. Только когда проект уйдёт в производство — он уже никому не будет нужен

А как вы например предполагаете учитывать будущее проекта? Что б в итоге в следующих итерациях было удобно, выдерживало нагрузку, маштабируемо было, вообщем хорошо и какой вы предполагаете горизонт планирования?

Оно как то так бывает : накидуешь черти шо лижбы работало и исполняло свои задачи. Думаешь «фух накидал за день херни, на неделе все норм перепешу». А хер там — нужно то вчера. И твое фиг знает что идет в прод. А потом коллеги смотрят как на сумасшедшего бо говнокод лютейший с переменными типа «gavno1», «gavno2».... и функциями типа «PrivetMamke», «SeichasZakoldyjy», «ZakoldyiPerekoldyi», не, ну я утрирую конечно, называть можно со старту нормально, но кучу других нюансов, типа нима коментов, не оптимизирован и т.д. Впринципе тот код вообще видеть никто не должен, а вот ниполучается. Так шо «фух ! Работает !» лучше не говорить, а быстренько переписывать Если со старту писать нормально, то по времени выходит дольше + если незнакомая задача переписывать прийдеться полюбе..

С точки зрения компании — лучше писать быстро.

1. Заказчик доволен.
2. За переписывание этого говнокода быстро написанного кода, компания получит дополнительную прибыль.
3. Когда вы посмотрите на код, который написали год назад (быстро) и увидите, как Вы его переписали (сделали нормально), то Вы ощутите собственное развитие, как специалиста :)

А если серьёзно, то писать нужно быстро и качественно (чтобы функционал исправно работал и не возникало критичных проблем).

А женщине нужно быть умной и красивой, у неё никогда не болит голова, знает совершенно несколько иностранных языков, работает на 5к$ в лидере рынка под кондиционером, после работы варит борщи , держит дом в идеальной чистоте и никогда не пилит мужчину.

«А борщ готовить быстро или качественно?»

(подсказка автору, что все зависит от того, насколько вы уважаете себя и тех кому ваш «кодо-борщ» достанется)

«А борщ готовить быстро или качественно?»
В Пузатой Хате готовят быстро.
И, крнечно же, коренастая девочка на раздаче с волосатыми руками ляпнет в тарелку сметану — она так привыкла.

Здесь нельзя не согласиться :)
Хотя, как показывает код, который достаётся от предыдущих коллег, многие компании рады такому подходу :)

Тут главное знать когда стать предыдущим.

2. За переписывание этого говнокода быстро написанного кода, компания получит дополнительную прибыль.
это актуально только для аутсорса, в других случаях существует шанс огрести люлей

Если проанализировать происходящее в мире, то подход «сделать быстро» однозначно побеждает в количественном измерении. В конце концов в подавляющем большинстве случаев заказчик не сильно понимает что он хочет. Потому чем быстрее он увидит результат — тем более всем сторонам выгодно. Собственно говоря на этом и построен весь Agile.
Однако хорошему инженеру такой подход претит конечно же.

Если проанализировать происходящее в мире
В третьем мире. Не забывай где ты, и подумай о тех местах, где не разделяет подобного подхода.

Колись була стаття про класичну суперечку, як правильно писати — знизу вгору чи згори вниз. Висновок був — з країв досередини.

Коли зрозуміло, що робити — тоді найкраще закрити критичний шлях, якщо готові всі компоненти. А деколи варто зняти критичні техні ризики.

Я для себя поставил когда-то ровно такой же вопрос. Решил его благополучно так — сначала быстро, а потом качественно.
Быстро нужно потому, что требования могут измениться по ходу написания, по ходу вникания в задачу. «Быстрый код» (какая хорошая альтернатива «говнокоду» :) ) не жалко выкинуть.
Качественный код для вещей, для которых хорошо понятны и стабилизированы требования, набран некий критический объём юс-кейсов. Иногда он пишется и с первого раза... если уже не впервой.

такой себе agile-как-подход-к-разработке-конкретной-задачи

Не вижу каким образом бессмысленные названия переменных или магические числа или дубликация кода ускоряют работу.

Я не говорил, что нужно давать бессмысленные названия переменным. Тем не менее, переменные назвать проще, чем дать короткое и понятное название методу, чтобы и без комментариев к коду было понятно, что там происходит.

Конечно, чем яснее код пишешь, тем лучше понимаешь, что делаешь.

Продублировать код зачастую быстрее, чем вынести его в отдельный метод или вообще в отдельный класс, хотя с помощью современных сред разработки можно быстро рефакторить.

Это все мелочи, но они влияют на скорость.

Ты очень серьёзно относишься к этому всему дерьму.


С одной стороны, если программировать быстро, тогда возникает диссонанс, что пишу говнокод и боязнь критики со стороны коллег,
Значит , ты тут сжатый временными рамками и стараешься найти баланс, а у твоих коллег есть время не только на просмотр чужого кода , но и на критику?

Как-то нечестно получается. Не смущает?

Обсуди этот вопрос с коллегами.
Если они нормальные и понимающие (есть время на чтение твоего кода и критику) — то разберётесь там сами без ДОУ.
Если ненормальные, заносчивые, любят ржач на привселюдном код-ревью — тебе с ними не по пути, ищи другую работу и другой коллектив, бывает так, что даже в соседнем кабинете люди иначе себя ведут.
Если стерпишь — то выгоришь, будешь потом отдыхать полгода и рассказывать недалёким хрюшам, почему пробел в полгода в резюме, хрюшам, которые много болтают вместо того, чтобы отправить на техническое собеседование.

Ещё раз: поговори с коллегами. Посмотришь на результат.

Да, некоторые начнут думать , что настоящие профессионалы не задают вопросов или ещё какое-то дерьмо с определением внутреннего конфликта начнётся, но я тут не знаю , что делать, в айти на самом деле много MYДАKОВ.

А вообще вопрос серьёзный ты затронул.

c2.com/...WorkMakeItRightMakeItFast
1. Make it working
2. Make it right
3. Make it fast

Лучше получить работающий вариант, а потом доводить его до ума. Пока получаешь работающий вариант можешь много нового узнать про задачу, и понимание того как оно должно быть сделано по-уму может измениться. Если сразу начнешь пытаться делать архитектурный долгострой, то рискуешь и задачу толком не сделать, да еще и понять что не так нужно было к ней подходить.

Это называется сначала сделать макет, опытно-конструкторский образец.
А потом уже сделать проект, основываясь на предудущей работе.
нет, это не совсем то, даже скорее совсем не то. Этот принцип работает на более маленьком масштабе — фичи (в идеале — сашими). И результат шага 1 не выбрасывается, а рефакторится к шагу 3, чем достигается постоянная преемственность улучшений, и если почему-то нужно будет остановить работу, то будет уже не голый прототип.
менеджмент выкидывает на рынок
менеджмент имеет полное право принимать решение о выкидывании на рынок, на то он и менеджмент.
в результате продукт представляет собой набор костылей и подпорок, связанных скотчем и шнурками.
 в этом либо обоюдная вина в недостаточной коммуникации и доверии, или исключительно техническая вина в увлечении слишком большими переписываниями / gold plating. Иногда просто требования ситуации на рынке.

Да, это всегда проблема, и вряд ли есть универсальные критерии выбора. Поэтому поделюсь своими.

Надо четко различить интерфейс от реализации.
Интерфейсы стараться делать качественно. Реализацию — если есть время.
Например банальная процедура сортировки — должна получать массив, коллекцию, И правило сравнения, даже в том случае когда это правило очевидно. А реализована может пузырьком без флага.
Другими словами — заметать под ковер можно, но сам ковер должен быть качественный и чистый.
В помощь — метод прогрессивного джипега.

Нужно помнить, понимать где написан гыкод. И иметь рациональное объяснение себе почему он такой. Возможно написать это и в комментарии к нему.

Гыкод допустим в случае если точно уверены что его потом не нужно будет развивать, или что потом он будет весь заменен.

Помнить что качественное проектирование нередко превращается в творение архитектурных астронавтов. А потому избегать недодуманного использования паттернов. Качества они не добавят, и уж если нет времени подумать, то лучше писать простой гыкод, чем его же усложнять изысками.

Даже в гыкоде нельзя нарушать аксиомы. Типа процедура, метод на сотни строк, в которых и обработка входных данных, и работа с БД, и формирование ответа. Пусть это делает богокласс, но метода уже минимум будет три.

Названия переменных типа ttt допустимы, но только в случаях если эта переменная используется тут же, в пределах 5-7 строк. В остальных случаях надо и в гыкоде давать что-то более осмысленное. Хоть даже тип дублировать.

Всем коллегам не угодить, поэтому нужно реагировать только на мнение близких. Т.е. как и в жизни — замечание случайного прохожего можно игнорировать, а близкого человека — не стоит

поддерживаю.
лучше концентрироваться на «быстро», костыли и велосипеды — допустимо.
важно — чтоб отдельные фрагменты были как можно сильнее изолированы друг от друга.
и тогда можно будет итеративно по частям рефакторить.

Часто бывает overengineered решения, на много хуже чем костыли на коленке

Это скорее правило. Костыли достаточно легко поправить или загнать в канву, особенно если они ДОКУМЕНТИРОВАНЫ. А вот «overengineered» — это когда баги становятся фичами, потому что поправить их уже некак — на них код в продакшене завязан.

Советую почитать Clean Code: A Handbook of Agile Software Craftsmanship анкл Боба

Предлагаю абстрагироваться от заказчиков и менеджеров, и допустим, что я пишу свой простой пет-проект для андроида. Есть дизайн и сроками я не ограничен. К примеру, хочу сделать экран авторизации, после чего переход на экран со списком элементов.

Я знаю, как правильно все реализовать, но подходы к кодингу и в этом случае все равно могут быть разными. Один из подходов в том, чтобы концентрироваться на деталях, то есть, по принципу «от частного к общему». Согласно этому принципу я могу заняться версткой дизайна от начала и до конца, и пытаться делать все по уму (ясное наименование айдишников, все оформление вынести в стили, не хардкодить строки, а выносить их сразу в отдельный файл).
Потом также с головой погрузиться на реализацию функционала по кнопке «Log in with Facebook». Задействовать RxJava+MVP+Retrofit+Dagger2, и так далее по пунктам.

Второй подход, на котором я хотел бы акцентировать внимание — это от общего к частному. В этом варианте можно набросать по-быстрому рабочий черновой вариант всего проекта. Вместо того, чтобы весь дизайн сразу начать прорабатывать, можно просто показать два дефолтных текстовых поля и кнопки авторизации, строки прописать хардкодом. И вместо настоящей реализации авторизации через фейсбук, сделать заглушку для метода loginWithFacebook(), и при нажатии на кнопку логина открыть новый экран, где показать тестовый список строк.

Второй подход предполагает быстрое написание прототипа, как предложил Alexandr Gavriluk. А дальше уже повторять итерации с улучшением и большей детализацией всех частей проекта.

Выше еще написали про метод прогрессивного джипега. На мой взгляд, он полностью соответствует принципу «от общего к частному». Фактически такой подход можно назвать, как разработка через прототипирование.

Каждый из этих подходов имеет право на жизнь, но хотелось бы разобраться, какой лучше.

По своему опыту — лучше делать чуть медленнее, но качественнее. Иначе потом фиг разберешься, что это было и зачем, и потратишь кучу времени вспоминая/разбираясь. Если совсем запара по времени — хотя бы добавить комментов, а на досуге причесать.

Мой совет — добавляй не пару, а ПОБОЛЬШЕ комментов. Тогда и разберёшься легко (поиск по ключевым словам никто не отменял), и твои «причесать на досуге» окажутся в этих самых комментах со словом TODO.

Тогда можно делать и делать по-быстрому. Даже если и не запара, но хочется увидеть хоть что-то стабильно работающее, и работающее через свои родные интерфейсы, а не через тесты. Даже если и нет их там, этих тестов, в 80% твоего кода, работы через родные интерфейсы как правило достаточно, чтобы все баги увидеть через них.

У быстрого кода есть ещё одно преимущество — бета-тестеры. Чем скорее к ним попадает код, тем короче его цикл до выхода на стабильную версию. Иначе же со всеми тестами да ревью ты уже забыть успеваешь что там, когда его только-только пользователи видят. И как назло, видят все сразу скопом, и это утро понедельника первого числа — потому что сдавался проект в последний срок последнего дедлайна.

Быстро писать прототип, при этом итеративно тратить 25% на рефакторинг текущего кода, когда он тебе перестаёт совсем нравится.

Вот интересно, а как потом объяснить заказчику, что «это прототип» и сделать из него продукт это затратить сопостовимое время. Ведь для заказчика «оно почти работает, вот только тут чуть-чуть добавить и сделать быстрее». Так и получается lava flow

Объяснить про разницу стоимости поддержки текущего кода и её стоимость после рефакторинга. Если заказчик согласен со стоимостью поддержки прототипа, то его деньги.

А как померять? Заказчику ведь зачастую сегодня и не нужно поддерживать, это он завтра придумает новую фичу, завязанную на эту.

Ну можно в условном отношении, что стоимость поддержки текущего кода в 3.5 раза выше чем отрефактореного. Согласившись с внедрением прототипа заказчик не удивится если стоимость и срок разработки фичи будет отличатся в 3.5 от стандартной.

Кроме того поддержка говнокода сторонним программистом становится практически невозможной. Поэтому получаем добровольный lock in заказчика на разработчика. Причем разработчика в индусчине обвинить будет сложно, так как решение принимал заказчик.

PS
Лично я отказ в рефакторинге выдел только в НИИ, где я работал сразу после института. Во всех остальных случаях, как ни странно, заказчик умеет считать деньги.

Закладывать стоимость рефакторинга в фичи. Тогда и объяснять ничего не надо будет, и код будет улучшаться.

Просто спроси его — это как подержаная машина, да? В смысле, должен доработать до выезда от продавца?

На рефакторинг тратится 300%. Иначе это либо не рефакторинг, либо не первый.

Здравствуйте!

Самый лучший вариант — программировать быстро И качественно. Когда качественное выполнение работы войдет в привычку, работа будет выполняться быстро и на автомате. Конечно, во время вырабатывания такой привычки скорость будет страдать...

Также, нужно быть здоровым, умным и богатым, потому что быть больным, глупым и бедным неправильно.

Мужик в троллейбусе едет и думает: «Жена-дура, друзья-подонки, жизнь-дерьмо». За спиной стоит Ангел, записывает в блокнот и думает: «Какие странные желания, а главное одни и те же каждый день! Но ничего не поделаешь, надо исполнять!»

«Мы влюбляемся сотни раз, когда готовы умереть, и любим лишь один, когда готовы жить, терпеть и бороться.»

Точно, это они все отлынивают. А постарались бы — программировали бы быстро и качественно. И задешево, задешево!

Ну я когда начинаю минут за 5 максимум представляю архитектуру/флоу на высоком уровне и начинаю быстро педалить, в процессе педалиния формирую сразу ту часть архитектуры которую еще не успел/поленился сразу представить.

Напиши это в резюме. Наверняка найдутся те, кто поверит!

// это ж мы как идиоты тратим недели на архитектуру, из них львиную долю времени на обдумывание.

Я даже перевёл текст для резюме, вот он:

Well, I’d start in 5 minutes max represent the architecture / flow at a high level and begin to pedal quickly, in the course of Pedalino I form just a part of the architecture that has not had time / too lazy to immediately present.

Никто не верит, пока не увидит как я работаю.

Я верю. Сам таким был. А потом пришла мама и отобрала фломастеры чтоб на обоях не рисовал.

не надо было фломастеры отдавать, сейчас бы тоже так смогли работать.
но если бы юность знала, и если бы старость могла

Ну это до поры пока вы работаете с известными вам инструментами и в известной вам сфере. Как насчет взять десяток новых инструментов и запустить ракету в космос? На высоком уровне то все просто: взять ракету, взять топливо, посадить обезьянку, отсчитать от 10 до 0 и нажать кнопку.

в неизвестной доменной области я полагаюсь на БА, более того, даже в известной мне области я полагаюсь на БА.

так что проблем нет.

Підписатись на коментарі