Материализую замыслы.
Контакты

Достижения

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

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

Все теги (23)

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

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

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

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

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

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

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

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

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

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

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

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

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

    Продолжай, и не делай всем раскладки просто так. Успехов.
    Ответ написан
  • Как правильно планировать проект?

    deppkind
    @deppkind
    www.mjolnir.wtf
    Тебе нужно получить обратную связь от твоего "запланированного" в виде визуальной картины.

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

    Быстрый старт - тебе понадобится доска, большая на всю стену, если нет - постарайся ее найти (я делаю доски сам и могу рассказать про все способы создания такого инструмента).

    UPD: ответил в ветке про доски:

    desktop-3bd1b3af88a948ffac62dbfd3a74daa1

    Доска должна жить с нарисованным не менее недели а лучше трех чтобы никто не стер информацию.

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

    Важно чтобы ты мог все время туда дописывать.

    Что делаешь - стоишь и думаешь о проекте, и любое слово (осмысленное) ты выписываешь из головы на доску. Просто в столбик и далее в колонки если место позволяет.

    Выписывать слова до момента когда ты осознаешь что в голове нет мыслей о проекте - они все на доске.

    Повторять этот пункт каждое утро.

    2. Глядя на все написанные смыслы в левой части - стараешься расположить их в формате сетевого графика, поняв что за чем следует и к чему приводит. Тут и помогает "доска", потому что ты можешь все время переделывать картинку.

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

    Повторять эту процедуру каждый день.

    3. Во втором пункте ты получил все свои цели. И если они тебе интересны - ты их для себя уже утвердил.

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

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

    4. Ты просто берешь каждую задачу которую сам себе описал и делаешь.

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

    Если тебе нужно определиться попробуй 5 почему Тойоды, или прочитай на эту тему хороший материал (в первой его части есть ответы на твои вопросы) - https://vc.ru/tribuna/67821-melnir-platforma-dlya-...

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

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

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

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

    deppkind
    @deppkind
    www.mjolnir.wtf
    Если так лень запушить на гитхаб - лучше не браться за такую задачу а заказать на фрилансе.
    Ответ написан