Задать вопрос
Понижение энтропии на заказ
Контакты
Местоположение
Россия, Москва и Московская обл., Москва

Достижения

Все достижения (2)

Наибольший вклад в теги

Все теги (24)

Лучшие ответы пользователя

Все ответы (40)
  • Попросили проверить код, на что смотреть нужно?

    apavlyut
    @apavlyut
    www.apavlyut.ru
    Все комментаторы совершили одни и те же ошибки управления потому что, при всем уважении, скорее всего за эти ошибки (в стратегировании) они не платят из своего кармана.

    На пальцах отвечаю на ваш вопрос:

    1) По структуре - при проверки качества кода / решения / задачи / продукта / настройки сервера и так далее нужно проходить по списку (чеклист) критериев контроля качества - обычно они выглядят как списки определенных параметров которые может замерить третье лицо или сама система - формат проверяемого параметра прямо вот соответсвует / не соответсвует. На сколько процентов пройден чеклист - на столько процентов результат "качественный"
    2) Почему ребята ошиблись - потому что стали приводить конкретные списки. Дело в том что у каждого проекта / сиутации / команды / набора компетенций - свои наборы таких чеклистов на разные ситуации. В больших командах сущесвтует основной чеклист который регламентирует CodeReview - и за него отвечает как правило тим лид - он его обновляет, развивает, обосновывает внесенные правила и следит за тем чтобы ПЕРЕД началом разработки все разработчики были ЗАРАНЕЕ ОЗНАКОМЛЕНЫ с этим порятком проверки качества, а все потому что:
    3) Количество стайлгайдов и критериев в приципе существует огромное количество - и то как каждому в одной части света / компании удобно делать одно дело - не регламентирует ни разу что именно так же другому человеку в другой ситуации применять эти правила к своему контексту. В виде открытых стайлгайдов они существуют для накопления практик и навыков в первую очередь для их же развития (процесс формулировки наводит порядок в голове) а также дают возможность "на них конкретно" нанизать точечные ответы огромного сообщества людей, и получить те самые разные взгляды на ситуации, и по возможности опять же привести к общему знаменателю. Но это все мелочи жизни, а в вашем случае вы совершите серьезную ошибку если прямо сейчас возьметесь (примите на себя ответственность) проверять чужой код на предмет оценки, потому что:
    4) Вас явно используют как внешнего эксперта на которого можно сослаться, от которого можно получить якобы аргументацию для давления на свою позицию при решении какой-то возникшей ситуации во взаимоотношениях клиент-разработчик на проекте куда вас приглашают за экспертизой.
    Если вы, не предупредив, о том что "качество кода" начинается с декларации этого качества (в случае если речь идет о проверке этого внутреннего качества в рамках сотрудничества, а не самих задач которые поставлены перед создаваемой системой - фичесов) - любая ваша оценка будет недостоверна контексту ее применения (вы напишете про строки или еще что-то - а у человека будут либо взыскивать деньги / либо недоплатят за работу / или инкапсулируют в договоренности пост фактум за те же деньги работу над соотвествием определенным стилям - это все работа которая должна быть оплачена). Поэтому вот вам вилка ваших дейсвтий:

    1) Если у вас просто просят менторства молодые коллеги - дайте им ссылку на гугл и ключевое словосочетание php style guide github
    2) Если вас спрашивают (либо вы сами являетесь таким заказчиком который ищет за что зацепиться в коде чтобы продавить свою позицию) - нет критериев качества кода ДО начала работ подписанных на бумаге / пересланных по почте - никакие критерии не могут быть применены к текущим отношениям - только к следующей итерации за следующие деньги.
    3) Если вы все же разработчик и вас попросили оценить код - донесите данную ситуацию до стадии корректного закрытия текущего этапа работ - но дальше предложите уже введение стайл гайда если оно того требует. Я полагаю что на самом деле нет. Дав сейчас ответ на вопрос в виде оценки качества кода вы сделаете только одно - абсолюно необоснованно дадите агрумент в явно перекошенном споре, и просто возьмете на себя еще один мешок кармогрязи которую будуете еще сколько-то положенного времени отрабатывать.

    Подумайте хорошо на эту тему - придется выбрать свою сторону.
    Ответ написан
    Комментировать
  • Стоит тратить свое личное время стартующему фрилансеру на клиента?

    apavlyut
    @apavlyut
    www.apavlyut.ru
    Все что ты делаешь для каждого заказчика обдумай в общую концепцию и сделай сначала твой план работ с клиентами и выложи это на одной странице.

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

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

    Если клиент не хочет с тобой работать а хочет "об тебя" подумать / прикинуть / получить проектировку бесплатно - лучше об этом узнать заранее.

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

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

    Продолжай, и не делай всем раскладки просто так. Успехов.
    Ответ написан
    Комментировать
  • В какой ИТ-сфере реально продолжить карьеру после 55 лет?

    apavlyut
    @apavlyut
    www.apavlyut.ru
    Научитесь решать проблемы без акцента на технологию - рекомендую изучить тематику по Системной инженерии.
    В этом направлении вы всегда останетесь при любимом техническом инструменте (сами выбираете что необходимо) и будете решать задачи, контролируя и аргументируя техническую часть самостоятельно. Хороших технических директоров крайне мало, платят хорошо, и возьмут именно тех кто "решает" вопросы, путем успешного применения конкретных технологий и направляя персонал на решения которые бизнес крайне ценит.

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

    Успехов.
    Ответ написан
    7 комментариев
  • Где хранить связки кода (примеры, микропроректы)?

    apavlyut
    @apavlyut
    www.apavlyut.ru
    Если так лень запушить на гитхаб - лучше не браться за такую задачу а заказать на фрилансе.
    Ответ написан
    Комментировать
  • Куда податься на фрилансе?

    apavlyut
    @apavlyut
    www.apavlyut.ru
    Зачем тебе апворк - иди на freelansim.ru, или если хочешь посражаться с нашими индусами тогда и на fl.ru

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

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

    Открой сайт и бери свои заказы на дошик - там их точно тебе хватит.

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

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

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

    Удачи!
    Ответ написан
    3 комментария