Как найти правильный баланс между "быстрым и грязным" и "красивым и общим" кодом?
Это не прямой вопрос программирования, но была бы признательна небольшая помощь со стороны сообщества программистов.
Я страдаю от чрезмерной болезни. Я не могу перестать тратить драгоценное время, делая мой код наиболее общим и абстрактным. Я мог бы также назвать это болезнью набора инструментов / библиотеки. Я склонен превращать каждую задачу программирования в общую проблему и пытаться "написать инструментарий", который бы работал для многих подобных проблем.
Я знаю, что в целом это хорошо, если есть достаточно времени, но иногда я должен писать быстрый прототип и просто не могу написать быстрый и грязный код, который просто работает для особого случая. Меня часто волнует идея, которая делает код более общим и настраиваемым пользователем и недооценивает время, необходимое для его реализации.
У кого-нибудь еще есть такой опыт? Как я могу заставить себя найти правильный баланс между "быстрым взломом" и "хорошим решением"?
7 ответов
Разработка, основанная на тестировании (также известная как TDD), может быть полезным противовесом чрезмерному толчку общности - она прививает практику, где, цитируя только что указанную статью в Википедии,
Важно, чтобы написанный код был разработан только для прохождения теста; никакие дальнейшие (и, следовательно, непроверенные) функциональные возможности не должны быть предсказаны и "допущены" на любой стадии.
Как только вы будете практиковать это строго некоторое время (лучше всего, если это возможно, в парном программировании, где партнеры усиливают мотивацию друг друга следовать этим практикам!), Вы можете выйти за пределы этого.
Это обычный цикл обучения: шу, "удерживать", когда вы практикуете одну технику, пока не освоите ее; ха, "отделяйся", где вы сочетаете техники друг с другом; и, наконец, "трансцендировать", когда вы выходите за рамки такого явного обучения, освоив и усвоив все это - оно работает так же хорошо для программирования, как и для театра "Нет", для которого оно изначально задумывалось (большинство людей в Запад, знакомый с концепцией шу-ха-ри, вероятно, встречал ее в контексте боевых искусств, но исторически это уже было огромным продолжением оригинала;-).
Я тоже склонен это делать. Но когда я снова и снова использую мой "обобщенный" код, я обычно обнаруживаю, что это не совсем то, что мне нужно в новой ситуации.
В эти дни я пытаюсь подождать, пока я что-то не реализовал пару раз, прежде чем думать о том, как это следует обобщить. Таким образом, у меня есть лучшее представление о реальных случаях использования, которые я должен охватить.
Этот вопрос также напоминает мне цитату из Чарльза Мура в этом сообщении в блоге. Каждый раз, когда вы переопределяете что-то, вы узнаете об этом больше и улучшаете свою реализацию. Вам, вероятно, следует изобретать колесо несколько раз, прежде чем помещать свою реализацию в библиотеку.
Соблюдайте ваши сроки. И если у вас нет сроков, создайте свои собственные.
Программисты не работают в вакууме, они большую часть времени служат бизнесу.
Сначала я обычно получаю решение для быстрой доставки, тогда, когда у меня есть время, я начинаю процесс его очистки (стараясь не нарушать функциональность. Последней хорошей версией в срок является версия для доставки.
Поверьте мне, первая пара ботинок в задней части или другие плохие оценки производительности расскажут вам о важности этого:-)
Пишите быстро и грязно и проверяйте, работает ли он, рефакторинг до тех пор, пока вам не стыдно за код.
Рабочий код лучше, чем хорошо разработанный, но не рабочий код. Даже самая грубая реализация намного лучше, чем то, что не работает или даже не закончено.
Из прототипа / быстрой и грязной реализации проще сделать рефакторинг и структурные улучшения, поскольку есть рабочая ссылка для тестирования.
Как написали другие, TDD очень полезен, так как без надлежащих тестов это очень сложно, поэтому преуспеть в любом проекте рефакторинга.
Но, наконец, очень важно разделить обобщение в проблемной области, в которой работает ваша программа, и обобщение во всей области вычислений.
Очень часто проекты заканчивают изобретением решений для структур данных, алгоритмов, сетевых протоколов и т. Д. Вместо использования существующих реализаций / библиотек.
Я видел множество примеров, когда программисты реализуют свои собственные хеш-карты, реализации http и т. Д. Вместо использования существующих. Иногда, возможно, отсутствовала совместимость между библиотекой и приложением, но тогда шаблон фасада можно было использовать для инкапсуляции использования внешней библиотеки.
Я думаю, что это проблема, с которой сталкиваются многие программисты. Вот почему нам нужны менеджеры проектов, которые понимают бизнес. К сожалению, мы работаем в среде, которая не является чисто академической. Поэтому работа, которую мы выполняем, полезна только в том случае, если она своевременно удовлетворяет бизнес-требованиям.
Вы должны найти правильный баланс между выполнением "правильного" кода и фактическим предоставлением работающего программного обеспечения.
Лучший ответ, который я всегда нашел, это как долго должен длиться код? Вам не обязательно писать весь фреймворк, просто убедитесь, что его можно поддерживать.