О решении старых проблем

Рубрика: Development | 7 August 2008, 08:27 | Vadim Voituk

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

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

К счатью (а может быть и к несчастью) замечаю, что “заморачиваюсь” не один я – это довольно распостраненное явление среди моих знакомых.

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

С одной стороны вроде бы это и похвально, – основываясь на собственном опыте делать все сразу и хорошо. Но с другой стороны подобные “надуманные” (или правильнее “ненужные”?) решения отбирают какие-никакое время и тормозят развитие проекта.

Вот и думай что лучше: “плохо-шатко, но сейчас” или “хорошо и стабильно но стулья вечером потом”.

Какие у вас мысли по этому поводу?

Комментариев: 30

30 Responses to “О решении старых проблем”

Комментарии:

  1. wheleph

    Если рассматривать качество кода, то конечно же лучше “хорошо и стабильно но потом”. А если говорить о производительности, дополнительных функциях и масштабируемости, то лучше решение таких задач откладывать до того момента, когда они возникнут.

  2. Vadim Voituk

    то лучше решение таких задач откладывать до того момента, когда они возникнут

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

    Хотя я тоже больше склоняюсь к варианту оптимизировать по мере надобности, и не тратить изначально на это время (конечно же в пределах разумного).

  3. AntonLyapunov

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

    Приходится останавливать себя, и делать что-либо быстрее и продуктивнее.

  4. Андрей

    “Эффект второй системы”
    Вместе с последствиями очень хорошо описан у Брукса, в “Мифическом человеко-месяце”.

  5. Vadim Voituk

    AntonLyapunov,
    +1, аналогично на все 100%

    Андрей,
    Хм… Надо будет МЧМ перечитать заново (хоть убей не помню ничего подобного). Спасибо за наводку.

  6. ilya

    Думаю что есть достаточно типичные ошибки при построении приложений. Они повторяются у всех и все про них пишут. Вот их стоит учитывать.

    Вообще опытный программист думаю вполне сможет оценить риски. И потенциально узкие места заранее. А также приоритеты по их устранению.

    Моя позиция это «быстрее». То что касается высоких нагрузок вообще не проблема ИМХО. Кеширование наш лучший друг. Так что если где-то большая нагрузка — в кеш, а потом устранять ее.

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

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

  7. kVn

    2ilya: то, что ты говоришь правильно, но это не связанные между собой вещи. :)

  8. Yaroslav Vorozhko

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

  9. COTOHA

    делать надо “just good enough” и не больше. вопросы оптимизации в начале вообще не должны затрагиваться, ну кроме явных ляпов. потому что оптимизировать надо бутылочное горлышко, а не всё подряд, а где это горлышко становится понятно только в конце.

    вот где-то так.

  10. Yaroslav Vorozhko

    2 СОТОНА: Оптимизировать надо не только код, но и организацию кода…
    Ты можешь сразу написать 10.000 строк кода в одном файле разбитым на процедуры, а потом начать оптимизировать, то если ты даже все напишеш за неделю, то тебе потребуется не менее месяца, чтоб в нем разобраться.
    Оптимизация процесса и организации структуры кода, одна из главных задач при проектировании.

    А если ты вдобавок работаешь над кодом не один, а в команде, то непродуманная структура будет проблемой для всей команды.

  11. corsair

    Перше правило оптимізації – не оптимізувати
    Як правило часто затики виникають не там де оптимізуєш, так що навіщо тратити час?

  12. Yaroslav Vorozhko

    corsair, можно ссылка на источник, где такое правило прописано?

  13. Vadim Voituk

    С чего это все вдруг на оптимизацию накинулись? – я её только для примера привел.
    Аналогичное можно сказать и про другую задачу, в которой кто-то уже “поднаторел” и в следующем проекте “вылизывает её по самое не могу”.

    А вообще я вижу, что все склоняются к варианту “плохо – но сейчас, а дальше переделаем”.
    В лучших традициях agile-методологий – делать только то, что понадобится.

    что касается высоких нагрузок вообще не проблема ИМХО

    Судя по всему понятия “высокая нагрузка” у нас кардинально разнятся :)
    Если бы все было так просто: “большая нагрузка — в кеш” – то никто бы сейчас не заморачивался с кластерами App и DB серверов, memcached-ами и тд и тп.

  14. COTOHA

    2 Yaroslav Vorozhko

    “corsair, можно ссылка на источник, где такое правило прописано?”

    Refactoring by Martin Fowler

  15. corsair

    Замовник хоче бачити результат і розказні про те, як ти красиво повилизував класи, його не тішать. Він більше любить коли щось можна помацати.

    Тому краще гірше, але зараз.

    P.S. коли пишеш вдома для себе – можливі варіанти %)

  16. COTOHA

    2 Vadim Voituk
    А вообще я вижу, что все склоняются к варианту “плохо – но сейчас, а дальше переделаем”.
    не “плохо”, а “достаточно хорошо”. есть большая разница…

  17. Yaroslav Vorozhko

    2 СОТОНА, по моему рефакторинг сам по себе является оптимизацией кода. Код становиться проще и понятнее, а значит и проще с ним работать. Я думаю Фаулер хотел сказать другое, что оптимизация нужна, но только до того момента пока она не будет удовлетворять пользователя.
    А “не оптимизировать” делать первым правилом уж очень строго, и не путаете ли вы Фаулера с кнутом?
    «Преждевременная оптимизация — корень всех зол» © Кнут

  18. COTOHA

    эээ. пошла философия :) но я тоже могу:

    “рефакторинг” как техника направлена на улучшение кода и архитектуры вцелом

    “оптимизация” направлена на решение конкретной задачи – улучшение быстродействия, поисковая оптимизация и т.д.

    то, что можно померять, то можно оптимизировать, а “читабельность кода”, “расширяемость кода” не меряется. соответственно его нельзя оптимизировать.

  19. COTOHA

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

    нет. он говорит, что она нужна только, когда видна вся картина и выявлено бутылочное горлышко. и, естественно, только на бутылочном горлышке – оптимизировать всё остальное – непродуктивно и неэффективно.

  20. Yaroslav Vorozhko

    Попробуй измерить производительность, количество строк кода, количество объектов, классов и т.д. до “рефакторинга” и после.
    Все можно измерить, даже “читабельность” и расширяемость кода.
    Например для “читабельности” измерить глубину вложенности кода, чем вложенность выше, тем хуже читабельность, измерить количество глобальных переменных, количество goto и т.п., чем такого рода вещей больше тем хуже читаемость.
    Расширяемость аналогично.

  21. Yaroslav Vorozhko

    “нет. он говорит, что она нужна только, когда видна вся картина и выявлено бутылочное горлышко. и, естественно, только на бутылочном горлышке – оптимизировать всё остальное – непродуктивно и неэффективно.”
    На любой тезис, можно найти антитезис. Думаю не стоит искать цитаты и доказательства слов Фаулера, ведь без проблем можно доказать и обратное.

  22. corsair

    А можна я теж скажу, що на мою думку означає фраза Фаулера?
    Він мав на увазі, не задумуватися про оптимізацію коли пишеш чи обдумуєш задачу. Так як це може вплинути на архітектуру, і до того ж не факт що воно в кінечному результаті буде в тому місці тупити. Тому краще присвятити час саме на вирішення задачі і написанню “якісного” коду.

  23. Yaroslav Vorozhko

    С идеей оптимизировать код после его написания я полностью согласен.

  24. COTOHA

    2 Yaroslav Vorozhko

    На любой тезис, можно найти антитезис. Думаю не стоит искать цитаты и доказательства слов Фаулера, ведь без проблем можно доказать и обратное.

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

    речь не идёт о том, прав он или нет – речь идёт о том, так он считает или нет.

    что касается момента “правды”, то я разделяю точку зрения Фаулера и своим программистам бью по рукам за попытки бесцельной оптимизации во время реализации функциональности. (а в то время оптимизация _всегда_ бесцельная)

  25. Иван Блинков

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

  26. Vadim Voituk

    Иван,
    Не соглашусь. Как раз суть в том, чтоб без надобности не углубляться в собственный опыт (что собственно перечит человеческой психологии, ибо каждый любит заниматься тем, в чем он лучший).
    IMHO правильным решением проблемы будет научиться убеждать себя в том, что “сейчас сделаем поверхностно, а потом уже доведем до уровня, какой был прошлом проекте. Тем более я на этом уже собаку съел.”

  27. COTOHA

    в такой остановке вопроса (как научиться так делать?) думаю ответом будет: научиться считать деньги. :)

  28. Иван Блинков

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

  29. Dancer

    ну.. кто сказал, что это хорошо?

  30. kVn

    мне это напомнило:
    совокупность идей и представлений, умозаключение, возникшее не в результате обработки поступивших сведений и не корректируемое поступающими сведениями

    See also: http://ru.wikipedia.org/wiki/%D0%91%D1%80%D0%B5%D0%B4

Leave a Reply