Как вы выбираете из множества решений то, которое в итоге реализуете?
Добрый день!
Передо мной часто встает проблема: я знаю, что какой-то метод можно реализовать несколькими способами, но я не могу оценить, какой из них лучше. По каким критериям оцениваете вы?
Бывает, что какой-то из способов я пытаюсь реализовать, но у меня не выходит, т.к. я начинаю путаться в собственном коде. Понимаю, что дело в практике, но обычно, немного помучившись, я выбираю другой способ, так и не добив первую реализацию. Это нормальная практика?
Второй/Третий способ обычно более читабельный, но я начинаю задумываться о его эффективности. Возможно, стоило добить первую идею, она была лучше и т.д...
Посоветуйте, пожалуйста, какие-то способы оценки себя; возможно, какую-то литературу. Как мне научиться понимать, где плохое, а где хорошее решение; где плохая, а где хорошая реализация...
Именно для борьбы такого плана и придумываются методологии типа TDD, BDD
Придуманы интерфейсы и принципы ООП
Придуманы паттерны (в частности: адаптер, декоратор и прокси)
Кратко -- придумываете интерфейс, придумываете клиентский код
а далее реализуете различный код, но каждый раз он наружу торчит на языке вашего бизнеса
правильное решение (если оно есть))) это то которое вы легко поймете прочитав исходники которые вы написали полгода назад. )
Для этого нужна что-то типа стандартизации. Т.е. вы применяете стандартное разбиение на слои свою программу. Стандартно разбиваете на модули. Стандартно разбиваете на классы. Из этого видно плюсы паттернов - они привычны и легко узнаваемые. (один из плюсов)
Есть разные способы написания стратегии написания кода. написать все и переписать заново. написать и изменять. (на самом деле деление немного оторвано от жизни)
Для собственного увеличения скилов, думаю лучше , при имении время, писать рабочую версию, а затем изменять текст в сторону красоты.
Любой способ должен быть читабельным. Почитайте Макконела Совершенный Код например.
По каким критериям оцениваете вы?
Если задача не учебная, значит решается не в вакууме и можно определить какие критерии более важны, скорость получения решения, скорость работы, минимизация занимаемой памяти и.т.д. При прочих равных выбирается наиболее простое в реализации решение. Чем больше опыт, тем проще будет определять критерии.
Понимаю, что дело в практике, но обычно, немного помучившись, я выбираю другой способ, так и не добив первую реализацию.
Стоит знать лучшие реализации типовых задач. Хоть они как правило и берутся из библиотек, но если вдруг библиотеки нет, то всё равно вы уже знаете что делать. Не типовые задачи разбивайте на типовые. Для совсем-совсем не типовых задач получите работающее решение, назовите его прототипом и исследуйте на соответствие предъявляемым критериям.
Это вряд ли возможно формализовать. Один из подходов: KISS — keep it simple. Выбираю самое простое решение, потому что, пока оно дойдет до production, требования 10 раз поменяются (и еще 10 раз поменяются уже после внедрения), а простое решение и проще реализовать и проще переделать. Но это только одна из эвристик.
Такое, чтобы запутаться в решении не бывает. Это только, если не понимать, что делаешь. Иногда бывает, что не совсем до конца понимаешь требования, или как решать задачу. Тогда можно зайти в тупик спустя несколько часов или дней. Но такие ситуации встречаются редко.
Иногда по мере того, как делаешь задачу, понимаешь, что ее можно сделать совсем иначе, при этом получится проще и эффективнее. Ничего страшного нет: с самого начала продумать идеальное решение не может никто.
В жизни нет готовых рецептов на все случаи. Жизнь вообще не поддается формализации.
Возможно, я не совсем понимаю, какой критерий должен быть основным? Я могу писать понятный, красивый, читабельный код – не сразу, но после раздумий. При этом меня каждый раз волнует вопрос: а насколько он быстро будет вычисляться??
Поэтому я не могу понять, на чем мне делать акцент. На понятности кода, его простоте?
Но ведь простота для меня, как для человека, не означает простоты для компьютера?
Не понимаю...
Ксения, на простоте реализации. Формализовать немного сложно, но допустим так. Есть задача, вернуть список файлов в текущем каталоге, которые начинаются на "a".
Шаг 1.:
def files_a():
return ['a_file.txt']
Шаг 2:
import os
def files_a():
return os.listdir('.')
Шаг 3:
def files_a():
return [f for f in os.listdir('.') if f.startswith('a')]
То есть начинать с самого простого и примитивного решения, которое самыми простыми шагами доводить до работающего.
Думать о том, сколько код будет вычисляться не нужно почти никогда. Во-первых, большинство кода, который пишется, не доходит до production, то есть, никогда не будет выполняться. Во-вторых, может оказаться, что он будет выполняться очень редко, и даже если долгий, то это ни на что не повлияет.
Оптимизировать надо только тогда, когда возникли ощутимые проблемы с производительностью, потому что они часто оказываются совсем не там, где мы думаем, они появятся.
Со временем появится интуитивное понимание, где в будущем могут возникнуть проблемы, и как лучше написать, чтобы их по возможности избежать.
Без опыта, только по книгам и советам, научиться этому почти невозможно. У меня не получилось, во всяком случае. Любая книжная теория очень быстро разбивается о практику. Это не значит, что теория бесполезна, скорее, что теория дает плоды только вместе с практикой.
Нельзя прочитать 100 книг и начать писать идеальный код. Можно прочитать 100 книг, поучаствовать в 100 проектах, многие из которых провалятся, в которых будет куча плохого кода. И после этого начать писать нормальный код...
Оптимизировать надо только тогда, когда возникли ощутимые проблемы с производительностью, потому что они часто оказываются совсем не там, где мы думаем, они появятся.
Именно вот это меня и интересовало! Спасибо :)
Со временем появится интуитивное понимание, где в будущем могут возникнуть проблемы, и как лучше написать, чтобы их по возможности избежать.
Без опыта, только по книгам и советам, научиться этому почти невозможно. У меня не получилось, во всяком случае.
Только сейчас смогла почувствовать, какого масштаба опыт должен быть, чтобы не терзаться такими вопросами :)
Только сейчас смогла почувствовать, какого масштаба опыт должен быть, чтобы не терзаться такими вопросами :)
Да нет, опыт быстро накапливается. После первого проекта будет уже понятнее, после второго еще яснее. А вообще, у всех по-разному. Кто-то быстрее учится, кто-то медленнее. Кому-то скучно над одним и тем же проектом работать, а кто-то может оттачивать на такому навыки десятилетиями.
При работе с другими людьми еще наблюдаешь за ними, перенимаешь опыт.
Saboteur
@saboteur_kiev Куратор тега Организация работы
software engineer
На самом деле вам только кажется, что несколько вариантов равноправны. С опытом приходит понимание, чем каждый вариант лучше/хуже и вы применяете его в конкретной ситуации уже исходя из опыта.
А реализовывать нужно в первую очередь работающий вариант. Если есть время и желание, оптимизировать можно всегда и потом - оптимизировать заранее не нужно.
А реализовывать нужно в первую очередь работающий вариант. Если есть время и желание, оптимизировать можно всегда и потом - оптимизировать заранее не нужно.
На начальном этапе - не париться об этом. Все равно идеально не сделаете. Крутите велосипед - с опытом его улучшите и поймёте что правильно.
Вариант есть - спросить о реализациях старшего разраба. Если таковой есть. Описать ему все варианты реализации и он объяснит где у какого минусы-плюсы.
Просто пишите, читайте, вникайте. Со временем всё придёт.
В первую очередь выбирается то решение, которое "было в прошлый раз". Потому что оно уже собственноручно проверенное, и не даром же оно уже было выбрано по каким-то параметрам.
Если оно почему-то не подходит (древний/глючный/тормозной говнокод, на который стыдно смотреть, например), то ищется либо более производительное, либо универсальное/гибкое, либо какая-то новинка для попробовать. Не обязательно в таком порядке, зависит от проекта.
Сложный
