«Не изобретать колесо» игнорирует пределы человеческой памяти?

В Haskell и F # меня научила одна вещь: кто-то в университете умнее меня, вероятно, уже нашел абстракцию для того, что я делаю. Аналогично в C # и объектно-ориентированном программировании, вероятно, есть библиотека для «этого», что бы я ни делал.

Особое внимание уделяется повторному использованию абстракций в программировании, и я часто испытываю дилемму между: 1) простым написанием чего-то короткого и грязного или 2) тратя то же самое время на поиск более надежной библиотеки / решения другого пользователя и просто используя его.

Как недавно один из программистов здесь написал (de) сериализатор для файлов CSV, и я не мог не подумать, что что-то подобное, вероятно, очень легко найти в Интернете, если оно еще не поставляется со стандартом .NET API.

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

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

Во-первых, вам нужно научиться определять «компоненты», которые являются достаточно общими / многократно используемыми, чтобы, скорее всего, уже существовала библиотека или стороннее решение. Как только вы это сделаете, поймите, что, даже если вы хороший разработчик, коллективный опыт бесчисленных разработчиков, тратящих бесчисленные часы на одну и ту же проблему, скорее всего, даст решение лучше, чем вы когда-либо сможете сделать. Это не значит, что вы никогда не должны «изобретать велосипед», но если вы решите это сделать, вам лучше иметь ЧЕРТОВОЕ оправдание для этого.

Особое внимание уделяется повторному использованию абстракций в программировании, и я часто испытываю дилемму между: 1) простым написанием чего-то короткого и грязного или 2) тратя то же самое время на поиск более надежной библиотеки / решения другого пользователя и просто используя его.

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

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

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

Добро пожаловать в мир программирования. Эта проблема будет предметом многих разногласий между вами и вашими будущими коллегами. У вас есть два варианта:

1. Катайся сам.
2. Создайте что-нибудь поверх чьего-либо решения.

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

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

Это (или подобное) часто случалось со мной на предыдущей работе, где фреймворк страдал от серьезного эффекта внутренней платформы.

По сути, их кодовая база развивалась с ранних времен Windows C / C ++, затем начала компилироваться в MFC - и поэтому сопровождающие начали смешивать MFC и их старые внутренние структуры данных и оконные компоненты. Внутренняя платформа не очень хорошо документирована, но якобы это был «Путь» для работы с этим продуктом из-за некоторых внутренних возможностей, которые он предоставил. Мне часто было проще и быстрее писать свои собственные вещи с нуля (из основ MFC), а не пытаться понять, как это сделать с помощью внутренней структуры компании.

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