Как мы можем заставить кодеров искать существующие функции перед написанием их собственных?

Question

Почему так много людей до сих пор пишут дерьмовые версии вещей в стандартных библиотеках? Не нужно идти за разработчиками PHP, но парни читают PHP SPL

Answer 1

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

Answer 2

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

Итак, мой совет: в следующий раз, когда вы наймете программиста, выберите старика, который засыпает в приемной.

Шучу, в основном. Рецензия и образование - это ответ.

Answer 3

Резюме: Предположение является матерью всех FUBAR

Я часто вижу это от коллег, которые не знакомы с концепцией фреймворков (боже, как они жалуются на «два языка в одном»), а именно: старые парни из C ++ внезапно сталкиваются с C #, ныряющим в голову, чтобы воссоздать хеш-таблицы царапина ...

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

Недостаток знакомства с вашими инструментами порождает презрение к другим.

Answer 4

Улучшенные методы поиска. и Знакомство с доменом

Как разработчик проверяет функцию, имя которой он не знает? Или, возможно, нет встроенной функции EXACT, которая делает то, что они хотят, но что-то, что они могут использовать, чтобы сохранить много кода. Вы должны быть в состоянии найти правильную терминологию для проблемы, и оттуда вы знаете, что искать. Этого лучше всего достичь, читая темы, относящиеся к вашей проблемной области. Избавьтесь от кодирования конкретных ресурсов и проведите какое-то время в той области, для которой вы кодируете ... будь то розничная торговля, медицина, страхование и т. Д.

Answer 5

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

Если люди этого не делают, возможно, было бы неплохо попросить кого-нибудь задать им вопросы об их общем подходе к проблеме и о том, какие библиотечные функции / классы они планируют использовать. Если они упускают что-то очевидное, предложите им это.

Answer 6

PHP хорошо документирован тогда и только тогда, когда вы точно знаете, что ищете. Например, вы бы открыли Массивы и Функции массивов разделы, чтобы увидеть, что можно делать с массивами. И угадайте, что там даже не упоминается SPL.

Answer 7

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

Иногда нужно просто напомнить людям.

Рецензия поможет.

Answer 8

На ум быстро приходят две причины. Во-первых, стандартная библиотека PHP неизвестна и страдает от плохой документации. Веб-сайт php.net широко считается лучшим активом языка, но многие новые встроенные классы (такие как SPL, API отражения, DomDocument и т. Д.) Представляют собой не более чем список методов без большого контекста.

Что еще более важно, похоже, что полный SPL никогда не поставляется по умолчанию с какой-либо версией PHP до (не выпущенной) 5.3. Это убийца, насколько усыновление идет. Обычно люди, пишущие код PHP, не имеют контроля над тем, что попадает в их двоичный файл PHP. Этим занимается их веб-хост и / или операционная команда, и веб-хосты и / или операционные команды имеют другие цели, чем разработчик, и не собираются устанавливать каждое дополнительное расширение, которое приходит вместе. Это также означает, что проекты, такие как Drupal, Joomla, Wordpress и т. Д., Не могут полагаться на SPL, установленный везде, поэтому они не используют его.

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

Answer 9

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

Если это так, кто-то из команды должен просмотреть спецификации и указать, где можно использовать существующий код ...

Answer 10

Согласитесь с обучением и экспертной оценкой, но также принудительное применение модульного тестирования и документации кода должно помочь при синдроме NIH :)