Почему иногда нужно изобретать колесо? Перевод

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

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

Что произошло, когда колесо перестали изобретать заново?

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

• слишком сложный код. Скорее всего, никто не сделал решение ТОЧНО для ваших нужд, поэтому в конечном итоге вы используете что-то излишне сложное, что снижает производительность, а также делает код трудным для понимания. В мире Java или PHP (другие языки, в которых я разбираюсь) вы столкнетесь с изобилием фреймворков, направленных на то, чтобы сделать вышеупомянутое ведро достаточно огромным, чтобы вместить «все», что когда-либо понадобится кодеру.

• хаос, созданный программистами, у которых не было возможности потренировать свой ум. Очевидно, что годы или даже десятилетия опыта работы в качестве заводского робота не повышают ваш интеллект и навыки решения проблем. Вещи, которые вы пишете, всегда будут отражать отсутствие фундаментальной логики: никакой заботы о производительности, простоте, элегантности или даже здравом смысле. Как правило, здесь мы находим классы, делающие ВСЕ, технологии, используемые, потому что разработчик не мог написать две строки правильного кода, оргии макросов (на C/C++) и зловещий беспорядочный взгляд сверху донизу.

• «стандарты». Заводская работа не была бы полной без стандартов. Рабочий должен подчиняться стандартам как своей второй натуре! Как правило, сами стандарты стали стандартизированными, поэтому компании создали инструменты, которые проверяют, соответствует ли ваш код стандартам (будь то тестовое покрытие, качество кода, шаблоны проектирования или что-то еще). Конечный результат производит впечатление улучшения качества, но реальный жизненный опыт подсказывает вам, что они в значительной степени бесполезны. Наем нескольких компетентных разработчиков всегда является лучшим долгосрочным решением (с точки зрения качества и производительности), чем навязывание стандартов нестандартным работникам.

• увеличение числа лиц, которые не должны быть программистами. Поскольку программирование — это хорошо оплачиваемая работа, в последнее время она привлекает армию людей, интеллектуально непригодных для этой работы, неспособных работать лучше, ДАЖЕ ЕСЛИ они обучены «стандартам» или думают самостоятельно.

Это мышление, которое способствует конформизму, несет ответственность за огромное снижение качества программирования, и его можно устранить только с помощью его возмездия: творчества или «изобретения велосипеда».

Когда мы должны изобретать велосипед?

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

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

Источник: https://www.data-types.com/blog/reinventing-the-wheel