Необходимо оценить умение программиста

Собственно о чём спор то ?

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

$ext=substr($ufile_name,strlen($ufile_name)-4,4);

вот это кривовато, не у всех же файлов трехбуквенное расширение, имхо лучше использовать strrchr($ufile_name,".");

set_time_limit(0);
$file_out=fopen(getcwd()."/parsed.sql","w");

Вот это чревато, лучше одноразовая запись в файл.

А вообще товарищ свое дело знает и мозги использовать умеет, так что "программисту" - зачет =)

neolord добавил 09.06.2008 в 00:17

На новичка не похоже. Во всяком случае когда я был новичком, я об fsockopen и некоторых других вещах даже и помыслить не мог. Но фиг знает, может кто-то с другого начинает =) Интересно было бы услышать критерии "опытности" программиста. Использование классов, или еще что-то?=)

Просто не пытался ибо занимался другими вещами, я наоборот очень быстро стал с fsockopen работать так как планировал изобрести несколько велосипедов с квадратными колёсами.

Критерии уже были озвучены в топике.

- не разделённая логика

- чёртикакая мешанина с выводом HTML

(отсутствует ощущение что это продукт, больше похоже на временную заплатку.)

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

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

Что касается перестройки архитектуры. Если вообще в системе есть архитектура, и разработчик ее ясно видит, понимает и знает, не вижу никаких сложностей с ее перестройкой. Если все методы занимаются своими делами и находятся на своих местах - что сложного в том, чтобы жонглировать ими при помощи copy-paste? :)

+1

у меня както так еще с php4 повелось, что в php я если пишу чисто сам, то ООП вообще не использую. Вернее не использую его в явной форме, а только в голове и логике именования функций помечаю мол это функция такогото модуля, а это его же, но "приватная", ну и тп...

так вот этот самый процедурно/модульный код у меня уже не первый год пререкачевывает из архитектуры в архитектуру, и готовый двиг весом в 100-200кб кода полностью переделывается за несколько часов во чтото совсем на него не похожее.. с другой логикой структуры папок проекта, с другой логикой построения URL, с другим алгоритмом авторизации, с другой схемой обработки URL и тп.. для этого нужно только грамотно продумывать структуру модулей, именования объектов и прочего... (конечно ООП в этом помогает, но и без этого тоже можно :) )

Вопрос рефакторинга всегда сводится к тому чтобы грамотно продумать архитектуру, а когда обстановка меняется, не поддаваться на соблазн сделать маленький "костыль", а сразу думать как это внести в мейнстрим-идеологию проекта, чтобы и это изменение автоматом отработать и весь класс подобных ей потом переварить на полуавтомате :)

Хотя не спорю, это реально только когда пишешь для себя, а не сметно/срочное задание в команде из 20 человек.. но и в таких условиях к этому надо стремиться :)

Помните игру "получить из волка козу, меняя по одной букве"? :) Тут также, можно сразу взять и сделать козу, а можно переделать волка. Казалось бы, это намного дольше, но заново сделанная коза будет обладать кучей багов, в отличие от переделанного, но отлаженного волка.

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

Все абсолютно верно. Но, как всегда бывает "любовная лодка разбилась о быт".

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

Все верно. Я как раз и пишу о том, что надо изначально все правильно проектировать. Только не понимаю, зачем копи-пасте, можно и библиотеки использовать :)

А вот копи-пасте, да еще с модификацией кода по месту - кратчайший путь к бардаку и потере управления :).

Мэкс добавил 09.06.2008 в 10:02

Вообще - то цикл действий по внесению изменений что по частям, что целиком - один:

1. Планирование изменений и определение зависимых процессов и данных по изменению.

2. Внесение изменений в прототип

3. Тестирование

4. Исправление ошибок

5. Еще раз тестирование

6. Разработка конвертора данных ( как правило структура баз данных меняется )

7. Тестирование конвертора данных

8. Импорт реальных данных в прототип

9. Проверка импортированных данных

10. Документирование изменений или выпуск новой версии документации

12. Принятие решения о модификаци рабочей системы.

13. Модифиация рабочей системы.

И все это только в случае, если мы можем остановить систему на несколько часов для апдейта.

Остановка системы например в банке или пенсионном фонде - это огромные организационные и технические трудности.

Если мы не можем останавливать систему, все усложняется в разы.

Внесение непосредственно изменений программистом в таком процессе - не более 10% трудозатрат.

Тут, как я понимаю, имелся в виду перенос (а не копирование) кода в более подходящее место.

Вот! Золотые слова. Нефиг давать программисту писать заплатки и не будет проблем :)

Всетаки чтобы было все грамотно изначально это работа не программиста.. ну или мы по разному определяем понятие программиста :)

По вашим словам от программиста зависит 10% эффективности изменений. Однако и в изначальной версии от кодера зависит те же 10%, хоть и по трудочасам он работает 80-90% от общего времени проекта (ну в крупных проектах).

От программиста требуется чтобы код выполнял задачу по заданному ему алгоритму, чтобы все пункты ТЗ были выполнены, чтобы код был достаточно отказоустойчив (ну а по хорошему стоит упомянуть и о XSS и прочих инъекциях в ТЗ на те модули в которых есть внешний ввод) и чтобы... чтобы его мог легко прочитать другой программист. Все остальное уже к технологу/постановщику/системному_архитектору и прочим :)

ЗЫ: по поводу качества программиста и читабельности кода есть хорошая фраза.. я ее себе на нулледе даже в подпись вынес:

Любой дурак может написать программу, которую поймет компилятор. Хорошие программисты пишут программы, которые смогут понять другие программисты. (Мартин Фаулер)

Ну хоть убей меня, чем крупнее проект тем меньше в нем кодерских трудозаорат.

1. Общий менеджмент проекта, написание технических требований, функциональных спецификаций, ТЗ.

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

3. Организация взаимодействия программистов ( планирование работ, контроль )

4. Организация взаимодействия с ИС заказчика

5. Разработка документации

6. Тестирование

7. Внедрение и обучение персонала заказчика.

Где тут время программиста?

Или это все тоже программист должен делать?