Перманентне питання продуктивності. Размишлізми четвертої ранку
Тепер я знаю як виглядає параноя: це коли зовні нормальний чілавєк підривається в четвертій ранку, щоб вже бігти робити заміри продуктивності. Оскільки інших таваріщів в чаті не було, довелось піти шпарити свій код...
Продуктивність -- це як ілавєк справляється з якимись базовими задачами. Наприклад, звичайний сайт візитка робиться мною за два дні: день на верстку та день на посадку й відшліфовку функціоналу. Мова про технічну частину, оскільки в залежності від клієнта дизайн може робитись до півроку...
6 годин на функціоналку 12-ти годинної роботи це реально. Це нормально, якщо ти вже робив подібне і пам'ятаєш, яка контрольна точка буде наступною. Верстка та функціоналка магазину робиться до 2-х тижнів (верстка та посадка на функціонал). Там роботи на ~70 і якщо пробувати отримати подвійне прискорення то порядком підгорають твої процесори...
Тиждень на повну зачистку функціоналки потрібен при умові, якщо чілавєк вже працював з системою, знає, де переоприділяються шаблони та орієнтується в кодах виклику функцій. Якщо хлоп з системою не працював, потрібно 2 тижні, тобто + 100% на підбір рішень та пошуки місця, з якого ростуть ноги.
Раніше, коли я працював сам, то міг спокійно поклястись мізинчиком, що впораюсь до дедлайну (хоча, якщо не клявся, то часто той дедлайн завалював). Щоб орієнтуватись в часових рамках своїх хлопів, мені слід буде трохи поноситись з годинником.
До того ж інакше постає питання стандартизації коду: одне рішення може забрати менше часу, ніж інше, проте витягне всі соки з наступного девелопера, який спробує апгрейтнути продукт.
Відтак, в списку актуальних проблем ведення проектів продуктивність ставимо на перше місце:
Продуктивність -- це як ілавєк справляється з якимись базовими задачами. Наприклад, звичайний сайт візитка робиться мною за два дні: день на верстку та день на посадку й відшліфовку функціоналу. Мова про технічну частину, оскільки в залежності від клієнта дизайн може робитись до півроку...
6 годин на функціоналку 12-ти годинної роботи це реально. Це нормально, якщо ти вже робив подібне і пам'ятаєш, яка контрольна точка буде наступною. Верстка та функціоналка магазину робиться до 2-х тижнів (верстка та посадка на функціонал). Там роботи на ~70 і якщо пробувати отримати подвійне прискорення то порядком підгорають твої процесори...
Тиждень на повну зачистку функціоналки потрібен при умові, якщо чілавєк вже працював з системою, знає, де переоприділяються шаблони та орієнтується в кодах виклику функцій. Якщо хлоп з системою не працював, потрібно 2 тижні, тобто + 100% на підбір рішень та пошуки місця, з якого ростуть ноги.
Раніше, коли я працював сам, то міг спокійно поклястись мізинчиком, що впораюсь до дедлайну (хоча, якщо не клявся, то часто той дедлайн завалював). Щоб орієнтуватись в часових рамках своїх хлопів, мені слід буде трохи поноситись з годинником.
До того ж інакше постає питання стандартизації коду: одне рішення може забрати менше часу, ніж інше, проте витягне всі соки з наступного девелопера, який спробує апгрейтнути продукт.
Відтак, в списку актуальних проблем ведення проектів продуктивність ставимо на перше місце:
- продуктивність виробництва;
- навчання персоналу, стандартизація коду, коменти;
- документація ведення проектів, автоматизація процесів;
- проблема впорядкування проектів об'ємом понад 70 годин.