Как найти грамотного програмиста

Естестно :) Зачем же тогда программер? Он дока - ему карты в руки! По другому это просто стенографистка, не иначе...

Не во всех случаях, оно конечно так... но в подавляющем большенстве.

Представьте ситуацию: Я Проектный менеджер, взялся реализовать проект. Что же мне, идти к заказчику и требовать от него подробного плана мероприятий, вплоть до ежедневного графика!?

Какова же будет моя роль и за что мне платить деньги? За Ноги?

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

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

Lisa, да, планировали вчера вечером получить готовое решение (при начале работ утром).

Довольно сжатый график. Довольно неплохой ТЗ, не лучший но и не худший.

(просмотрел по диагонали правда)

В целом... быстро только кошки родятся...

По мне, так абсолютно нормальный случай, когда приоритеты были расставлены

не совсем верно, т.е. исполнитель не понял, что надо "кровь из носу вечером",

а понял, что надо "кровь из носу круто".

ЗЫ. А эээ... не быстрее было сделать самому, чем ТЗ писать :) ?

Или это эксперимент такой ? Просто практика показывает, что

на один день обычно нецелесообразно бывает людей нанимать.

ЗЫЫ. Есть такой документ у некоторых... блин... склероз...

Короче правила по оформлению и написанию кода. Чтобы потом не было удивления.

К примеру я довольно долго имел дело с такими, где 25% синтаксиса С++ было

попросту запрещено. Дабы монстры не самовыражались.

(бывали случаИ от которых кровь стыла в жилах)

Очень полезно его (документ) составить.

Правда до 10-15% времени у людей уходило на причесывания кода.

Зато у ВСЕХ и ВСЁ было единообразно, включая формат комментариев итп.

У вас не заметил, только абстрактные слова о том, что "должно быть читаемо".

На php бог миловал, может там есть общепризнанный стандарт ?

Там заодно были всякие банальные слова написаны, что текстовые константы

должны быть отдельно, что числовые должны быть объявлены, что переменные

должны быть ЯВНЫМ способом проинициализированны итп.

Все эти спорные и необязательные моменты сильно облегчают жизнь потом.

Такой-же документ бывает и касательно проектирования.

Я бы мучался больше суток, скорей всего, и я отдаю себе отчёт, что у меня любительский уровень - в коде нечем было бы гордиться. Не, всё работало бы отлично, но всё же хочется на этот раз выполнить проект профессионально. Ну и вообще очень важный момент: стараюсь как можно больше задач теперь отдавать на сторону, потому что время — драгоценный ресурс. Мне правильно заниматься тем, что у меня лучше всего получается и что мне нравится. Разработкой интерфейсов, например, ну и постановкой задач (учиться лаконичности и точности).

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

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

К сожалению (или счастью) с открытыми стандартами не работал никогда.

Обычно есть люди, которым сопровождать, у них есть требования, они и описаны.

Т.е. как правило там 99% можно оспорить с точки зрения здравого смысла, но

в общем логика простая "кому долбаться - тот заказывает музыку".

Да, круг исполнителей, особенно разовых здорво ограничит.

Вообще мне лично стремно было бы на биллинг каких-то непонятных людей нанимать :)

А еще стремнее потом с написанным ими кодом работать.

Да со справочными материалами все довольно неплохо обычно. Это только не очень нужно.

Но если есть общепринятое, то конечно лучше использовать его.

Однако поверху можно навернуть и своего слегка.

К примеру "каждый случай множественного наследования должен быть письменно(мыло) одобрен архитектором, в коде должны стоять комментарии с обоснованием", "если в вашем switch нет default, то что-то тут не так" итд итп. Современные языки дают много альтернативных путей решения одних и тех-же задач. Существенную часть из них лучше купировать сразу, иначе будет "кто в лес, кто по дрова". Для каждого проекта обычно свой документ, но отличия редко существенны. Доводилось мне с Java иметь дело, так там нам присылали готовый файл с настройками чекстайла, который 99% проблем рубил сам. Не давал функции больше 250 строк писать, рубил кривые имена итд итп.

Собственно ваши требования похудели бы на половину полагаю. Если бы был такой готовый документ. В этом была цель. У вас там половина довольно очевидных и понятных вещей.

(типа копирайтов, текстовых констант итп)

Не, в этом смысле человек надёжный, я ему доверяю.

Да и код я просмотрю, пойму если где-то "закладка" или что-то в этом роде.

Спасибо, не думал об этом. Скорей всего приду постепенно к такому документу-стандарту, а может быть и нет :) Слишком усложнять и формализовать творческий процесс тоже не хотелось бы, а то всё желание творить пропадёт нафиг. Это ведь тоже важно.

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

http://gettingreal.37signals.com/GR_rus.php#ch16

Об тупом саботаже речи нет.

Понимаете... тут есть одна опасность.

Через год-два кто-нибудь найдет и воспользуется уязвимостью.

Не тупой закладкой, а ошибкой.

Как будете узнавать специально он ее оставил или нет :) ?

И в голове... будут крутиться неправильные мысли почти наверняка... что не есть хорошо.

Какое может быть творчество в вопросах ОФОРМЛЕНИЯ идей ?

По опыту скажу - это все конечно раздражает и довольно сильно,

но в общем-то выхлоп того стоит.

Сильно сомневаюсь что в результате у вас получится код в одном стиле :).

Хотя, если время жизни вашей системы мало, поддержка не требуется итд итп,

то всем этим можно пренебречь.

_SP_, ошибки у всех бывают, на 100% никогда ничего нельзя гарантировать. Но как считаете, более вероятно, что ошибку допущу я, любитель, или профессионал? Думаю, второе менее вероятно. + В планах у меня отдать скрипты на растерзание специалистов по безопасности, есть такая услуга. Покажут уязвимости, если есть.

Как какое? Техническое! :)

Чаще всего единство стиля не является наиболее приоритетной задачей.

Вы не поняли посыла.

1. Если вы сделаете все сами - вы будете знать что ошибка случайность.

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

А он вам дорог ?

Ставить // или /* в комментариях ?

Вам есть разница, реально :) ?

А ведь когда ставят вперемешку, то потом приятного мало.

(надо скажем покоментить блок целиком, а там внутри пяток разработчиков уже

вообще все возможные способы использовали :)

Нотация в именах переменных типа IsValid или Is_Valid вас сильно ограничит ? А isValid ?

А ведь имея один стиль я могу СХОДУ писать код... т.е. никуда не смотря вообще,

даже в объявления.

Имена для локальных переменных с каким-нибудь префиксом типа iInternal чем хуже

любой другой ?

Наличие автора для каждой функции чем плохо ?

Итд итп.

Речь о разумных рамках при оформлении работы.

Пример... простой... есть ГОСТ на чертежи... для архитекторов.

А ведь моглиб каждый "рисовать" "как хочет", и потом выб не смогли определить

где капитальная стена, а где временная...

Тогда да, можно этим всем не морочиться.

Сделали-сдали-забыли. А долбится с этим всем пусть кто-то другой, ему за это денег платят.