Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 101
Видел уже такое…
По-поводу прототипа. Почти всегда прототип после того как он себя оправдал тут же превращается в продукт. И когда разработчика пытаются убедить что нужно писать быстро и абы как, а потом напишем нормально. Это наглая ложь!
Как вариант: писать прототип на языке/платформе, которые в продакшен не пойдут с очень большой вероятностью.
т.е. например наняли несколько java/ruby/.net программистов, а прототип им писать на php?
Написали прототип на Ruby, утвердили и сделали на PHP.
Смешно.
Реальное использование. RoR удобен для прототипирования, проработки концепций и т. п., но для продакшена у него есть недостатки (прежде всего экономического плана).
Просто надо знать область применения. Для клепания сайтов в конвейерном режиме не подходит, для средних приложений — идеально. Не знаю о чем вы, про «экономический план».
Посмотрите любой холивар PHP vs Ruby.
Ну про какие-то недостатки RoR не я сказал, но если простое уточнение рискует перерасти в холивар — я пас.
В общем у PHP есть преимущества для бизнеса. Проще говоря, поддержка будет дешевле.
На разницу зарплат? Так нормальные специалисты стоят одинаково плюс-минус, а если «х*як-х*як и в продакшн» тогда конечно, тут такого нет.
Специалистов среднего уровня заметно больше.
Ребята пхп-шники, спасибо за минусы и слитую карму :) Но лучше вы бы высказали аргументы.
Это в рельсах-то нет «х*як-х*як и в продакшн»?!
А производительность?
А Пи Джи Хайетт-то и не в курсе. Или github еще не вышел в продакшн?
Писать прото на JS :)
ну это возможно, если цель прототипа — показать заказчику, как это будет выглядеть на экране. кнопочки, окошечки.
а в наше неспокойное время частенько компании хватаются за проекты, в которых требуется использовать неизвестные им технологии (но кто ж в этом признается, когда вот они, деньги!) и тут уже прототип больше нужен самим программистам, чтоб опробовать новый стек, слепить из 10 туториалов и заметок на стековерфлоу нечто, напоминающее систему.
а в наше неспокойное время частенько компании хватаются за проекты, в которых требуется использовать неизвестные им технологии (но кто ж в этом признается, когда вот они, деньги!) и тут уже прототип больше нужен самим программистам, чтоб опробовать новый стек, слепить из 10 туториалов и заметок на стековерфлоу нечто, напоминающее систему.
Не столько показать, сколько получить фидбэк, проверить юзабилити и т. п.
это тоже, но всё равно — упор на интерфейс, а не на начинку.
А у меня другая проблема:
я им говорю: я не понимаю, что вы хотите получить. пожалуйста, накидайте хоть на бумажке схему того, как все должно работать, я сделаю рабочий вариант.
Но мне говорят: мы сами не знаем, сделайте как-нибудь, а потом переделаем!
В результате:
они говорят — ты сделал плохо, мы вообще просили не так.
я говорю — (написал говно), все переделывать заново.
В результате, не вижу средств, как с этим бороться, кроме смены места работы.
В итоге такой код я называю «энтерпрайз», с пометкой «нет ничего более постоянного, чем временное».
я им говорю: я не понимаю, что вы хотите получить. пожалуйста, накидайте хоть на бумажке схему того, как все должно работать, я сделаю рабочий вариант.
Но мне говорят: мы сами не знаем, сделайте как-нибудь, а потом переделаем!
В результате:
они говорят — ты сделал плохо, мы вообще просили не так.
я говорю — (написал говно), все переделывать заново.
В результате, не вижу средств, как с этим бороться, кроме смены места работы.
В итоге такой код я называю «энтерпрайз», с пометкой «нет ничего более постоянного, чем временное».
Знакомо. Выход — каждую идею о том, как должно быть реализовано та или иная часть, быстренько прототипировать, показывать, переделывать если «мы просили не так», а когда всё «так», то писать уже нормально. Но при этом, пока заказчик не скажет «всё так», он должен понимать, что это прототип, который будет выкинут. Как вариант — серьезно доработан, и необходимость доработки должна быть очевидна даже (вернее особенно) для не разбирающегося в разработке человека. Хорошо работают, скажем, использование in-memory хранилищ, а не нормальных БД на стадии прототипирования или вывод всякой отладочной информации, игнорирование возможности кэширования, использование заведомо неэффективных алгоритмов или запросов к БД. В общем под шумок «полировки» переделать чуть более чем полностью.
О! В свете давно читаемых мной на Хабре споров на тему, стоит выбрасывать или развивать прототип, интересный приём…
Задача грамотного лидера разработки убедить подопечных, что быстро писать можно будет только если код будет чистым. Тогда и не будет идеологического противостояния с бизнессом.
А вот избыточную архитектуру в прототипах — часто действительно не нужно городить. был сведетелем, когда приходилось переписывать прототипы, после того, как они стали продуктом. Но главное было то, что прототип успешно приносил деньги. А значит — свою задачу выполнил.
А вот избыточную архитектуру в прототипах — часто действительно не нужно городить. был сведетелем, когда приходилось переписывать прототипы, после того, как они стали продуктом. Но главное было то, что прототип успешно приносил деньги. А значит — свою задачу выполнил.
Не только прототип, есть множество всяких «временных» заглушек. Но нет ничего более постоянного чем временное…
Ребят, есть идеальный код, а есть просто хорошо структурированный.
Так вот, идеальный код — практически не возможно писать (но можно стремиться). При пересмотре через месяц — всегда придумаешь как его можно было бы улучшить, или решить проблему более гибко/элегантно.
Структурированный, чистый, читаемый код — это код, который может быть «тупым», но легко понимаемым и читаемым. Возможно он не даст гибкости, но он позволит быстро найти ошибку в логике программы. И исходя из этого посыла НЕ СУЩЕСТВУЕТ причин, не писать хорошо структурированный код.
Так вот, идеальный код — практически не возможно писать (но можно стремиться). При пересмотре через месяц — всегда придумаешь как его можно было бы улучшить, или решить проблему более гибко/элегантно.
Структурированный, чистый, читаемый код — это код, который может быть «тупым», но легко понимаемым и читаемым. Возможно он не даст гибкости, но он позволит быстро найти ошибку в логике программы. И исходя из этого посыла НЕ СУЩЕСТВУЕТ причин, не писать хорошо структурированный код.
«Заставьте себя написать хотя бы один проект «правильно», и потом вы просто не сможете это делать по другому ;-)»
Голая правда!
Голая правда!
Это же дарк сайд софтваре девелопмента!
хорошие программисты оптимизируют код, а плохие — покупают новые сервера
Вот с этим бы не согласился, такое верно далеко не всегда. Оптимизированный код как правило стоит дороже неоптимизированного, и его сложнее читать и модифицировать. Поэтому я считаю допустимым лечить проблемы с вырастающей нагрузкой подконтрольным улучшением железа для многих ситуаций. А уж если неоптимизированный код и так потребляет три процента ресурсов, так тем более незачем его менять.
Абсолютно верно. Если код масштабиуется и проблемы производительности решаются докупкой серверов — это просто прекрасно. Железо стоит намного дешевле, чем труд квалифицированных специалистов.
Не так дорого железо, как его содержание, по этому горизонтальная масштабируемость — это прекрасно, но и о приложении тоже нужно думать.
Я не говорю о микрооптимизациях, за исключением разве что векторизации кода для современных CPU в некотором классе задач, а о алгоритмических оптимизациях, которые, если хорошо подумать над алгоритмами, могут существенно отсрочить необходимость закупки и содержания дополнительного оборудования.
Я не говорю о микрооптимизациях, за исключением разве что векторизации кода для современных CPU в некотором классе задач, а о алгоритмических оптимизациях, которые, если хорошо подумать над алгоритмами, могут существенно отсрочить необходимость закупки и содержания дополнительного оборудования.
А уж если неоптимизированный код и так потребляет три процента ресурсов, так тем более незачем его менять.
Раз стоит проблема покупать новые сервера или оптимизировать то явно потребляет больше 3-х процентов ресурсов.
Кроме того есть разные уровни оптимизации:
Можно оптимизировать путем внедрения низкоуровневых оптимизаций и т.д. — такой подход действительно может ухудшить читаемость.
Но на самом деле самые важные оптимизации это как правило структурные (закешировать результат тяжелых вычислений, минимизировать обращения к БД, удаленным обьектам, убрать дублирование логики) и на мой взгляд такие оптимизации только улучшат читаемость.
Если код на 1 полезное действие выполняет 100500 бесполезных операций но при этом хорошо масштабируется добавлением железа то этого железа достаточно никогда не будет
Мой комментарий был настолько общий, насколько это вообще возможно. Оптимизация кода — сложная и разносторонняя дисциплина, можно приводить много примеров как легких и полезных оптимизаций, так и сложных и ненужных. Да и перед разработчиками ПО задачи самые разные стоят. Одно дело программировать по четкому ТЗ, зная характеристики целевого железа, видя всю архитектуру и взаимосвязи компонентов перед глазами и рассчитав предварительно нагрузки, а другое дело — для себя по ночам новомодный стартап писать, не зная, выстрелит он, или вы так и останетесь его единственным пользователем.
В общем, да — само убирание со всех уровней дублирования логики и дублирования данных — это то, что приводит к улучшению читаемости и к улучшению надежности. Также дает возможность потом оптимизировать.
Но вот:
Не так. Закешировать — это продублировать. Это никогда не улучшает читаемость. Кеширование — это дублирование данных. Появляются новые проблемы — проблемы синхронности данных. Нужно создавать механизмы, проверяющие актуальность кеша, или обновляющие кеш при изменении главного источника данных. Есть БД — значит там главный источник данных.
Кеширование — это уже оптимизация. Т.е. низкоуровневая оптимизация. Ее не надо делать в процессе разработки, только в конце.
Вот почему я пишу, что хорошие программисты покупают сервера. Если программисты оптимизируют все время, то в коде появляются монстроидальные конструкции, дублирующие данные. Появляются неявные зависимости. И тогда добавить сервера и решить проблему железом просто не получится.
Один из замечательный приемов оптимизации — писать как можно проще. Это дает больше возможностей в дальнейшем распараллелить работу. Между потоками, между процессами, между серверам и как угодно.
Но вот:
закешировать результат тяжелых вычислений, минимизировать обращения к БД, удаленным обьектам,
Не так. Закешировать — это продублировать. Это никогда не улучшает читаемость. Кеширование — это дублирование данных. Появляются новые проблемы — проблемы синхронности данных. Нужно создавать механизмы, проверяющие актуальность кеша, или обновляющие кеш при изменении главного источника данных. Есть БД — значит там главный источник данных.
Кеширование — это уже оптимизация. Т.е. низкоуровневая оптимизация. Ее не надо делать в процессе разработки, только в конце.
Вот почему я пишу, что хорошие программисты покупают сервера. Если программисты оптимизируют все время, то в коде появляются монстроидальные конструкции, дублирующие данные. Появляются неявные зависимости. И тогда добавить сервера и решить проблему железом просто не получится.
Один из замечательный приемов оптимизации — писать как можно проще. Это дает больше возможностей в дальнейшем распараллелить работу. Между потоками, между процессами, между серверам и как угодно.
Даже совсем наоборот: хорошие программисты покупают сервера, а плохие оптимизируют.
В одной из компаний перед тем как садиться писать оценку проекта и комерческое приложение, я (в обход начальства) всегда спрашивал у заказчика...
Вас за это не уволили? Мне кажется, мало кому из начальства такое может понравиться.
Не дайте Астронавтам Архитектуры вас запугать!
Да-да, мне тоже в свое время очень понравился этот пост Спольски.
Тема раскрыта не до конца. Рассматривается только суровая реальность написания кода для стороннего заказчика.
Если заказчик — сама компания в которой ты работаешь (например, какой-нибудь SAAS) и поддерживать код и архитектуру, которую ты пишешь сейчас тебе предстоит годами, то я думаю вопрос о возможности говнокода, отказа от TDD и хороших практик тут вообще стоять не должен.
Если заказчик — сама компания в которой ты работаешь (например, какой-нибудь SAAS) и поддерживать код и архитектуру, которую ты пишешь сейчас тебе предстоит годами, то я думаю вопрос о возможности говнокода, отказа от TDD и хороших практик тут вообще стоять не должен.
Допустим мы хотим проверить, насколько удобно воспользоваться API некого, возможного партнёра, и хотим собрать прототип, неким образом обрабатывающий его данные. Скажем — строит какието стат. графики.
Второй вариант: К некой дате нужно выпустить некий промо(викторина/розыгрыш), который день покрутится, а после будет забыт и удалён.
Я в упор не вижу смысла в этих случаях заморачиваться с гибкой архитектурой, или заставлять людей переучиваться на TDD.
Второй вариант: К некой дате нужно выпустить некий промо(викторина/розыгрыш), который день покрутится, а после будет забыт и удалён.
Я в упор не вижу смысла в этих случаях заморачиваться с гибкой архитектурой, или заставлять людей переучиваться на TDD.
> Допустим мы хотим проверить, насколько удобно воспользоваться API некого, возможного партнёра
В этом случае проблем не вижу, в песочнице на дев-сервере попробовать можно и без TDD.
Хотя, я не понимаю как вы убедитесь что оно работает как вы ожидаете. Ручками будете API методы вызывать и сверять с ожидаемым результатом? А если завтра обновленное API партнера вместо ожидаемого графика вам пришлет котиков?
Как вы об этом узнаете? От клиентов? Как раз-таки в этом случае стороннего API без нормальной архитектуры и TDD вы далеко не уедете.
> К некой дате нужно выпустить некий промо(викторина/розыгрыш), который день покрутится, а после будет забыт и удалён.
Если считаете что это действительно простая задача и не требует архитектуры и TDD, то можете их не использовать.
Только помните: ничего не бывает более постоянного чем временное.
PS. Во всем нужен здравый смысл и мера
В этом случае проблем не вижу, в песочнице на дев-сервере попробовать можно и без TDD.
Хотя, я не понимаю как вы убедитесь что оно работает как вы ожидаете. Ручками будете API методы вызывать и сверять с ожидаемым результатом? А если завтра обновленное API партнера вместо ожидаемого графика вам пришлет котиков?
Как вы об этом узнаете? От клиентов? Как раз-таки в этом случае стороннего API без нормальной архитектуры и TDD вы далеко не уедете.
> К некой дате нужно выпустить некий промо(викторина/розыгрыш), который день покрутится, а после будет забыт и удалён.
Если считаете что это действительно простая задача и не требует архитектуры и TDD, то можете их не использовать.
Только помните: ничего не бывает более постоянного чем временное.
PS. Во всем нужен здравый смысл и мера
>>Хотя, я не понимаю как вы убедитесь что оно работает как вы ожидаете. Ручками будете API методы вызывать и сверять с ожидаемым результатом? А если завтра обновленное API партнера вместо ожидаемого графика вам пришлет котиков?
Собственно зачастую прототипы и проверяются в ручную — есть график или нет. даже если он немного не точен — то свою задачу, проверить, возможно ли что-то сделать или нет — он выполнил. А завтра — нам API может уже и не понадобиться. Опять таки — прототипы, как правило, клиентам не показываются. А если и показываются — то тщательно тестируются вручную, или автоматизированными тестами. И самое главное — прототип=далеко не едем.
Я думаю, если идёт речь о развитии прототипа, то лидер разработчиков должен взять на себя ответственность о уничтожении прототипа и начала разработки постоянного решения. Если же он принимает решение «да вроде и так работает, приделаем ещё пару костылей» — то это приводит к проблемам.
Викторина к 8 марта — ну всемы понимаем, что это не вечный проект, правда? :)
И да, чуть не забыл — xkcd.ru/i/292_v1.png (картинку вставить не могу, уж извините)
Собственно зачастую прототипы и проверяются в ручную — есть график или нет. даже если он немного не точен — то свою задачу, проверить, возможно ли что-то сделать или нет — он выполнил. А завтра — нам API может уже и не понадобиться. Опять таки — прототипы, как правило, клиентам не показываются. А если и показываются — то тщательно тестируются вручную, или автоматизированными тестами. И самое главное — прототип=далеко не едем.
Я думаю, если идёт речь о развитии прототипа, то лидер разработчиков должен взять на себя ответственность о уничтожении прототипа и начала разработки постоянного решения. Если же он принимает решение «да вроде и так работает, приделаем ещё пару костылей» — то это приводит к проблемам.
Викторина к 8 марта — ну всемы понимаем, что это не вечный проект, правда? :)
И да, чуть не забыл — xkcd.ru/i/292_v1.png (картинку вставить не могу, уж извините)
Ну да, главное чтобы все понимали что это только прототип. И не надо его завтра выкладывать в продакшн, хоть он и работает на первый взгляд =)
А вообще, суровая реальность в том, что хороший проект делается со второго раза, ну или уж точно не с первого. Первый вариант — обкатка идеи, сбор требований и анализ ошибок. Потом все переписывается правильно.
А вообще, суровая реальность в том, что хороший проект делается со второго раза, ну или уж точно не с первого. Первый вариант — обкатка идеи, сбор требований и анализ ошибок. Потом все переписывается правильно.
А викторина к 8 марта — это ж вечный проект. 8 марта каждый год внезапно случается). Или каждый год новую писать? )
Допустим мы хотим проверить, насколько удобно воспользоваться API некого, возможного партнёра, и хотим собрать прототип, неким образом обрабатывающий его данные. Скажем — строит какието стат. графики.
А Вам не кажется, что решение этой задачи и сводится к TDD в чистом виде?
А если разговор идёт о том, что людям на TDD придётся переучиваться… не понимаю, продакшн всё ещё без автоматического тестирования? Или дело дальше прототипов никогда не доходило?
TDD вообще начинается в тот момент, когда изучаешь новый для себя язык программирования или фреймворк — пишешь различные helloworld'ы, которые тебе показывают, как реально система реагирует на твой код. И этому в общем-то не нужно много учиться, можно только повышать уровень мастерства — систематизируя тесты и налаживая их автоматическую работу, используя межпроектные библиотеки тестов.
TDD всё же проверка, что система ожидаемо реагирует на код. Для изучения вообще непонятного API анализ дампов или просто вывода всё же предпочтительней.
И тесты на перед деплоем на продакшен ещё далеко не для всех норма.
И тесты на перед деплоем на продакшен ещё далеко не для всех норма.
Эх, старый разговор )
Но я, собственно, к чему про хелловорлды? У меня подобных тестов для стандартных библиотек и самого языка прилично. Как оказалось не зря — поведение меняется, да и сам бывает забываешь тонкости, можно тест посмотреть.
А в остальном да — чего уж спорить — в очердной раз сталкиваюсь с этим и грустно становится…
Но я, собственно, к чему про хелловорлды? У меня подобных тестов для стандартных библиотек и самого языка прилично. Как оказалось не зря — поведение меняется, да и сам бывает забываешь тонкости, можно тест посмотреть.
А в остальном да — чего уж спорить — в очердной раз сталкиваюсь с этим и грустно становится…
НТП сейчас такими скачками прыгает, что «код и архитектура, поддерживаемые годами» автоматически превратятся в говнокод и устаревшие практики. Почти с гарантией.
Если же это какая-нибудь специальная эзотерическая бухгалтерия, то их и не выбрасывают десятилетиями именно потому, что весь этот говнокод просто невозможно повторить, причем не только в хороших практиках, а вообще — никак.
Если же это какая-нибудь специальная эзотерическая бухгалтерия, то их и не выбрасывают десятилетиями именно потому, что весь этот говнокод просто невозможно повторить, причем не только в хороших практиках, а вообще — никак.
Разве код крупных проектов, используемых по всему миру постоянно переписывается с нуля?
Согласен, что определённые практики и представления об «идеальном» устаревают, но вот поддерживать иные вещи действительно приходится в течение нескольких технологических «волн». Разумеется, это не касается сайтов, которые не перерастают даже виртуальный хостинг.
Согласен, что определённые практики и представления об «идеальном» устаревают, но вот поддерживать иные вещи действительно приходится в течение нескольких технологических «волн». Разумеется, это не касается сайтов, которые не перерастают даже виртуальный хостинг.
Нет, конечно. Я, вероятно, не слишком внятно выразился.
Есть «хорошие практики», есть «плохие», есть «идеальные». Плохие остаются плохими с течением времени. Хорошие — превращаются в «так себе». «Идеальные» — либо в «так себе», либо в «плохие».
Я имел в виду, что писать «идеально» немного бессмысленно, поскольку через пару лет оно с гарантией перестанет быть идеальным.
Не опускаться ниже уровня «хорошо» и постоянно подтягивать до своего уровня, — разумеется, необходимо.
Есть «хорошие практики», есть «плохие», есть «идеальные». Плохие остаются плохими с течением времени. Хорошие — превращаются в «так себе». «Идеальные» — либо в «так себе», либо в «плохие».
Я имел в виду, что писать «идеально» немного бессмысленно, поскольку через пару лет оно с гарантией перестанет быть идеальным.
Не опускаться ниже уровня «хорошо» и постоянно подтягивать до своего уровня, — разумеется, необходимо.
Вот допиливать потом на перекурах плохая практика, потом начинает появляться практика допиливать плохой проект работа по 9-10 часов. Так быстро выгораешь и теряется удовольствие от работы, В последствии может упасть продуктивность труда. И хороший менеджер должен это дело мониторить и вовремя предотвращать
Ну не знаю, сталкивался с ситуацией когда в продакшен молча отправляют заведомо глючный код (код который не обрабатывает edge cases) с мотивировкой «нужно быстрее всё сделать» либо с просто молчаливым игнорированием проблемы.
Примерно через месяц кто-либо из менеджеров находит этот «баг», тратит час, разработчик пытается воспроизвести тратит два, затем фиксит, тратит в два раза больше чем нужно было вначале, при этом вносит ещё какой-то костыль.
И так каждый раз.
Причём что контора будет работать этот следующий месяц — известно заранее, ведь она уже года 4 работает на одного заказчика.
Ну не идиотизм ли?
Примерно через месяц кто-либо из менеджеров находит этот «баг», тратит час, разработчик пытается воспроизвести тратит два, затем фиксит, тратит в два раза больше чем нужно было вначале, при этом вносит ещё какой-то костыль.
И так каждый раз.
Причём что контора будет работать этот следующий месяц — известно заранее, ведь она уже года 4 работает на одного заказчика.
Ну не идиотизм ли?
>Ментальная ошибка в том, что чаще всего код не нужно поддерживать или нужно будет поддерживать не вам.
Если вам не нравится поддерживать плохой код, то почему вы его пишете?
Если вам не нравится поддерживать плохой код, то почему вы его пишете?
Меня тоже очень раздражает такой подход. Для меня писать максимально качественный код (в рамках имеющегося бюджета и ресурсов) вопрос профессиональной гордости.
А говорить что можно писать плохо т.к. поддерживать все равно не вам это все равно что наложить кучу соседу под дверь — убирать то все равно не вам. Просто однажды вы найдете такую же кучу и под вашей дверью.
Ну и как уже сказали сверху:
Качественно обычно и бывает быстро просто это становится заметно ближе к концу проекта.
А говорить что можно писать плохо т.к. поддерживать все равно не вам это все равно что наложить кучу соседу под дверь — убирать то все равно не вам. Просто однажды вы найдете такую же кучу и под вашей дверью.
Ну и как уже сказали сверху:
Задача грамотного лидера разработки убедить подопечных, что быстро писать можно будет только если код будет чистым. Тогда и не будет идеологического противостояния с бизнесом.
Качественно обычно и бывает быстро просто это становится заметно ближе к концу проекта.
Статья про какой-то странный мир, в котором только один разработчик и отсуствует конкуренция. Работая как фрилансер с почасовой оплатой и создавая проекты которые практически не нуждаются в суппорте никогда не жаловался на недостатки этого метода, если у клиента отлично работает один проект он обязательно найдет еще один и вдобавок друзей приведет, которым другие говнокода понаписали и просят денег за поддержку.
«Темой статьи является применение методов управления качеством в производстве программного обеспечения»…
Чтоб адекватно писать говнокод, надо уметь писать хороший код и иметь большой опыт написания хорошего кода. По крайней мере, очевидных «запахов» типа длинных методов и повторного использования переменных будет меньше. Нужно иметь за спиной этап, на котором качественный код является вопросом профессиональной гордости.
Чтоб адекватно писать говнокод, надо уметь писать хороший код и иметь большой опыт написания хорошего кода. По крайней мере, очевидных «запахов» типа длинных методов и повторного использования переменных будет меньше. Нужно иметь за спиной этап, на котором качественный код является вопросом профессиональной гордости.
Если fixed price — ок, еще есть надежда, что код будут писать грамотно, но если time & materials…
Откуда, интересно, у вас такое мнение? Зачем писать код грамотно, если можно написать быстро и получить в итоге больше денег за меньше времени и трудозатрат? Не говоря уже о случае, когда сроки превышены, и исполнитель начинает работать себе в убыток. Думаете, его будет заботить качество кода в такой ситуации?
У кода есть два аспекта: чистота и работоспособность. Другими словами, надо стремиться к «чистому коду, который работает правильно». От баланса между этими двумя аспектами и зависит подход к разработке. Когда пишутся прототипы, то основная цель — сделать работающий код. Чистота его на тот момент не нужна. Но для поддержки кода в будущем, исправления найденных в нем дефектов, адаптации его под новые задачи без огромных затрат времени нужно заботиться и об аспекте чистоты.
В XP (eXtreme Programming) специально выделяется практика написания spike. Это специальный формат задачи (технической истории), цель которой уменьшить неопределенность и технологические риски при реализации основной задачи. По правилам код, написанный во время реализации spike, не может быть перенесен в основную ветку. Поэтому его можно писать, не заботясь о поддержке в будущем.
В целом, от баланса между указанными двумя аспектами и зависит решение, стоит ли писать чистый код в том или ином случае. Но люди, которые привыкли писать чистый код, потом просто не могут иначе… :)
В XP (eXtreme Programming) специально выделяется практика написания spike. Это специальный формат задачи (технической истории), цель которой уменьшить неопределенность и технологические риски при реализации основной задачи. По правилам код, написанный во время реализации spike, не может быть перенесен в основную ветку. Поэтому его можно писать, не заботясь о поддержке в будущем.
В целом, от баланса между указанными двумя аспектами и зависит решение, стоит ли писать чистый код в том или ином случае. Но люди, которые привыкли писать чистый код, потом просто не могут иначе… :)
>>От баланса между этими двумя аспектами и зависит подход к разработке
Простите, вы хотите сказать, что чистый код менее работоспособный, или работоспособный — менее чистый? Это ведь бред.
>>Когда пишутся прототипы, то основная цель — сделать работающий код.Чистота его на тот момент не нужна.
Почему? Попробуйте писать чистый код, и Вы увидите, что писать стало БЫСТРЕЕ (а ведь мы хотим писать прототипы быстрее). Ошибки (которые надо устранять и в прототипах) — исправляются много быстрее.
Каждый раз, когда Вы пишете грязный код, Вы гадите себе в проф. качества. Да, в данном конкретном случае Ваш код не помешал. Но на подсознательном отложилась возможность писать кривой код. И это ОБЯЗАТЕЛЬНО вылезет Вам боком. Так что чистый код — писать нужно в любом случае.
Простите, вы хотите сказать, что чистый код менее работоспособный, или работоспособный — менее чистый? Это ведь бред.
>>Когда пишутся прототипы, то основная цель — сделать работающий код.Чистота его на тот момент не нужна.
Почему? Попробуйте писать чистый код, и Вы увидите, что писать стало БЫСТРЕЕ (а ведь мы хотим писать прототипы быстрее). Ошибки (которые надо устранять и в прототипах) — исправляются много быстрее.
Каждый раз, когда Вы пишете грязный код, Вы гадите себе в проф. качества. Да, в данном конкретном случае Ваш код не помешал. Но на подсознательном отложилась возможность писать кривой код. И это ОБЯЗАТЕЛЬНО вылезет Вам боком. Так что чистый код — писать нужно в любом случае.
Простите, вы хотите сказать, что чистый код менее работоспособный, или работоспособный — менее чистый? Это ведь бред.
Это два независимых аспекта кода. Я как раз это и написал.
Почему? Попробуйте писать чистый код, и Вы увидите, что писать стало БЫСТРЕЕ (а ведь мы хотим писать прототипы быстрее). Ошибки (которые надо устранять и в прототипах) — исправляются много быстрее.
Дело в том, что часто для проверки какой-то идеи не надо создавать хорошего, поддерживаемого дизайна, использовать шаблоны проектирования, следить за размером методов и классов. Можно даже использовать не рекомендуемые в обычной жизни вещи: статику, прямое обращение к файловой системе, базе данных и т.д. И это будет реально быстрее.
Каждый раз, когда Вы пишете грязный код, Вы гадите себе в проф. качества. Да, в данном конкретном случае Ваш код не помешал. Но на подсознательном отложилась возможность писать кривой код. И это ОБЯЗАТЕЛЬНО вылезет Вам боком. Так что чистый код — писать нужно в любом случае.
Я как раз сторонник чистого кода. Уже 6 лет работаю строго по TDD, на каждом проекте применяется 100% ревью кода, парное программирование на сложных задачах и статические анализаторы (очень грамотно настроенный Sonar). Но ничего не мешает мне пробовать идеи без всех этих техник, чтобы потом выбросить этот код и написать хорошее решение. Нет смысла вкладывать в качество того, что может не справиться с задачей, поставленной требованиями.
>>Это два независимых аспекта кода. Я как раз это и написал.
Когда мы говорим о независимых аспектах — не нужно добиватся баланса. Они же независят.
Для проверки идеи — хорошобы использовать подходящий дизайн :). Но тем не менее, код всё равно нужно оставлять чистым. пусть Вы используеете статику, не проверяете переменные и так далее — но не нужно всё запихивать в одну 1000-строковую функцию. Вы же через неделю сами там потеряетесь.
Очень часто, если Вы проверяли идею, и нашли её плохой, то коллеги захотят перепроверить Ваш код — просто чтоб удостоверится, что Вы проверяли идею правильно. И если Ваш код будет нечитаем — им придётся потратить кучу времени чтоб разобраться в нём. Так зачем такое делать? К тому же, если код будет чистым, Вы сможете использовать если не весь прототип, так его части в рабочем проекте.
И да, самое главное — писать чистый код ничуть не медленее чем грязный. А вот работать с ним в дальнейшем — намного быстрее.
>>Нет смысла вкладывать в качество того, что может не справиться с задачей, поставленной требованиями.
Не в качество, а в понятность и чистоту. Возможно нет смысла, использовать ОРМ для проверки идеи, но если Вы выделите обращения к базе в отдельный «класс» функций/методов — то Вам не захочется повеситься, когда коллега попросит Вас сменить СУБД и повторить эксперемент. Замедлит ли это Вашу работу? Ну, если Вы тратите 90% времени на кодинг — то да. Иначе — разницы Вы не заметите.
Когда мы говорим о независимых аспектах — не нужно добиватся баланса. Они же независят.
Для проверки идеи — хорошобы использовать подходящий дизайн :). Но тем не менее, код всё равно нужно оставлять чистым. пусть Вы используеете статику, не проверяете переменные и так далее — но не нужно всё запихивать в одну 1000-строковую функцию. Вы же через неделю сами там потеряетесь.
Очень часто, если Вы проверяли идею, и нашли её плохой, то коллеги захотят перепроверить Ваш код — просто чтоб удостоверится, что Вы проверяли идею правильно. И если Ваш код будет нечитаем — им придётся потратить кучу времени чтоб разобраться в нём. Так зачем такое делать? К тому же, если код будет чистым, Вы сможете использовать если не весь прототип, так его части в рабочем проекте.
И да, самое главное — писать чистый код ничуть не медленее чем грязный. А вот работать с ним в дальнейшем — намного быстрее.
>>Нет смысла вкладывать в качество того, что может не справиться с задачей, поставленной требованиями.
Не в качество, а в понятность и чистоту. Возможно нет смысла, использовать ОРМ для проверки идеи, но если Вы выделите обращения к базе в отдельный «класс» функций/методов — то Вам не захочется повеситься, когда коллега попросит Вас сменить СУБД и повторить эксперемент. Замедлит ли это Вашу работу? Ну, если Вы тратите 90% времени на кодинг — то да. Иначе — разницы Вы не заметите.
И да, самое главное — писать чистый код ничуть не медленее чем грязный.
Всё же медленнее.
Не в качество, а в понятность и чистоту.
Никому не нужную в прототипе или эксперименте.
>>Всё же медленнее.
Почему Вы так считаете? Ещё раз обращу внимание — архитектурные изыски и чистота кода — РАЗНЫЕ вещи.
>>Никому не нужную в прототипе или эксперименте.
Самые важные качества эксперимента — достоверность и повторяемость. Без чистого кода проверить это сложно.
И самое главное — писать чистый код даже в самых черновых наработках — так же важно, как и всключать сигнал поворота на пустой дороге: это вырабатывает привычку. И возможно однажды дорога окажется не такой пустой, как Вы думали, а эксперемент — пойдёт в продакшн.
Почему Вы так считаете? Ещё раз обращу внимание — архитектурные изыски и чистота кода — РАЗНЫЕ вещи.
>>Никому не нужную в прототипе или эксперименте.
Самые важные качества эксперимента — достоверность и повторяемость. Без чистого кода проверить это сложно.
И самое главное — писать чистый код даже в самых черновых наработках — так же важно, как и всключать сигнал поворота на пустой дороге: это вырабатывает привычку. И возможно однажды дорога окажется не такой пустой, как Вы думали, а эксперемент — пойдёт в продакшн.
Почему Вы так считаете?
Один из признаков чистого кода — давать семантические имена переменным, функциям, классам и методам. Над этим надо думать, зачастую в словари лезть, в грамматические справочники и т. п., а в прототипе я просто буду использовать буквы алфавита по порядку :) Это и многие другие подобные вещи отнимают время капля за каплей.
Самые важные качества эксперимента — достоверность и повторяемость.
Эксперимент я имел в виду не в научном смысле слова, а в смысле «научного тыка». Посмотреть, а что будет если…
а эксперемент — пойдёт в продакшн.
Выше я где-то писал, что чтобы исключить это использую различные платформы для прототипов/экспериментов (за редким исключением) и продакшена.
>>Это и многие другие подобные вещи отнимают время капля за каплей.
Если не секрет, какое соотношение времени для Вас между обдумыванием решения и кодингом?
Знаете, вся эта ерунда про «отнимает время» — просто отговорки. И я их раньше тоже повторял. Пока не нахватался граблей по самое немогу :). Тем более, что подобрать правильное имя для переменной гараздо проще, чем потом вспоминать, как же я там назвал результат выполнения вычеслений — толи CR, толи просто C, толи просто r… особенно в языках типа PHP, где пременную можно создать без предварительного обьявления.
>>Посмотреть, а что будет если…
Но после того, как результат получен — всё таки хорошо бы понять, что результат получен не случайно.
Если не секрет, какое соотношение времени для Вас между обдумыванием решения и кодингом?
Знаете, вся эта ерунда про «отнимает время» — просто отговорки. И я их раньше тоже повторял. Пока не нахватался граблей по самое немогу :). Тем более, что подобрать правильное имя для переменной гараздо проще, чем потом вспоминать, как же я там назвал результат выполнения вычеслений — толи CR, толи просто C, толи просто r… особенно в языках типа PHP, где пременную можно создать без предварительного обьявления.
>>Посмотреть, а что будет если…
Но после того, как результат получен — всё таки хорошо бы понять, что результат получен не случайно.
К сожалению, вы читаете сквозь строки и не хотите прислушаться к тому, что я вам пытаюсь донести. Аспекты независимые, но каждый из них отнимает определенное время. Решение = уровень первого аспекта + уровень второго аспекта. Вот и идет речь о балансе, когда не надо в обоих аспектах добиваться максимума.
Если для вас чистота кода = длина методов, то тут я могу вас заверить, что это больше здравый смысл и он применяется даже в прототипе. Я веду речь о разделении кода на классы, построении правильной ООП модели, разделении ответственности, применении дизайн паттернов. На это уходит время. Банально хотя бы на то, чтобы подумать над дизайном, а потом его применить.
С кодом прототипа никто работать не будет. В этом и особенность. Именно поэтому и открывается возможность снизить планку качества кода на нем. В вашем примере, если коллега попросит сменить СУБД и повторить эксперимент, то я вынесу эти методы автоматизированными рефакторингами моей IDE. А если не попросит? Зачем тратить на это время? Алгоритм прост: сделал чтобы работало -> проверил идею -> задумался будут ли доработки -> выбросил код или привел в порядок. :)
Если для вас чистота кода = длина методов, то тут я могу вас заверить, что это больше здравый смысл и он применяется даже в прототипе. Я веду речь о разделении кода на классы, построении правильной ООП модели, разделении ответственности, применении дизайн паттернов. На это уходит время. Банально хотя бы на то, чтобы подумать над дизайном, а потом его применить.
С кодом прототипа никто работать не будет. В этом и особенность. Именно поэтому и открывается возможность снизить планку качества кода на нем. В вашем примере, если коллега попросит сменить СУБД и повторить эксперимент, то я вынесу эти методы автоматизированными рефакторингами моей IDE. А если не попросит? Зачем тратить на это время? Алгоритм прост: сделал чтобы работало -> проверил идею -> задумался будут ли доработки -> выбросил код или привел в порядок. :)
>>Вот и идет речь о балансе, когда не надо в обоих аспектах добиваться максимума.
Но ведь без разумного минимума — невозможно, правда? :)
Я к тому, что на самом деле, писать код чисто — не требует вообще дополнительного времени. К тому же, это даёт гарантию что код работает нужным образом а не «как то там работает».
Вот простой пример из жизни: Сделали быстренько рефакторинг функции, чтоб проверить идею. Работает! Потом прадва оказалось, что ничего не работает, данные как брались напрямую из базы, так и продалжали оттуда браться. Просто сервак был незагруженный, и этого небыло видно.
А ведь будь код более читаемым(а не вывод в поток, в перемешку со сбором данных и всё в одной функции) — ошибка была бы видна сразу.
Теперь обьясню, что я называю чистотой кода. Чистый код — это код, который требует минимум времени на понимание того, что он выполняет. И как раз очень часто неуёмное следование паттернам проектирования приводят к тому, что код становится крайне тяжолым для понимания.
Поэтому мой посыл очень прост — если код Вашего прототипа может посмотреть другой человек, и быстро понять его — отлично, всё в порядке. Если для другого человека, становится загадкой, что тут вообще происходит — то наверное с кодом проблемы.
Но ведь без разумного минимума — невозможно, правда? :)
Я к тому, что на самом деле, писать код чисто — не требует вообще дополнительного времени. К тому же, это даёт гарантию что код работает нужным образом а не «как то там работает».
Вот простой пример из жизни: Сделали быстренько рефакторинг функции, чтоб проверить идею. Работает! Потом прадва оказалось, что ничего не работает, данные как брались напрямую из базы, так и продалжали оттуда браться. Просто сервак был незагруженный, и этого небыло видно.
А ведь будь код более читаемым(а не вывод в поток, в перемешку со сбором данных и всё в одной функции) — ошибка была бы видна сразу.
Теперь обьясню, что я называю чистотой кода. Чистый код — это код, который требует минимум времени на понимание того, что он выполняет. И как раз очень часто неуёмное следование паттернам проектирования приводят к тому, что код становится крайне тяжолым для понимания.
Поэтому мой посыл очень прост — если код Вашего прототипа может посмотреть другой человек, и быстро понять его — отлично, всё в порядке. Если для другого человека, становится загадкой, что тут вообще происходит — то наверное с кодом проблемы.
У Вас достаточно альтернативный подход к понятию «чистоты». Ну вот есть код, смотря на который, я прекрасно понимаю, что он делает, он прост как дважды два. Но в продакшн я его не пущу, поскольку SQL запросы выполняемые из шаблона с потенциальной уязвимостью к инъекциям — это не то, что я называю чистым кодом )
Но для прототипирования — никаких нареканий — нормальный код и даже более приемлемый, чем разнесение его на несколько файлов по две три строки. Хотя в целом, разумеется, всё зависит от целей и конкретного случая.
Но для прототипирования — никаких нареканий — нормальный код и даже более приемлемый, чем разнесение его на несколько файлов по две три строки. Хотя в целом, разумеется, всё зависит от целей и конкретного случая.
Вы используеете статику, не проверяете переменные и так далее — но не нужно всё запихивать в одну 1000-строковую функцию
Почему не нужно? Разница между прототипом и не прототипом — не следование в первом случае ТДД. Т.е. не покрывается тестами и не рефакторится. Поэтому в прототипе, 1000 строк в методе — да без проблем. Если это единственный логический кусок. Лезет напрямую в базу? Да тоже без проблем. Это просто отдельный большой логический кусок.
Фокус в том, что потом рефакторить такой один метод вполне не сложно, если прототип останется. Но разбиение на небольшие методы, и написание тестов — замедляет разработку, хотя не сильно. А если прототип не выстрелит, как идея вообще? Стоит ли тратить время на тесты и на постоянный рефакторинг?
Потом, сам прототип призван что-то показать. Его можно будет оставить, если только он вообще делает что нужно, а не имитирует. Например, я делал прототип. Чтобы не тратить время, хотел набросать быстро на MS-SqlServer. Логично. На SQL можно гораздо быстрее что-то набросать. Задача прототипа — всего лишь увидеть, работает ли предложенная мат-модель на реальных данных или нет. Т.е. дает нужный результат или нет. Оказалась засада — не выдержал сервер работы с деревьями. Хотя, меня скорость совершенно в прототипе не интересовала. Но он как-то совсем не мог работать. Пришлось перенести частично в процедуры на дотнете. Начал прототип дышать и работать.
Но на чистовик нужно было переписывать совершенно другое. Модель только оставить. А само хранение данных, обработка, алгоритмы, — совсем другие.
Разрабатывать тот прототип по ТДД не имело смысла, т.к. ТДД — это постоянная поддержка кода в чистоте на случай изменений. Т.е. нацелена на то, чтобы можно было развивать продукт. Но задача прототипа — не развитие прототипа.
Если уже не хочется тратить время на написание кода два раза, то выбирают функциональный язык, который хорошо работает с любыми данными и позволяет даже в прототипе соблюдать лаконичность кода.
>>Поэтому в прототипе, 1000 строк в методе — да без проблем.
Проблема в том, что в этих 1000 строках Вы потеряетесь. И если прототип с первого раза не запустится (да, расскажите как Вы пишите 1000 строковые методы без ошибок) — прийдётся удалять, и переписывать всё с начала (О да, и такое было :))
Абсолютно не понимаю Выши рассуждения на тему TDD. Чистый код, можно и нужно писать независимо от того, применяете Вы TDD или нет. Просто если Вы TDD не применяете — возможно код будет содержать больше ошибок. И нужно будет больше потратить время на проверку после рефакторинга.
Поймите, всё что я хочу сказать — стоит всего лишь придерживаться простейших правил, и ваш код будет легко читаем и понятен. независимо от того, прототип это, или нет. И на скорости это отрицательно точно не скажется.
Какие это правила? Читаемые и адекватные названия методов/переменных/классов и так далее, лаконичность функций (попробуйте ограничить размер метода хотя бы 10 строками).
Проблема в том, что в этих 1000 строках Вы потеряетесь. И если прототип с первого раза не запустится (да, расскажите как Вы пишите 1000 строковые методы без ошибок) — прийдётся удалять, и переписывать всё с начала (О да, и такое было :))
Абсолютно не понимаю Выши рассуждения на тему TDD. Чистый код, можно и нужно писать независимо от того, применяете Вы TDD или нет. Просто если Вы TDD не применяете — возможно код будет содержать больше ошибок. И нужно будет больше потратить время на проверку после рефакторинга.
Поймите, всё что я хочу сказать — стоит всего лишь придерживаться простейших правил, и ваш код будет легко читаем и понятен. независимо от того, прототип это, или нет. И на скорости это отрицательно точно не скажется.
Какие это правила? Читаемые и адекватные названия методов/переменных/классов и так далее, лаконичность функций (попробуйте ограничить размер метода хотя бы 10 строками).
Я вас вполне понимаю и только за — писать чистый код. И тоже считаю, что это быстро. Также, если сильно долго думать, то код может стать нечистым. Как раз желание писать быстро порождает необходимость в лаконичности.
Но мы про прототипы. Применяю я ТДД или нет — сильно влияет на чистоту. Имею ввиду постоянный рефакторинг. Чтобы соблюдать чистоту, нужно на каждом шаге рефакторить (и как это без тестов делать? с ошибками разве что). Если не рефакторить, то значит «планировать заранее» — а это уже никаким боком не относится к прототипированию. Знали бы, что получится, то не нужно было бы прототип писать.
Рефакторинг замедляет разработку. Может и ускорить местами, поэтому в прототипе тоже делается, но от случая к случаю.
Потом, чистота кода — это немного неоднозначное явление. Из большого метода в 1000 строк легко в нормальном IDE буквально почти мышкой сделать маленькие — повыносить методы, классы и т.д. А вот из порезанного кода не всегда получается перекроить что-то совсем новое. Вы при рефакторинге смотрите не повторяющиеся куски, выносите, думаете, какое имя дать более правильное. Но тем не менее, такое улучшение кода дает увеличение производительности где-то только в перспективе. В близкой перспективе может оказаться, что код, разбитый на куски, имеет неявные зависимости между разными частями. И как только стукнет в голову изменить ход работы прототипа кардинально — сразу возникают проблемы.
Делать методы маленькими, заботиться о чистоте — это хорошо для большого процесса и «ленивого» создания архитектуры. Т.е. в том случае, когда это не прототип и вы имеете время. И после каждого шага любуетесь кодом и сглаживаете неровности.
Потом, прототип должен быть небольшим. Если у вас в прототипе такой объем кода, который уже тянет на проект и надо будет его развивать, читать другим людям, поддерживать — то скорее всего это уже не прототип и что-то сделали неправильно.
Поэтому, лучше всего использовать, повторюсь, другие, декларативные языки. Чтобы можно было как можно короче, как можно быстрее проверить идею. А не бороться с говнокодом с помощью рефакторинга.
А вообще, мы спорим сейчас о двух крайностях. Я с одной стороны (и другие), вы с другой. Да, недорогие рефакторинги можно в прототипе и проводить — менять имена например. С выносом методов не так очевидно. Тоже можно, но так, чтобы не откатываться если что. В прототипировании нет правил — цель — что-то проверить и как можно с меньшими потерями. Качество, количество багов не так интересует, как «показать результат побыстрее».
Но мы про прототипы. Применяю я ТДД или нет — сильно влияет на чистоту. Имею ввиду постоянный рефакторинг. Чтобы соблюдать чистоту, нужно на каждом шаге рефакторить (и как это без тестов делать? с ошибками разве что). Если не рефакторить, то значит «планировать заранее» — а это уже никаким боком не относится к прототипированию. Знали бы, что получится, то не нужно было бы прототип писать.
Рефакторинг замедляет разработку. Может и ускорить местами, поэтому в прототипе тоже делается, но от случая к случаю.
Потом, чистота кода — это немного неоднозначное явление. Из большого метода в 1000 строк легко в нормальном IDE буквально почти мышкой сделать маленькие — повыносить методы, классы и т.д. А вот из порезанного кода не всегда получается перекроить что-то совсем новое. Вы при рефакторинге смотрите не повторяющиеся куски, выносите, думаете, какое имя дать более правильное. Но тем не менее, такое улучшение кода дает увеличение производительности где-то только в перспективе. В близкой перспективе может оказаться, что код, разбитый на куски, имеет неявные зависимости между разными частями. И как только стукнет в голову изменить ход работы прототипа кардинально — сразу возникают проблемы.
Делать методы маленькими, заботиться о чистоте — это хорошо для большого процесса и «ленивого» создания архитектуры. Т.е. в том случае, когда это не прототип и вы имеете время. И после каждого шага любуетесь кодом и сглаживаете неровности.
Потом, прототип должен быть небольшим. Если у вас в прототипе такой объем кода, который уже тянет на проект и надо будет его развивать, читать другим людям, поддерживать — то скорее всего это уже не прототип и что-то сделали неправильно.
Поэтому, лучше всего использовать, повторюсь, другие, декларативные языки. Чтобы можно было как можно короче, как можно быстрее проверить идею. А не бороться с говнокодом с помощью рефакторинга.
А вообще, мы спорим сейчас о двух крайностях. Я с одной стороны (и другие), вы с другой. Да, недорогие рефакторинги можно в прототипе и проводить — менять имена например. С выносом методов не так очевидно. Тоже можно, но так, чтобы не откатываться если что. В прототипировании нет правил — цель — что-то проверить и как можно с меньшими потерями. Качество, количество багов не так интересует, как «показать результат побыстрее».
Вообще то я не про рефакторинг. Я о том, что бы заранее держать минимально необходимую структуру. Это не сложно, отнюдь.
ПРоблема 1000-строкового метода не в том, что его сложно рефакторить. Проблема в том, что тяжело понять, что там происходит :). да и дописывать его — ещё то удовольствие — приходится постоянно скролить, чтобы вспомнить названия переменных/ключей. И всё это — действительно сильно замедляет разработку прототипа.
Впринципе — да, если создание прототипа занимает 2-3 часа, после чего его удаляем, и результат для коллектива не принципиальный — то можно делать как угодно — за это время особо не наговнакодите. Ну всмысле — совсем уж страшно.
Но если прототип — это нечто большее, скажем — некая страничка на сайте, некоторая фича в приложении — то стоит подходить чуть более ответственно.
ПРоблема 1000-строкового метода не в том, что его сложно рефакторить. Проблема в том, что тяжело понять, что там происходит :). да и дописывать его — ещё то удовольствие — приходится постоянно скролить, чтобы вспомнить названия переменных/ключей. И всё это — действительно сильно замедляет разработку прототипа.
Впринципе — да, если создание прототипа занимает 2-3 часа, после чего его удаляем, и результат для коллектива не принципиальный — то можно делать как угодно — за это время особо не наговнакодите. Ну всмысле — совсем уж страшно.
Но если прототип — это нечто большее, скажем — некая страничка на сайте, некоторая фича в приложении — то стоит подходить чуть более ответственно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Об идеальном коде и суровой реальности