Pull to refresh
  • by relevance
  • by date
  • by rating

Про использование чужого кода. Плагин «пейджер» для smarty.

Lumber room
Недавно в очередной раз под звук участливых замечаний «не изобретай велосипед» нарвался на глюки чужого кода. В данном случае это был полуофициальный плагин «пейджер» для smarty, который работал жутко криво (я даже не стал разбираться почему, т.к. всё равно бестолку). В прошлый раз я написал свой класс для конвертации JSON <-> Object, который действительно правильно преобразовывал все типы, не херил UTF-8 и правильно сообщал если что не так, а не тупо возвращал пустоту. В позапрошлый — два часа попыток заставить drag'n'drop из mootools делать то что надо мне, привели к написанию за 40 минут собственного drag'n'drop для JS.

В этот раз всё закончилось аналогично — был написан свой «пейджер», который субъективно получился куда короче, понятнее, юзабельнее. Вызов моего плагина требует намного меньше лишних параметров, помещается в одну строку, дружественен к семантическому коду с раскрашиванием через CSS. Фишечек в нём тоже поменьше (а они нужны?).

Вот он, если кому интересно.

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

Выводы: Свой код, особенно если он приспособлен для повторного использования всегда лучше чем такой-же, но взятый со стороны. Если кто-то ещё скажет мне «не изобретай велосипед» — снисходительно посмотрю на него сверху вниз. А то любят тут умничать, блин…
Total votes 17: ↑11 and ↓6 +5
Views 292
Comments 19

Как разобраться в «иностранном» коде и влиться в новую команду?

Skillbox corporate blog Programming *Development Management *Studying in IT
Translation


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

Любой код имеет собственную логику, основан на определенных принципах, в нем встречаются паттерны и технологии, характерные для команды, к которой присоединился программист. Но как начать быстро понимать чужой проект, при том что он вряд ли небольшой, а документации часто либо вообще нет, либо она недостаточна и неточна?
Читать дальше →
Total votes 32: ↑29 and ↓3 +26
Views 10K
Comments 1

Не судите чужой код строго

Abnormal programming *IT Standards *
Так сложилось что большую часть своей сознательной жизни я программирую на PHP. Наш мозг, воспринимая информацию из любого источника, делает это без отрыва от авторитетности этого источника. Грубо говоря, если вы любите PHP — вы автоматически добавили очков авторитетности автору этой статьи, а если не любите — автоматически отняли. Этот процесс происходит на бессознательном уровне и является по сути призмой восприятия, которая с одной стороны защищает нас от падения в бесконечный анализ информации любой степени авторитетности, но с другой стороны ограничивает нас в поиске новой более актуальной информации. Самое поганое здесь то, что авторитетность источника редко когда проверяется на сознательном уровне (потому что на это нужны время и ресурсы в виде драгоценных калорий), я могу быть с той же долей вероятности разработчиком плюсов, домохозяйкой-кухаркой, водопроводчиком без принцессы или генетически модифицированным котом. Не судите мою статью строго, у меня лапки.

То же самое относится к чтению чужого кода: если его автор сидит по левую руку от вашего трона, работает в вашей фирме 10+ лет и зарабатывает на один ноль больше вас, это совершенно не то же самое, что автор, которого уволили за что-то плохое, а вас наняли на его место. Но по сути то и там и там код — это всего лишь набор байтов, которые было бы полезно оценивать без привязки к авторитетности источника.
Читать дальше →
Total votes 46: ↑33 and ↓13 +20
Views 9.9K
Comments 44

Почему полезно изобретать колёса

Productivity Inside corporate blog Programming *Studying in IT
Translation


На днях я проводил собеседование с разработчиком на JavaScript, который претендовал на позицию сениора. Коллега, тоже присутствовавший на собеседовании, попросил кандидата написать функцию, которая бы производила HTTP запрос и в случае неудачи повторяла попытку несколько раз.

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

Но увы. Да, было очевидно, что подобный код встречался ему раньше. Он в общих чертах знал, как там все работает. Нам хватило бы наброска решения, который демонстрировал бы понимание концепта. Однако код, который кандидат писал на доске, был полной бессмыслицей. У него сложилось крайне туманное представление о том, что такое промисы в JavaScript и он не мог толком объяснить, зачем они нужны. Для джуниора это было бы еще простительно, но на позицию сениора уже не тянуло. Как бы этот разработчик сумел устранить баги в сложной цепочке с промисами и объяснить остальным, что именно он сделал?
Читать дальше →
Total votes 22: ↑20 and ↓2 +18
Views 7.5K
Comments 15

Sourcetrail: инструмент, чтобы разобраться в чужом коде и не выстрелить себе в голову

RUVDS.com corporate blog Programming *Industrial Programming *Lifehacks for geeks


I regret to report that I've just recently looked again at my programs for prime factors and tic-tac-toe, and they are entirely free of any sort of comments or documentation.
— Donald E. Knuth

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

Такое случается даже со своими программами и скриптами, написанными на write-only ЯП.

Разработчики, имеющие дар работать с таким кодом высоко ценятся в коллективе.

Такое чудо-лабиринты из кода бывают, когда исходный код имеет:

  • Непоследовательный стиль разработки
  • Чересчур сложную и запутанную структуру программы
  • Очевидные логические ошибки или упущения
  • Запущенность

Надо понимать, что существует большое отличие между живым рабочим кодом и неким учебно образовательным. В первом случае на процесс разработки может влиять целый ряд технических, коммерческих и даже бытовых причин. Под их воздействием даже самый строгий и элегантный дизайн ПО может превратиться в спагетти. Основные причины таких метаморфозов знакомы многим программистам.
Читать дальше →
Total votes 49: ↑48 and ↓1 +47
Views 9.6K
Comments 7