Реклама
Комментарии 55
Эти парни любят абстракции даже больше, чем сами программисты.

Ещё они любят картинки и рисовать процессы в них. :)
Млин, а что такое уникальный код?
Рамки задает задает фреймворк.
Алгоритмы типовые в основном.
Сидишь и из кубиков складываешь как нужно в текущей задаче.
У меня не было за всю жизнь «уникального кода» кроме костылей придуманных мною.
Даже работа с апи руцента по их протоколу это не уникальный код (а просто очень редкий случай, человек 100 подобное я думаю уже писали) им просто не делятся.
вот да.
хотя пару раз в год «палка стреляет» и я пишу на проде достаточно уникальный код.
Думаю посмотреть в сторону кодовой базы опенсорса — может у них есть места для этого?
Вот вот. И как быть например в ситуации:
Андроид-приложение. Экран «Делать Х» (Х можно делать разными способами, в разные места, с разными ограничениями). Реализован список все полей (с нужной вспомогательной обвязкой вроде) который в принципе могут потребоваться, какие именно поля — решает сервер. Сервер трогать нельзя, совсем нельзя (потому что на нем за список полей и обработку данных с этого экрана отвечает по сути отдельный закрытый компонент). Порядок полей должен быть красивым. Сделано жестким заданием порядка в layout. Да, можно полностью руками конструировать GUI либо попробовать Jetpack Compose (а с порядком по другому решить как то). Но это переписывать достаточно много.
Для одного набора подзадач вида «делать X способом Y1..Y3» существующий порядок полей настолько сильно мешал что пришлось часть полей (вместе с логикой поддержки) задублировать (и показывать их).
Это уже не уникальный код?
А переписка всей архитектуры данного модуля на Jetpack Compose была бы написанием уникального кода? (при том что текущий вариант работает вполне хорошо а беклог и так огромный)
ты занят полезным делом, если пишешь уникальный код.

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

Осталось научиться делать оптимальный в каждом случае выбор — "писать код, б..." или "копипастить со stackoverflow"
Когда вы копипастите со stackoverflow, вы теряете время. Надо больше уникального кода.
Мне показалось, или программистов к кодерам прировняли?
Программист в отличии от кодера еще и постановку делает — т.е. анализирует задачу, проектирует архитектуру и т.д. «глюпостями», нужными для того чтобы писать онли уникальный код занимается большую часть времени.
А мне представляется, что все, что НЕ приближает к решению поставленной задачи, является потерей времени. А за скорость приближения отвечает эффективность отдельного программиста или команды (например, переиспользование кода или, наоборот, ненужное создание велосипеда).
Ну, и вообще, если не подумать над архитектурой вначале, то можно сколько угодно долго писать уникальный код, который не приближает к решению задачи, а даже отдаляет от нее. Поэтому, мне лично такое определение полезной деятельности не нравится.
Более того, и думать над архитектурой без определения цели, позиционирования, модели продаж, срока окупаемости и т.д — бесполезно.

Иначе эта превосходная архитектура и её реализация просто пополнят кладбище ненужных проектов.
Очень много в каких областях написание любого кода — и есть потери. Самый лучший код — это тот, которого нет, но его задача все равно исполняется. Не счесть количества месяцев, которые удалось не заниматься ненужной фигней после того как я спрашивал «а что будет, если нам НЕ реализовывать вот эту функцию?» Я бы поэтому заменил «уникальный» код на «нужный».
>Я бы поэтому заменил «уникальный» код на «нужный».

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

Зачем продукт-менеджеру менеджить, лиду лидить, мастеру мастерить, аналитику аналитить. Лучше на синергию надеяться, чтобы как-нибудь само.

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

Если вы кодер, то да. Хотя и в этом случае мыслительные процессы в перерывах между стуком пальцами никто не отменял.
Что такое уникальный код? Уникальный в мире? Уникальный в проекте? Уникальный сегодня?
Не могу не удержаться в свете последней статьи автора про кавычки. «Уникальный». Что бы это ни значило. Всё, пацаны, расходимся.

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

Это вас после «понедельничного» утреннего митинга у начальника так торкнуло?

