Александр Воробьев

Александр Воробьев
Рейтинг
59
Регистрация
03.02.2020
MrPi #:
ак, а критерии оценки какие? Я чуть посматриваю на ваш челлендж, но не пойму, как оценивать будут.

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

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

MrPi #:
антипаттерн - это Ларавель. Из всех крупных - мне ближе CI4

Мне в ларе не очень нравится, что там есть желание "обернуть" вообще все что есть в php :) в остальном (Если не использовать его в таком объеме) мне как раз таки он приглянулся (хотя больше вообще работаю с Битрикс и его фреймворком). помимо ларавель я только с симфони еще работал.  Посмотрю на cl4 - что там интересного.

А избыточность - цена расширяемости (конечно в удобном виде в моем понимании :) ).

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

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

MrPi #:
$definition не проверяется?

нет.

Вообще я в начале и местами поспешил, местами пока нет четкой картинки "что хочу".

Да run понимаю, тут в планах наводить чистоту точно.  собственно в нем todo для этого и висит

Итак очередной спринт завершился.

В этот раз движения более скромные (очень  насыщенные были две недели)

Шаблонизатор

Как и отмечал ранее:  Три раза переписав лексер, пришел к окончательному концепту. Для дальнейшей разработки требуется механизм регистрации модулей в фреймворке

Релиза пока нет, актуальное состояние модуля на момент этого сообщения на gtihub

Фреймворк

  • Готов механизм работы с окружением, 
  • Почти завершен механизм работы с конфигурационными файлами
  • Мелкие правки

Так же релиза пока нет, актуальное состояние на github в ветке next (на момент сообщения: здесь)

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

Так же принял решение, что подключу статанализ и следовать стилю кода PER CS 2.0 (а может и 3.0). Это dev зависимости проекта

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

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


В общем на следующий спринт: задача минимум выпустить релиз фреймворка с конфигурацией, с механизмом регистрации модулей, а так же есть у меня небольшой todo  , а в максимуме: реализовать в шаблонизаторе базовый функционал и базовые теги


PS Надеюсь ArbNet  завтра хоть, что то расскажет о подвижках


Ну у меня сразу - без докера. Есть ряд причин. В общем на данном этапе это до нагрузка мне будет и расширение зоны обязанностей (а мне это точно не надо).

Далее. Мастер. И две "типовых» ветки. Dev - это ветка которую показываю заказчику, с ней там работают тестировщики, или еще кто-то.   Hotfix. Через нее все попадает в мастер. Далее в зависимости от проекта. Где-то как я описывал выше, где-то мастер через гитлаб.

По тестированию. Тут все упирается в Битрикс. В прошлом году как раз делал инструмент для для мокирования какого либо Легаси и расширение к нему под Битрикс. В этом году буду внедрять. 

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

Ну а далее разработка в фича ветках, с тестами, потом сливаю все в мастер. Прогоняю окончательно тесты, анализ.... Выполняю автомнкремент версии и уже пушу на гитхаб. Т.е. пока у меня не высокая степень автоматизации. :) но я работаю в этом плане.
В общем на гитхаб "рабочие" ветки крайне редко залетают,  в плане проекта с фреймворком - все мержи локально
Sly32 #:
Значит ты удалял дев ветки, или не пушишь  их вовсе. Я предпочитаю мерж через гитхаб. А как ты релизы делаешь  , автоматом при мерже в  мастера?

Ну у меня не совсем "классическая" схема. Тому  ряд причин:

git использую даже на мелочах (для себя всякую мелочевку) - она вообще на github не бывает. Основные проекты Битрикс - там файлы могут быть изменены контент менеджером или СЕО шником (через интерфейс но все же) . Это тоже накладывает свое.  На большинстве проектов я один единственный разраб, и гита до меня не было. И там все без github и его аналогов.  (по сути на gitlab только есть рабочий проект один).  т.е. схема примерно такая: master - чистая ветка, все правки попадают на прод через hotfix.  Локально веду разработку в фьюча ветках, заливаю в hotfix, с боя в мастер принимаю все изменения, что там наколбасили все кому не лень, мержу в хотфикс с устранением конфликтов, далее на прод и там уже мержу в мастер. Да вроде как не правильно, но я привык :)  Пока не разбирался как по взрослому (опять же я ни когда не работал в больших командах с поставленным процессом). Если честно там где я один - не хочется запариваться с процессом и настраивать это все.  Тем более, может быть и такое: у меня один клиент попробовал другого разработчика, потом вернулся я "ремонтировать", одна из фишек от того разработчика: часть кода правилось от рута, и права 777  бахнуты.  :)

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

ArbNet #:
Упс. Мозг устаёт после напряжённого дня, а вот после несколько лет такой деятельности выгорает

Несколько это сколько? Я с 96 года, плюс до этого еще два года научная работа по разработки САПР.  ;)

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

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

ArbNet #:
Дневная задача решается проще и быстрее, а вот если бился над задачей несколько лет, то отдыха и времени на решение такой задачи нужно больше.

А почему сразу дневная? Для разгурзки хватает  хорошего сна. Когда есть обязательства не бывает "я сегодня не могу". Просто потом нужен качественный отдых. Я как то в было дело после  года напряженного 14 дней на все включено вообще провел в состоянии мозг выключен полностью. а потом снова в бой с полными силами

ArbNet #:
Надеюсь теперь вы меня хоть немного стали понимать.

Ну я и раньше понимал, просто наши взгляды сильно отличаются. Для меня выгорания не причина бросать работу и динамить заказчиков. Я своей репутацией дорожу. Против выгорания: сон, переключение между проектами (у меня их порядка 7 параллельно +  мой проект) ну и вот теперь с вами челендж - это тоже своего рода борьба с выгоранием (но ни каких задач я на паузу не ставлю). вот сейчас например работаю над задачей, которая пипец как надоела... и не идет. но решать надо - пользователи ждут

Sly32 #:
Кстати вот мне интересно, почему у тебя в гитхабе основная ветка - master? Руками переименовываешь? Уже давно стандарт - main

ИМХО, main - это стандарт  навеянной этой дебильной идеей про угнетение народов. Принципиально нет :) Завтра кто то пустит волну, что и "main" это оскорбление - опять перестраиваться под идиотов далеких от IT?  Лично мне master - понятнее и правильнее, в конце концов привычнее.

Sly32 #:
И ты не любишь gitflow?

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

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

Sly32 #:
Еще - docker-compose  теперь не требует версии - устарело.

оке

Факторов много, но можно действовать в парадигме снижения рисков:

- больше алкоголя - выше риск, значит стоит уменьшать

- качество алкоголя, если уж пить то хороший

- физкультура  - снижаем риск

- физкультура для мозга - снижаем риск

и т.п.

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

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

Sly32 #:

Ну чтож, очередная пятница и очередная тишина от "профессионала"... Похоже, за явным преимуществом досрочно победу можно присуждать Александру 💪

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

Ну справедливости для: все же челендж это не соревнование, а скорее оценивать можно будет по истечении года по достигнутому прогрессу. И, второе: "отчетная" неделя следующая.

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

Всего: 692