На текущий момент, самое успешное что я знаю из подобного, это connexion. У него много проблем, в том числе и та, что он сам по себе проблема, но он наиболее близок к решению подобной задачи.
Очередное нежелание глубоко освоить инструмент. Просто опишите спеку на OpenAPI и всё. Изменение кода будет требовать изменений в спецификацию и в таком виде. И это будет в разы сложнее. Код захламлён, описание спеки усложняется постоянным дублированием. Плюс к этому нужно втащить в проект минимум два модуля дополнительных.
За идею разместить на гитхабе — спасибо.
Здесь могут быть некоторые разночтения, но лично я пишу юнит-тест на функцию или метод класса, этот уровень мне кажется приемлемым.
Безусловна вся программа это собрание зависимых между собой методов и функций. И тут важную роль играет тестовый инструментарий. Например тот же pytest позволяет создавать своеобразные каскады тестовых данных. Это когда ты создаёшь фикстуры используя в качестве родителей другие фикстуры. И вопросы зависимостей решаются хорошо. Вот класс А он ни от кого не зависит (ну или с некоторым отступлением позволяет себя так рассматривать), вот класс Б он зависит от класса А.
Создаём тесты на класс А.
Создаём фикстуру, которая возвращает класс А.
Создаём тесты на класс Б в которых используем фикстуру с А.
Создаём фикстуру, которая возвращает класс Б.
Создаём тесты на класс А, для ситуации когда ему нужен Б. И применяем имеющиеся фикстуры.
Далее, берём задачу и думаем, что нам надо. Нам надо изменить класс А, каким образом? Добавить функционал или провести рефакторинг? Соответственно работаем. Добавляем в тесты и фикстуры изменения, чтоб получался ожидаемый результат.
Пускаем тест, не пашет. Берём лопату и идём копать пока не отработает ожидаемо.
Зачастую это не так. Пишешь-пишешь, оппа, оказывается есть такой подводный камень и пол решения надо переделывать, включая интерфейс взаимодействия с внешним миром. Половина тестов к коту под хвост.
Или вот про зависимости. Начали по ТДД, раз тест, два тест, три. А потом добавили зависимость — и все предыдущие тесты надо поправить. Потом снова. А затем переосмыслил подход и избавился от зависимости — снова меняем ранее написанные тесты.
Такое происходит тогда, когда меняешь интерфейс взаимодействия с внешним миром.
Если ты что-то переосмыслил и у тебя полетел тест, значит тут или исправлен баг или изменилась бизнес-логика.
Для меня лично применение практик TDD, стало обыденностью. Но нужно понимать, что тот же господин Бек, решает в первую очередь вопросы собственного рабочего дискомфорта. Например его онанизм на зелёную полоску это просто медитативная техника. Многие для того же используют ручное форматирование кода или попивание кофейка — сделал глоточек (поставил пробельчик) — обдумал — ещё глоточек (пробельчик). И всё в том духе.
На мой субъективный взгляд, основная ошибка применения TDD это забывчивость о задаче проектирования решения, собственно поставленной задачи. Мы НЕ движемся маленькими шагами, мы следуем техпроцессу. А тест это и есть техпроцесс, причём пошаговый техпроцесс. В различных инженерных отраслях техпроцесс уже больше сотни лет норма. Отличие лишь в том, что пишутся огромные талмуды специальными людьми, а программист будет писать небольшой локальный техпроцесс, для себя. Никто из химиков, машиностроителей и прочих, не бежит заглядывать в ректификационную колонну или выдёргивать из автомобиля мост, чтоб посмотреть как оно ДОЛЖНО работать. Он читает техпроцесс. А токарь не смотрит как эта самая машина едет мимо, видит мост и делает также. Он берёт техпроцесс и делает деталь согласно ему.
То что разработчик имеет лёгкий доступ к коду программы и сильное дробление на отдельные задачи и подзадачи, не отменяет тот факт, что принципы его работы глобально не отличаются от других инженерных специальностей. Просто они имеют некоторые особенности.
Тест помогает осознать последовательность шагов, применяемые решения и узкие места. А также показать, что и с каким результатом сделано. Не нужно применять его как медитативный инструмент, или вам перекрыли доступ к кофе?
В моём пет-проекте используется EAV. Наелся этого по самое нихочу.
Автор ничтоже сумняше не раскрыл один момент. Трёхтабличный EAV это не более чем пример практики, в реальности что-то адекватное можно построить не менее чем на 7. В моём проекте эта схема реализована на 9 и планирую расширить до 12 в ближайшей перспективе.
Благодаря этому я сохранил преимущества EAV плюс добился того что атрибуты хранятся в БД в своём типе, а не в строке. Недостатки остались конечно.
Вопрос производительности остаётся открытым и стоит остро. Метрики этого пока не собираю.
Тяжеловатая статья. Тем кто собирается изучить SQLAlchemy предлагаю начать с Мега-учебника Гринберга и после сразу переключиться на официальную документацию.
По моему мнению декларативное описание несколько чудное и отношения раскрыты недостаточно (да я видел слово «основы» в названии).
Непонятно почему используется VARCHAR, а не String.
Есть такой фильм «Человек который изменил всё». Так вот там была цитата про 50 метров г… на. Рекомендую просмотреть и оценить весь её шик.
Если применить подобный алгоритм, то получится специалист о котором заунывно взывают статьи подобные этой:
1. Высшее образование получать нужно. Лучше даже два. Первое какое-либо техническое, второе IT на базе технического (нужно будет отучиться 3 года вместо 5 в сумме 8 лет).
2. Устроиться на должность максимально близкую к ИТ, в идеале стажёром на погроммиста.
3. Пахать 10 часов в день, каждый день, без выходных и по 5 часов в праздники.
4. Учиться, учиться и ещё раз учиться.
5. Повтори пункт 4.
Не рекомендую тратить много сил на муки выбора, лучше всё пробовать и всем заниматься. Когда поймешь, что есть что в общих чертах, сможешь сам решить, в каком направлении надо двигаться, а от какого лучше отказаться.
Сергей, младший программист
Золотые слова!
А ещё я бы посоветовал ставить себе достижимые цели и верить в себя. А всё остальное придёт.
Я тоже админил больше 10 лет. Курсов не заканчивал. Через 4 года стал миддлом. Учавствовал в 2 довольно больших проектах, сейчас в третьем и делаю свой маленький веб-сервис. И что ж я теперь не могу честно сказать, что я разработчик среднего уровня?
Не боитесь размывания целеустремления сотрудника? Всё-таки его задача разработка и получение продукта определённой готовности. По моему опыту, когда ты и швец, и жнец, и ещё за кадровика тащишь 100% собеседования, начинается выпадение из твоего собственного рабочего русла. Как итог ты везде и нигде, плюс на тебе ответственность за принятые решения за которые приходится отвечать, вместо того, чтобы писать код.
Часть про эйчаров описывает вполне осуществление такого понятия как наставничество.
Хотелось бы услышать кто в компании ведёт личные дела сотрудников, вписывает изменения о составе семьи, подаёт всякие табели и прочее на расчёт зарплаты, отслеживает изменение внутренней трудовой документации в соответствии с законодательством, тусит на всяких сайта по найму сотрудников. И кто подписывает эти документы и изменения.
Я лишь вижу размазывание руководящей ответственности по сотрудникам, для прикрытия руководителей. Замена слова руковожу на слово отвечаю — «Я отвечаю за работу одного из подразделений разработки в компании 2ГИС — нас 36 человек, 4 команды.», на мой взгляд цинично.
Кстати, как у вас там с оплатой дополнительной нагрузки?
Я почти 15 лет работал в офисе в чётком 8-ми часовом рабочем дне. Работал в довольно сложных условиях, муниципальная и государственная служба. Атмосфера в данной среде своя и вынуждает очень мощно прокачивать коммуникативные навыки. Причина в том, что зарплаты очень низкие, качество специалистов как правило либо очень низкое, либо, внимание, на высоком уровне, но как люди они специфичны. Плюс без хорошего отношения с сотрудниками организации практически ни одно дело не идёт хорошо.
В погоне за деньгами и эмоционально спокойной работой, где не надо быть личным психологом каждого третьего, решил устроиться на удалённую работу простым разработчиком.
Снял небольшой офис на 15 квадратных метров в пяти минутах ходьбы от дома. Постарался выстроить тот же 8 часовой рабочий день. В принципе получается неплохо, работа сделана, обстановка спокойная, сам собой доволен. Работодатель кажется тоже.
Очередное нежелание глубоко освоить инструмент. Просто опишите спеку на OpenAPI и всё. Изменение кода будет требовать изменений в спецификацию и в таком виде. И это будет в разы сложнее. Код захламлён, описание спеки усложняется постоянным дублированием. Плюс к этому нужно втащить в проект минимум два модуля дополнительных.
За идею разместить на гитхабе — спасибо.
Безусловна вся программа это собрание зависимых между собой методов и функций. И тут важную роль играет тестовый инструментарий. Например тот же pytest позволяет создавать своеобразные каскады тестовых данных. Это когда ты создаёшь фикстуры используя в качестве родителей другие фикстуры. И вопросы зависимостей решаются хорошо. Вот класс А он ни от кого не зависит (ну или с некоторым отступлением позволяет себя так рассматривать), вот класс Б он зависит от класса А.
Далее, берём задачу и думаем, что нам надо. Нам надо изменить класс А, каким образом? Добавить функционал или провести рефакторинг? Соответственно работаем. Добавляем в тесты и фикстуры изменения, чтоб получался ожидаемый результат.
Пускаем тест, не пашет. Берём лопату и идём копать пока не отработает ожидаемо.
Такое происходит тогда, когда меняешь интерфейс взаимодействия с внешним миром.
Если ты что-то переосмыслил и у тебя полетел тест, значит тут или исправлен баг или изменилась бизнес-логика.
На мой субъективный взгляд, основная ошибка применения TDD это забывчивость о задаче проектирования решения, собственно поставленной задачи. Мы НЕ движемся маленькими шагами, мы следуем техпроцессу. А тест это и есть техпроцесс, причём пошаговый техпроцесс. В различных инженерных отраслях техпроцесс уже больше сотни лет норма. Отличие лишь в том, что пишутся огромные талмуды специальными людьми, а программист будет писать небольшой локальный техпроцесс, для себя. Никто из химиков, машиностроителей и прочих, не бежит заглядывать в ректификационную колонну или выдёргивать из автомобиля мост, чтоб посмотреть как оно ДОЛЖНО работать. Он читает техпроцесс. А токарь не смотрит как эта самая машина едет мимо, видит мост и делает также. Он берёт техпроцесс и делает деталь согласно ему.
То что разработчик имеет лёгкий доступ к коду программы и сильное дробление на отдельные задачи и подзадачи, не отменяет тот факт, что принципы его работы глобально не отличаются от других инженерных специальностей. Просто они имеют некоторые особенности.
Тест помогает осознать последовательность шагов, применяемые решения и узкие места. А также показать, что и с каким результатом сделано. Не нужно применять его как медитативный инструмент, или вам перекрыли доступ к кофе?
В моём пет-проекте используется EAV. Наелся этого по самое нихочу.
Автор ничтоже сумняше не раскрыл один момент. Трёхтабличный EAV это не более чем пример практики, в реальности что-то адекватное можно построить не менее чем на 7. В моём проекте эта схема реализована на 9 и планирую расширить до 12 в ближайшей перспективе.
Благодаря этому я сохранил преимущества EAV плюс добился того что атрибуты хранятся в БД в своём типе, а не в строке. Недостатки остались конечно.
Вопрос производительности остаётся открытым и стоит остро. Метрики этого пока не собираю.
Миграции данных делаешь сам.
По моему мнению декларативное описание несколько чудное и отношения раскрыты недостаточно (да я видел слово «основы» в названии).
Непонятно почему используется VARCHAR, а не String.
Если применить подобный алгоритм, то получится специалист о котором заунывно взывают статьи подобные этой:
1. Высшее образование получать нужно. Лучше даже два. Первое какое-либо техническое, второе IT на базе технического (нужно будет отучиться 3 года вместо 5 в сумме 8 лет).
2. Устроиться на должность максимально близкую к ИТ, в идеале стажёром на погроммиста.
3. Пахать 10 часов в день, каждый день, без выходных и по 5 часов в праздники.
4. Учиться, учиться и ещё раз учиться.
5. Повтори пункт 4.
Золотые слова!
А ещё я бы посоветовал ставить себе достижимые цели и верить в себя. А всё остальное придёт.
Часть про эйчаров описывает вполне осуществление такого понятия как наставничество.
Хотелось бы услышать кто в компании ведёт личные дела сотрудников, вписывает изменения о составе семьи, подаёт всякие табели и прочее на расчёт зарплаты, отслеживает изменение внутренней трудовой документации в соответствии с законодательством, тусит на всяких сайта по найму сотрудников. И кто подписывает эти документы и изменения.
Я лишь вижу размазывание руководящей ответственности по сотрудникам, для прикрытия руководителей. Замена слова руковожу на слово отвечаю — «Я отвечаю за работу одного из подразделений разработки в компании 2ГИС — нас 36 человек, 4 команды.», на мой взгляд цинично.
Кстати, как у вас там с оплатой дополнительной нагрузки?
Я почти 15 лет работал в офисе в чётком 8-ми часовом рабочем дне. Работал в довольно сложных условиях, муниципальная и государственная служба. Атмосфера в данной среде своя и вынуждает очень мощно прокачивать коммуникативные навыки. Причина в том, что зарплаты очень низкие, качество специалистов как правило либо очень низкое, либо, внимание, на высоком уровне, но как люди они специфичны. Плюс без хорошего отношения с сотрудниками организации практически ни одно дело не идёт хорошо.
В погоне за деньгами и эмоционально спокойной работой, где не надо быть личным психологом каждого третьего, решил устроиться на удалённую работу простым разработчиком.
Снял небольшой офис на 15 квадратных метров в пяти минутах ходьбы от дома. Постарался выстроить тот же 8 часовой рабочий день. В принципе получается неплохо, работа сделана, обстановка спокойная, сам собой доволен. Работодатель кажется тоже.