Сообщение Re: Отказаться от кул-фреймворков и вернуться к истокам - пл от 02.06.2022 15:33
Изменено 02.06.2022 19:03 Zhendos
Re: Отказаться от кул-фреймворков и вернуться к истокам - плюсы и минусы
Здравствуйте, Shmj, Вы писали:
S>Фреймворк вроде бы позволяет ускорить процесс разработки в n раз. Но при этом:
S>В итоге вместо изучения вещей базовых — тратится время на изучение продукта жизнедеятельности тех или иных авторов. Надоело вкрай.
S>Какое решение?
А в любом случае придется изучать "продукта жизнедеятельности",
даже если один работаешь. Можно только сдвинуть чуть-чуть границу
твой код, чужой, но все равно большая часть того, что твоя программа
запуститься и заработает зависит не от тебя (ОС, компилятор/интерпретатор,
стандартная библиотека твоего языка программирования и т.д. и т.п.).
И преимущество фреймворка, в том что из-за широты его использования
в разных проектах разными людьми его криво, косо можно заставить решить
большинство задач которые у тебя возникнут,
а вот собственная библиотека в этом смысле может потянуть на дно,
после пары тройки изменений в ТЗ, которые заставят отрефакторить
его на 90% и можно скатиться к тому что большую часть времени
выполняются не задачи, а допиливыается своя библиотека, что потом
выполнить поставленные задачи, но до реальных задача из ТЗ могут
руки и не дойти.
S>Фреймворк вроде бы позволяет ускорить процесс разработки в n раз. Но при этом:
S>В итоге вместо изучения вещей базовых — тратится время на изучение продукта жизнедеятельности тех или иных авторов. Надоело вкрай.
S>Какое решение?
А в любом случае придется изучать "продукта жизнедеятельности",
даже если один работаешь. Можно только сдвинуть чуть-чуть границу
твой код, чужой, но все равно большая часть того, что твоя программа
запуститься и заработает зависит не от тебя (ОС, компилятор/интерпретатор,
стандартная библиотека твоего языка программирования и т.д. и т.п.).
И преимущество фреймворка, в том что из-за широты его использования
в разных проектах разными людьми его криво, косо можно заставить решить
большинство задач которые у тебя возникнут,
а вот собственная библиотека в этом смысле может потянуть на дно,
после пары тройки изменений в ТЗ, которые заставят отрефакторить
его на 90% и можно скатиться к тому что большую часть времени
выполняются не задачи, а допиливыается своя библиотека, что потом
выполнить поставленные задачи, но до реальных задача из ТЗ могут
руки и не дойти.
Re: Отказаться от кул-фреймворков и вернуться к истокам - пл
Здравствуйте, Shmj, Вы писали:
S>Фреймворк вроде бы позволяет ускорить процесс разработки в n раз. Но при этом:
S>В итоге вместо изучения вещей базовых — тратится время на изучение продукта жизнедеятельности тех или иных авторов. Надоело вкрай.
S>Какое решение?
А в любом случае придется изучать "продукта жизнедеятельности",
даже если один работаешь. Можно только сдвинуть чуть-чуть границу
твой код, чужой, но все равно большая часть того, что твоя программа
запуститься и заработает зависит не от тебя (ОС, компилятор/интерпретатор,
стандартная библиотека твоего языка программирования и т.д. и т.п.).
И преимущество фреймворка, в том что из-за широты его использования
в разных проектах разными людьми его криво, косо можно заставить решить
большинство задач которые у тебя возникнут,
а вот собственная библиотека в этом смысле может потянуть на дно,
пара-тройка изменений в ТЗ, которые заставят отрефакторить
его на 90%, и можно скатиться к тому, что большую часть времени
выполняются не задачи, а допиливыается своя библиотека, чтбы потом
выполнить поставленные задачи, но до реальных задача из ТЗ могут
руки и не дойти.
S>Фреймворк вроде бы позволяет ускорить процесс разработки в n раз. Но при этом:
S>В итоге вместо изучения вещей базовых — тратится время на изучение продукта жизнедеятельности тех или иных авторов. Надоело вкрай.
S>Какое решение?
А в любом случае придется изучать "продукта жизнедеятельности",
даже если один работаешь. Можно только сдвинуть чуть-чуть границу
твой код, чужой, но все равно большая часть того, что твоя программа
запуститься и заработает зависит не от тебя (ОС, компилятор/интерпретатор,
стандартная библиотека твоего языка программирования и т.д. и т.п.).
И преимущество фреймворка, в том что из-за широты его использования
в разных проектах разными людьми его криво, косо можно заставить решить
большинство задач которые у тебя возникнут,
а вот собственная библиотека в этом смысле может потянуть на дно,
пара-тройка изменений в ТЗ, которые заставят отрефакторить
его на 90%, и можно скатиться к тому, что большую часть времени
выполняются не задачи, а допиливыается своя библиотека, чтбы потом
выполнить поставленные задачи, но до реальных задача из ТЗ могут
руки и не дойти.