«Или вообще лёг спать на работе», без этого не могу во второй половине дня продуктивно работать. На предприятии это считалось лютым косяком, даже если и в обеденный перерыв. Часто видел, народ прикрывшись монитором, спит. Из-за этого отчасти и уволился ((
По-моему, надо смотреть не на процесс, а на результат. И написание/использование кода — лишь один из способов результата достичь.
Вот я неделю читал код драйвера, добавлял отладку, тестировал. В итоге решил проблему двумя строчками. Две строчки за неделю = нулевая производительность/польза. Работающее устройство = довольный клиент, новые заказы, развитие компании.

Уникальный код? 80% задач повторяются с определенной периодичностью, не нужно каждый раз форыч изобретать, чтобы выполнить задачу. Я так понимаю, что когда автору нужен новый компьютер, то он идет в магазин радиодеталей, покупает транзисторы, делает самодельную плату, распаивает всё это добро на плате, тратит огромное количество времени и в итоге получает непонятное нечто. А мог бы просто воспользоваться проверенными, оттестированными практиками — не изобретать велосипед. Моё мнение, что автор всё же любит тешить самолюбие, мол смотрите, я потратил время и написал УНИКАЛЬНЫЙ код, такого больше нет нигде, я сделяль. И вы так же делайте. Только бизнесу плевать на эту уникальность, решай больше задач за меньшие сроки (95%)

А что, если разработчик занимался отладкой и разбирался в куче говно-уникального кода после такого же товарища, который не утруждал себя тем, чтобы «думать над архитектурой» и «шариться по зависимостям»? Допустим, он исправил несколько критических багов несколькими строчками кода за несколько дней. Получается, что он работал с крайне низкой производительностью, а тот, кто написал весь этот код — Д`Артаньян.
Если бы Вы работали на проекте, где количество строк измеряется сотнями тысяч и Вам нужно было бы разработать какой-то функционал, то вы бы с ходу взялись за написание кода? Хорошо, если там всё покрыто тестами и они сразу все упали, а если бы проблемы вскрылись на регрессе или, о боже, в продакшене? Насколько эффективной Вы сможете считать свою работу после такого?
Я понимаю, что можно много рассуждать о полезности той или иной методологии разработки, но подвергать сомнению необходимость стандартных процессов вроде отладки, проектирования архитектуры и анализа существующего кода по меньшей мере странно.
Я надеюсь, что Вы не станете в ближайшее время менеджером, иначе с таким подходом это приведёт к тому, что производительность на вашем проекте будет измеряться количеством написанных строк.

Уникальный код, говорите?
На клавиатуре? Какой-то упрощенный подход, кмк.


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


Если он обсуждает с разработчиком электроники вопрос, в каком виде данные с ацп лучше передавать, он уже балду пинает?


Если он объясняет своему коллеге, как в данной ситуации будет лучше организовать структуру базы данных, (для окружающих — сидят два мужика и полтора часа квадратики на листе бумаге рисуют) он уже фигней страдает?


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


Если он стоит в цеху у рядом с наладчиком, и пытается понять, чем неудобна текущая версия софтины, которой этот наладчик пользуется...


По моему опыту, современный инженер — разработчик софта тратит непосредственно на написание кода не так уж много времени.


Более того, если программер сидит на работе за монитором, вперившись в отладчик или колотит по клавиатуре — это еще не значит, что он действительно работает.


Верно и обратное- если он на работе отсутствует — это совсем не значит, что он бездельничает...

По моему опыту хороший современный инженер (любой) не тратит на непосредственно разработку так уж много времени.
Даже строительный, или машиностроительный, или электронщик — основное время занимают переписка, совещания, просмотр каталогов и серфинг интернета, подбор и анализ решений, запросы цен и сроков, доказательство своих решений другим лицам, проверка соответствия госнормам, и так далее.
Если он изучает логи системы, пытаясь понять причины подвисаний...
Значит он или тот кто писал систему плохо молился.
Если он стоит в цеху у рядом с наладчиком, и пытается понять, чем неудобна текущая версия софтины, которой этот наладчик пользуется...
Значит он или тот кто писал софтину плохо молился.
По моему опыту, современный инженер — разработчик софта тратит непосредственно на написание кода не так уж много времени.
Ну во все времена программист тратит на создание ошибок не более 10% времени. Все остальное время он эти ошибки устраняет. Причем оставшееся время рекурсивно делится в той же пропорции.
Если он объясняет своему коллеге, как в данной ситуации будет лучше организовать структуру базы данных, (для окружающих — сидят два мужика и полтора часа квадратики на листе бумаге рисуют) он уже фигней страдает?
Ну с учетом того что уже овер 25 лет существуют тулзы, которые позволяют рисуя оные квадратики на мониторе параллельно и реализацию оной структуры БД получать, то делают абсолютно необходимую работу абсолютно неэффективным способом. А если эффективным — ну в общем то это и есть написание оного уникального кода.
То есть, если программер калякает на листочках математические формулы, пытаясь свести вашу задачу к обычному линейному дифференциальному уравнению, он уже бездельничает? (Про других не скажу, но почему-то мне проще такие вещи делать на бумаге. Карандашом.)
Ну то что не в IDE это делать — это точно. Ну в общем то можно не на бамашке карандашиком, а на планшете распознающем рукописный ввод стилусом. Или во всяких маткадах по старинке. Оно как бы позволяет часть преобразований на комп переложить, хотя бы элементарных. Да в общем то и кота какого-никакого сгенерить они вроде как умеют, который в общем то может за основу для причесывания пойтить. Со временем это станет гораздо более совершенным. Т.е. как бы опять же процесс то ли обеспечения уникальности то ли само написание оного уникального кода.
Т.е. все о чем вы говорите — абсолютно справедливо, в случае если рассматривать это через призму существующих технологий хотя бы частичной автоматизации этих процессов, и именно как средство добиться того, чтобы код писать и отлаживать можно было только уникальный.
Ну что тут скажешь. Интересная позиция. Явного отторжения не вызывает. Но, пожалуй, это только шаг. В правильном направлении, но всего-то маленький шаг, с которого должно начаться большое путешествие. Если на нем останвиться то вырождение в чемпиона-олимпиадника по скоростному программированию неизбежно. Это не так плохо, как кажется, но думается для большинства это и не вершина к которой стоит стремиться.

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

Думаю, что для начала надо аксиоматически принять простую истинну — потери неизбежны. Просто неизбежны. Токарь тоже теряет время на заточку инструмента. У нас мысль, прежде чем начать реализовываться, должна сформироваться. Желательно целиком и полностью. У нас есть свои методы, позволяющие сократить эти потери. То же программирование сверху вниз, то же ООП — это про это. Не надо сразу понимать весь проект — реализуй его послойно. Другое дело, что цена ошибки в каждом из слоев становится очень существенной. Потому безоговорочно доверять им тоже нельзя.

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

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

Я не согласна, с тем что полезное — это только писать уникальный код.


Ну то есть если вы — программист-кодер и работаете по чётко поставленному ТЗ, то да, это так.


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

Ну то есть если вы — программист-кодер и работаете по чётко поставленному ТЗ, то да, это так.

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

И проделывать еще кучу всяких «глюпостей» (с точки зрения менеджера), нужных только с одной целью — экспоненциально снизить объем кода, за счет избегания его дублирования. Причем не только кода одного и того же 2+2, но и дублирования частных случаев одной и той же абстракции — т.е. описания вычисления 2+2, 2+5, 7+10 и т.д. вместо написания один раз вычисления a+b.
а само написание кода вообще можно отдать джунам.
Это заблуждение сгубило уже очень много душ и хороших начинаний. Для отладки кода нужно понимать предметную область не хуже, чем тот кто осуществляет постановку задачи. При этом зачастую постановку необходимо корректировать на лету. Нельзя спроектировать все сразу до мельчайшего винтика без коррекций в процессе реализации — именно в этот момент вылазят нестыковки. А соответственно наиболее скоростной и качественный подход — разделение зон ответственности между компонентами при проектировании архитектуры, а детальную постановку на каждый отдельно взятый компонент делать непосредственно перед его реализацией.

При этом стоит помнить тот факт, что джун таки моложе, а значит заканчивал ликбез позже. А соответственно владеет более свежими и совершенными методиками анализа, и при этом они для него нативны, в отличии от сеньора, которому эти методики пришлось наращивать поверх старых, даже если он их и изобрел. Если джуну чего то и не хватает для успешного проделывания всех этих «глюпостей» — то только опыта и глубины понимания того, чему его учили в ликбезе (оно приходит годам к 40-ка). А соответственно объединяя более свежие знания толкового «желторотика» с опытом «стариков» на всех этапах, получим гораздо более эффективный как анализ так и реализацию.
Я не согласна, с тем что полезное — это только писать уникальный код.
А суть всех остальных занятий именно в том чтобы обеспечить именно это — писать и самое главное отлаживать только уникальный код.
Похоже нужен явный тэг «сарказм». Это же грустная шутка из оперы «уровень моей зарплаты зависит от количества строк кода».
Боюсь, мало какой менеджер изменит свои взгляды и подходы, прочитав эту статью. У него в башке забито — делай так.

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


То, что описано в статье — это максимум средненький мидл, точно не больше! При чем, любитель велосипедов.


P.S. Не понимая, почему лайков больше, чем дизлайков?

Что за чушь я сейчас прочитал? Вы головой ударились или что?

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

Если же задача требует понимания — скопировав код с гитхаба вы с большой вероятностью просто перенесёте утечку времени из одного места в другое(скорее всего вам придётся залезть внутрь и переписать всё чуть ли не с нуля, только с грудой костылей).
Но не воспринимайте это как призыв заново переписывать функции взятия БПФ.

Главная утечка времени — в плохом ТЗ.
Можно сколько угодно писать уникальный код который будет отправляться на помойку, ибо кто-то не может определиться в какую сторону мы сейчас воюем.

У меня один вопрос: вы для кого код пишете? Для компьютера или для коллег?

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

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

Пишите еще. У вас талант!
И статья, и комменты порадовали.
Поржал от души ;)

тайный поклонник
что такое уникальный код? по версии автота статьи.
и аналогично — что тогда неуникальный код?
Отличная идея. Я как то уже писал уникальный код. А еще давал уникальные имена классам и переменным, специально, не ленился и смотрел как английские так и немецкие синонимы, ну а чё, все равно латиница. Только вот коллеги подкачали, код ревью мне вечно заваливали. Нужно таки нести слово истины в широкие массы)
Есть кстати и другие метрики, например более успешный тот кто меньше работает и больше получает. При таком подходе если условные Вася и Петя получают одинаково, то более успешным окажется тот, кто меньше работает.
Возможны и иные варианты.
При таком подходе если условные Вася и Петя получают одинаково, то более успешным окажется тот, кто меньше работает.
Возможны и иные варианты.

Обычно один из них трудолюбив много-много работает, то бишь копипастит а потом пытается это как то заставить работать. В результате получает копейки на доширак. Ну каков результат.
А второй ужасно ленив и почти ничерта не делает, только во всю находит способы как переложить 99% своей работы на комп за счет остального 1% который он делает сам — а именно пишет уникальный универсальный код. И получает куда поболе. Ну тоже каков результат.
Согласен с автором.
Написание кода — это процесс создания полезности, и его уменьшать не стоит. А вот обдумывание важно, но его уменьшать (не во вред коду) надо.
Уникальность кода — означает, что его автор потрудился, чтобы он возник. То есть автор доказал свою полезность в написании полезного кода.
Как бы да, но…
Проблема, в том, что сейчас приходит время «больших батальонов».
Искусство одного программиста становиться все менее и менее значимым.
Из-за этого нужно организовывать команды и программисты становятся все более и более специализированными.
Я предлагаю такую формулировку, для программиста: ты занят полезным делом, если пишешь уникальный код


Вот уж где точно скрываются 97% от обозначенных 97% потерь
Интересная точка зрения. А давайте вам будут оплачивать только то время, когда вы пишете уникальный код? Если код не уникален, либо вы пошли полистать Хабр или попить кофе, то это время не считается рабочим. Как предложение?
Написание уникального кода это искусство, а компоновка не уникального — это ремесло.
За искусство платят обычно значительно больше (так как оно уникально).
Поэтому за уникальный код нужно ещё премию накидывать.
Эти парни любят абстракции даже больше, чем сами программисты.

Зачем тогда вы абстрагируетесь от самоорганизации процесса написания кода? В вашем мире существует некий сферический кодер в вакууме, который пишет уникальный код и не хочет организовывать свой процесс: оценивать свой тайминг, свою эффективность. Во времена расцвета студии Лебедева этого вполне хватало: заказчика не интересовали детали. Ему был важен результат. Сидишь, пишешь код, получаешь зарплату. Увы, сегодня такие орлы нам нафиг не нужны. Потому что результат стал измеряться не в проданных вагонах майонеза, а в полученных электронных транзакциях, в объёмах электронных покупок, в точности датчиков, отправляющих метрики через REST API и в скорости коммитов этих метрик в базу. Бизнес становится технологичным, и специально обученные писать уникальный код люди стали не нужны. Нужны программисты, способные построить свой рабочий процесс, дать оценку задаче и сопроводить её прогресс. Поэтому, после высера про то, что скрам и канбан — придумка менеджеров — статью можно не читать. Скрам и канбан — это инструменты разработчиков, и переворачиватели пингвинов, как и бухгалтеры, при виде нормального аджайл-процесса, начинают сходить с ума и орать, что они привыкли к своему грёбаному корпоративному порталу с задачами, висящими месяцами с одним и тем же статусом. А если ты будешь пытаться выжать из менеджерского звена максимум результата применением доски задач, они уже через пару часов побегут к руководству с жалобами на то, что им не нравится настоящее лицо матушки Эффективности. И во всей этой иерархии ваш сферический кодер находится ниже переворачивателя пингвинов. Со своим мнением об инструментах самоорганизации он находится где-то между пьяным сантехником и корпоративным говном, которое тот вычищает из корпоративного унитаза. Такой же бестолковый, и такой же не понимающий методов оценки производительности и сроков реального завершения процесса. Главное — писать код. Или месить говно в туалете. Суть одинаковая.

Не так давно прочитал тут на хабре интересные рассуждения на тему программистов, только с освещением другой стороны. Вот там чувствуется опыт в каждом слове. Тут же у меня возникает много вопросов, например, про бесполезную работу и уникальный код. Т.е. если я прибегаю к использованию паттернов проектирования то я уже пишу не уникальный код, и соответственно не выполняю полезную работу? Что такое вообще этот уникальный код? Где грань между уникальным и не уникальным кодом? Использование общепринятых названий переменных и функций для некоторых задач — это не уникальный код, и соответственно — бесполезно выполненная работа? Т.е. по вашему лучше выдумать уникальные названия и структуры данных, вместо использования понятных и широко распространённых?
Или вот, например, 15 лет назад я мог написать за неделю 10000 строк уникального кода, и решить некоторую сложную задачу. По вашей логике, я целую неделю занимался, относительно, полезной работой. Так вот, теперь я могу эту же задачу решить за пол дня, а то и меньше, написав на порядок меньше строк скомпонованного из не уникальных частей кода. Получается, что я пол дня занимался бесполезной работой? Что вообще такое по вашему работа?

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

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

Черт, вы раскусили мою шизофрению.
или намертво зажат в массажном кресле

Сама возможность в кресле полежать может быть доводом для программиста работать именно в этой компании, при прочих равных.
Сама возможность в кресле полежать может быть доводом для программиста работать именно в этой компании, при прочих равных.
Цена массажного кресла в пределах 5 килобаксов, при это от начинается с 600-800. Так что таки з/п которая позволяет его прикупить и лежать в нем когда угодно, будет более важным фактором чем возможность в нем полежать в офисе после работы, привязывающая его к конкретной конторе аки крепостного.
Уже неделю пытаюсь запустить проект. Который мне достался от такого «оптимизатора», который, только писал полезный код и не отвлекался на такие мелочи(!) как документация, рефакторинг и описание тикетов.
И вот теперь есть код который как-то можно запустить и он что-то делает, но что и как — не знает никто.
Зато тот парень молодец — у него потерь по времени было мало, а уникального кода — хоть отбавляй.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.