Стандарты оформления кода
Март 3, 2010 Программирование
Пару суток назад пришел интересный заказ на доработку скрипта. В данный момент пребываю в глубоком желании дать по рукам человеку, который это писал до меня.
Я не сторонник тотального документирования, но глубоко убежден что использовать односимвольные имена переменных в ключевых участках кода это свинство.
Я не сторонник описывать все и вся, но ставить хотя бы блочные комментарии для систем сложнее одной функции просто необходимо.
Мне ложить на лицензии, но в больших проектах я считаю просто необходимым указывать свои координаты и как со мной связаться, если уж впадлу описать общую логику приложения.
Использование n-мерных представлений для двухмерных данных это моветон. Я убежден в этом.
31 запрос к БД для формирования одной страницы двухмерного отчета это вещь за которую нужно расстреливать.
Наличие в БД избыточных полей и присутствие в таблицах-хранилищах дублирующих текстовых ключей это извращение, это заслуживает строжайшего порицания.
На сегодняшний день, на мой простите профессиональный взгляд на первое место в разработке выходит понятность и лаконичность кода, внимание к структуре БД (неужели трудно нагуглить что такое НФ) и простота дальнейшей поддержки и модернизации.
В 2010 году всем нужно просто обязательно выучить что такое процедуры, а для особо продвинутых стоит озаботиться даже объектами. После этого сверхусилия из многих модулей объемом 41к можно будет получить 20к, а иногда даже 7к что положительно скажется на вашей карме.
That`s all.
Метки: комментарии, методология, программирование
Программисты vs Заказчики
Ноя 3, 2009 Программирование
Сегодня на прочитал что во всех бедах заказчиков виноваты программисты. Люди это в большинстве своем ненадежные, кидалы и просто ходячее пособие по распиздяйству. Можете считать все что ниже ответом разгневанного программиста:
1. По хорошему между программистом и заказчиком должен находиться еще как минимум проектный менеджер. Проектный менеджер это человек понимающий заказчика и программиста (грубо говоря это аналог совкового технолога способный невнятное лепетание заказчика перевести в простые логические конструкции).
2. Т.к. менеджеров у нас нет, а там где есть дорого, то заказчики идут к частникам. Частник лицо анонимное, на данный момент у нас школьник за 2 недели прочитавший книжку по пхп уже считается программистом. Здесь важно понимать, что большая часть провальных проектов именно на это и напарывается. Понимаете, в программировании есть понятия проектирования и кодирования. Книжка по пхп дает понятие о кодировании, но не учит алгоритмистике, не объясняет паттернов, не дает устойчивых конструкций.
Вообще большая часть из присутствующих на рынке сегодня программистов ниже среднего уровня (чтобы было понятно себя со своими около 10 годами опыта промышленного и коммерческого программирования я отношу к разделу чуть ниже среднего). У нас много кодеров, но мало архитекторов. Даже изучая исходные коды большей части крупных веб систем на сегодняшний день понимаешь что код и архитектура находятся на доисторическом уровне.
3. ТЗ превращается. По моим оценкам порядка 40-60% проблем на рынке фриланс программирования приходится на нечеткую постановку задачи. В ходе начала работы ТЗ начинает мутировать, расти, меняться в итоге на выходе получается совсем не то, что заказывали. Причины я думаю всем понятны, в ходе работы заказчику очень хочется добавить пару удобных вещиц, присобачить еще вот это, на середине проекта понять, что ошибался и переделать заново и т.д. При этом на все заявки программиста о том, что цена меняется начинаются вопли, мол обирают нас и работать вы не умеете.
4. Неумение формулировать задачу. Второй проблемой с ТЗ является неумение заказчика объяснить что он хочет. Очень часто заказ носит характер показа страницы или скрипта и вопля мне нужно вот это но не так. Здесь сходу можно оценить уровень программиста на которого вы наткнулись. При неясных вводных нормальный исполнитель запросит как минимум пару примеров входных и выходных данных. На основе этой информации можно попробовать прикинуть, как работает потенциальный заказ. Проблема в том, что мы не Кашпировские и знать что происходит в фантазии заказчика не можем. Проблема решается прототипированием — сбором минимальной конфигурации рабочего примера и последующим обсуждением с заказчиком что так, а что нет. Это естественно требует времени. (подробнее об этом ниже).
5. Я не знаю ни одного проекта сложнее 2+2 который писался бы с первого раза. Любой проект в рамках сущесвтующих систем управления разработкой проходит несколько обязательных этапов. Агиле жестокая штука. Без прототипа вы не выйдете на альфу. Без альфы нет беты. Без беты сложно прыгнуть сразу на релизкандидат. Ну а от релизкандидата до релиза уже рукой подать. В ходе этих этапов разработки программист и заказчик вырабатывают общее видение разрабатываемого продукта и начинают хоть как-то друг друга понимать.
6. Наиболее производительные спарки — хорошо притерты. При длительной работе с программистами на каком-то этапе заказчик все же мутирует в подобие проектного менеджера, правда программист тоже частично в него мутирует, тем самым они вдвоем заполняют имеющуюся брешь в процессе разработки. Многие заказчики часто входят в заблуждение что если они успешно работают с одним программистом, то эта же схема будет работать и на другом. Это заблужение. Программист не БМВ, уровень мастерства, опыт и понимание у каждого разные. Факты понятные изначально одному, могут представлять собой темный лес для другого. Именно поэтому я считаю наилучшим вариантом длительное сотрудничество подобных пар (для примера я работаю, правда уже с партнером, над проектом порядка полугода. За полгода мы научились как-то понимать друг друга).
7. Программисты работают лишь 30% времени в день. Господа, я открою вам секрет, 30% это очень большой показатель. Ваши вечные жалобы что программисты лишь в пустую тратят ваше время и бабки — ошибка. Программирование (именно программирование, а не кодинг) это не гайки на заводе закручивать. Любой программист, как и писатель 90% времени думает и лишь 10% времени пишет. Если программист не будет думать, то вы получите тонны кода, который будет либо не оптимальным, либо нерабочим, либо просто не там где надо.
Все выше имхо, но близко к истине. Думайте. Комменты в тему приветствуются.
Рекламный блок
Топографию в школе слышали? Все виды топографических работ и услуг в одном месте. Топографические работы проводят истинные мастера своего дела с богатым опытом и не скудным внутренним миром. Заказывайте пока дешево.
Метки: заказ, программирование, фриланс
JQuery autocomplete — как заставить автозаполнение работать?
Июнь 3, 2009 Программирование
Долго я оттягивал появление постов о программировании на этом блоге, но от основной профессии никуда не денешься и вот этот час настал...
Вторые сутки пытаюсь прикрутить автозаполнение к input при помощи jquery. Нихрена не работает. Причем похоже причина в моих родимых руках...
Рекламный блок
Евпатория цены — популярный запрос для поиска дешевого отдыха на побережьи. Кстати город очень прикольный, можно не только погреть тушку на пляже, но и посмотреть много интересного в самом городе.
Конец рекламного блока
Автозаполнение сложное. В форму может вводиться либо код, либо текстовое значение и для обоих случаев должна отрабатывать подстановка. В теории все просто.
1. Делаем форму.
2. Прикручиваем jquery с соответствующим плагином
3. Передаем данные на серверный скрипт, анализируем ввод и если там циферки выбираем по полю кода, иначе выбираем по текстовому полю.На выходе лажа, запрос проходит, отдача формируется в списке заполнения мусор.
Поидее проблема с форматом отдачи скриптом. Во первых глючит кодировка (хотя на сколько я понимаю должна быть utf-8) во вторых я где-то намудрил с функцией разбора.
Короче буду копать, как отрою сразу же сообщу.
Как вы считаете нужна ли на этом блоге серия статей по JQuery? Помощь по автозаполнению и вопросы по теме в комментах приветствуются.
Метки: ajax, autocomplete, Jquery, php, программирование
