Привет! Спасибо за уточнение. Мы хотели показать пример как это работает без необходимости глубоко вникать в суть, поэтому в статье есть упрощения и допущения. В жизни вряд ли фронтендер будет поднимать ssh на сервере, это админская задача, но высокоуровнево понимать что происходит по ту сторону может быть полезно для диалога.
Ты описал классный пример, как правильно, и он будет отличным блоком «В работе». Приходи его писать!
Мы рассматривали разные варианты, в том числе специально заточенные под документацию, типа GitBook, но все они либо не давали лёгкой возможности кастомизации, либо тащили свои процессы публикации. В общем, дьявол в деталях, которые не поменяешь.
В итоге мы решили развязать себе руки и выбрать самое гибкое решение.
Юмор — юмором, но лучше решать проблему хорошо, чем пассивно-агрессивно обижать человека. Стоило бы на этапе верстки договориться о заглушках. Такое умение сразу дает +100 к карме верстальщику
Я полагаю, что в качествен инструментов имелись ввиду две вещи: стандартные соглашения форматирования и автоформатирование в IDE.
Но на самом деле эти инструменты не исключают необходимость проверки. Очень часто бывает, что человек перед коммитом забыл вызвать функцию автоформатирования в IDE. Если это не контролировать и позволять изменять репозиторий, то следующий человек отформатирует код и в истории будет именно он, что ненамного, но затрудняет поиск реального автора кода.
Год назад попробовал практиковать полифазный сон. Сердечко пошаливать начало на второй неделе. Пошел на кардиограмму, где врач сказал мне, что все в порядке, но организм нетполноценно не отдыхает и посоветовал снизить физическую активность.
Хочется верить, что перевод на другие языки это только начала работы над интернационализацией. Очень было бы круто сделать попроектное назначение языков, так как бывает, что один проект ведется с русскоговорящим клиентом, другой с англоговорящим.
В таком случае не придется делать мучительный выбор между клиентами.
Мы все знаем, что проекты регулярно опаздывают. Считаю необходимым мысль о том, что опоздания возможны, донести до заказчика. Поэтому нужно всегда держать его в курсе событий — для этого есть много методов, например еженедельными отчетами с оценкой рисков опоздания.
В таком случае клиент во-первых, видит процесс работы, прогресс и часть подводной стороны айсберга, во-вторых, видит риск задержки, в-третьих, так как риск опоздания виден заранее, а не по факту, можно не дожидаясь опоздания проекта искать пути выхода.
А если прийти к клиенту в день, когда нужно сдавать работу и сказать «дорогой, я оценивал месяц назад проект от X дней, то сейчас я начал кодить и на эту работу нужно 2*Х дней» это значит проявить себя некомпетентным. Нормальный клиент сразу на дверь в таком случае покажет или как минимум расскажет о вас много нового и задаст много интересных вопросов. И будет прав.
Привет! Спасибо за уточнение. Мы хотели показать пример как это работает без необходимости глубоко вникать в суть, поэтому в статье есть упрощения и допущения. В жизни вряд ли фронтендер будет поднимать ssh на сервере, это админская задача, но высокоуровнево понимать что происходит по ту сторону может быть полезно для диалога.
Ты описал классный пример, как правильно, и он будет отличным блоком «В работе». Приходи его писать!
Мы рассматривали разные варианты, в том числе специально заточенные под документацию, типа GitBook, но все они либо не давали лёгкой возможности кастомизации, либо тащили свои процессы публикации. В общем, дьявол в деталях, которые не поменяешь.
В итоге мы решили развязать себе руки и выбрать самое гибкое решение.
Мы сейчас как раз обсуждаем изменения в темную тему. Приходи в ишью и вместе сделаем лучше 🙌
Автор, скорее всего, хотел привести более-менее универсальный список, который можно адаптировать под нужды.
Та же проверка входных данных на тип годится только для языков с нестрогой типизацией :)
Но на самом деле эти инструменты не исключают необходимость проверки. Очень часто бывает, что человек перед коммитом забыл вызвать функцию автоформатирования в IDE. Если это не контролировать и позволять изменять репозиторий, то следующий человек отформатирует код и в истории будет именно он, что ненамного, но затрудняет поиск реального автора кода.
В таком случае не придется делать мучительный выбор между клиентами.
В таком случае клиент во-первых, видит процесс работы, прогресс и часть подводной стороны айсберга, во-вторых, видит риск задержки, в-третьих, так как риск опоздания виден заранее, а не по факту, можно не дожидаясь опоздания проекта искать пути выхода.
А если прийти к клиенту в день, когда нужно сдавать работу и сказать «дорогой, я оценивал месяц назад проект от X дней, то сейчас я начал кодить и на эту работу нужно 2*Х дней» это значит проявить себя некомпетентным. Нормальный клиент сразу на дверь в таком случае покажет или как минимум расскажет о вас много нового и задаст много интересных вопросов. И будет прав.