Я ж не спорю, что жить надо. Просто в данном случае апеллировать надо не к свободе прессы, которая к рекламе никакого отношения не имеет, а к каким-то другим факторам. А то, как только реклама блокируется, сразу вопли об ущемлении свободы прессы.
Интересно, кто-нибудь напомнил истцам, что свобода прессы заключается в том, чтобы озвучивать на страницах издания свое мнение, а не в том, чтобы публиковать рекламу?
Правительство хочет создать структуру, которая будет повторять коммерческую? Те хотят бабла заработать, эти — распилить и подсидеть начальника. Дитя умрет во чреве.
Кстати, Ваши наработки для игр — это частные решения, которые становятся частью большого решения — фреймворка. И его тоже очень условно можно назвать CMS :)
Игры — да. Движок, который используется потом в десятках других игр и бизнес-приложение, каждое из которых суть другая разработка — разные вещи.
Терминалы — да. Они остаются терминалами и решают одну задачу. По сути, это CMS, обвешанная кастомными гуями и плюшками, об чем уже написал.
Что касается следующего коммента, никто и не просит дергаться между разными областями. И слава Богу, что Вы спец в определенной области :) В Вашей области переиспользование кода только на благо.
Кстати, так далеко метаться между областями не стоит :). Даже два кастомных веб-сайта практически гарантируют, что это будут уникальные решения без переиспользования кода.
Я в разработке уже тыщу лет, работал и на заказ, и для in-house, сделал многие десятки проектов. Делал и по нескольку в одной команде, и в разных. Это предпредисловие :)
Ведь то что пишешь для одного проекта можно потом использовать и в другом
Если вы спросите меня, в каком из своих проектов я использовал готовый код из других, то я отвечу предсказуемо: ни в одном. Серьезно, ни в одном. Дело не в том, что не хотелось, просто все проекты были разными. Даже те, которые не отличались кардинально от предыдущих. Разумеется, эта разница касается кода, который используется в бизнес-логике, разные там логгеры и мониторинги не в счет. Мы же о коде, который выполняет бизнес-задачу, правильно? Вот об этом и говорю.
Можно использовать архитектурное решение, но, если оно сделано по уму (паттерны-шматтерны), то в следующем проекте вы будете использовать именно паттерны-шматтерны, а не конкретное решение, потому что для другого клиента реализация будет другой.
Повторно использовать то, что пишешь для одного проекта, ты, скорее всего (ни разу не факт), будешь в 2 случаях:
Когда ты продаешь решение, которое потом будет частью большого проекта. Пример — CMS.
Когда ты продаешь проект, который является долгосрочным, и однозначно уверен, что он будет дорабатываться. Если уверен!
Это было предисловие.
В данном случае Petrovich_Z решал конкретную задачу, и ему нужна была конкретная функциональность. И он ни разу не был уверен, что что-то там будет дорабатываться потом. Посему здесь уместно и должно использовать KISS. Решать ровно ту задачу, которую нужно было решить.
Не стоит придумывать элегантных универсальных решений там, где их быть не должно. Хотя, простое решение тоже может быть элегантным :) А вот когда нужно будет вернуться к фиче повторно (мы же не уверены, что к ней вообще надо будет возвращаться) и начать ее расширять, вот тогда имеет смысл реализовать свои фантазии, потому что вероятность третьего возврата к фиче будет гораздо больше. И то не факт :)
Как-то так.
На объявление о вакансии PHP-разработчика откликнулось порядка 120 человек.
… из всех присланных резюме, осталось только 60.
Напомнило.
Сидят 2 HR-а — опытный и новичок. Опытный берет пачку резюме и говорит: «Ну что, начнем разбираться?», делит пачку пополам и половину выбрасывает в мусорное ведро. Новичок в шоке. Опытный: «А на фига нам неудачники?»
Дополню.
Показать же можно уже через спринт какое-то цельное и работающее решение. Пусть оно будет в виде тележки, подвозящей провод от генератора к площадке запуска, но оно будет работать.
Даже простой канал до Луны не строится мгновенно и в одно действие. Такой высокий уровень абстракции легко разбивается на подзадачи, а если речь идет о разработке ПО, декомпозировать задачи до 8-16 часовых подзадач — дело вполне реальное.
Довольно интересно. Есть одно уточнение. Вы путаете точность оценки с четкостью (иногда ее еще называют качеством)
Вам нужно самостоятельно прикинуть диапазон стоимости проекта. Оценка будет неточной. Диапазон – очень широким
Пример — «Проект займет от 1 до 3 месяцев». Вы уложились в 2, и это означает, что оценка была точной. Но нечеткой. Четкая оценка — «на реализацию фичи требуется 30 часов». Но вы, предположим, потратили 36, и это означает, что оценка, при всей ее определенности и четкости, была неточной. В данном случае точная оценка — от 30 до 40 часов.
Терминалы — да. Они остаются терминалами и решают одну задачу. По сути, это CMS, обвешанная кастомными гуями и плюшками, об чем уже написал.
Что касается следующего коммента, никто и не просит дергаться между разными областями. И слава Богу, что Вы спец в определенной области :) В Вашей области переиспользование кода только на благо.
Кстати, так далеко метаться между областями не стоит :). Даже два кастомных веб-сайта практически гарантируют, что это будут уникальные решения без переиспользования кода.
Если вы спросите меня, в каком из своих проектов я использовал готовый код из других, то я отвечу предсказуемо: ни в одном. Серьезно, ни в одном. Дело не в том, что не хотелось, просто все проекты были разными. Даже те, которые не отличались кардинально от предыдущих. Разумеется, эта разница касается кода, который используется в бизнес-логике, разные там логгеры и мониторинги не в счет. Мы же о коде, который выполняет бизнес-задачу, правильно? Вот об этом и говорю.
Можно использовать архитектурное решение, но, если оно сделано по уму (паттерны-шматтерны), то в следующем проекте вы будете использовать именно паттерны-шматтерны, а не конкретное решение, потому что для другого клиента реализация будет другой.
Повторно использовать то, что пишешь для одного проекта, ты, скорее всего (ни разу не факт), будешь в 2 случаях:
Это было предисловие.
В данном случае Petrovich_Z решал конкретную задачу, и ему нужна была конкретная функциональность. И он ни разу не был уверен, что что-то там будет дорабатываться потом. Посему здесь уместно и должно использовать KISS. Решать ровно ту задачу, которую нужно было решить.
Не стоит придумывать элегантных универсальных решений там, где их быть не должно. Хотя, простое решение тоже может быть элегантным :) А вот когда нужно будет вернуться к фиче повторно (мы же не уверены, что к ней вообще надо будет возвращаться) и начать ее расширять, вот тогда имеет смысл реализовать свои фантазии, потому что вероятность третьего возврата к фиче будет гораздо больше. И то не факт :)
Как-то так.
Золотые слова. Сторонникам подхода «а давайте напишем универсальный расширяемый код» посвящается.
То есть, это не за счет инновационных разработок, пущенных в производство?
Вопрос риторический, ответа от Чубайса не жду :)
2. Не контролируются владельцами сайта
Напомнило.
Сидят 2 HR-а — опытный и новичок. Опытный берет пачку резюме и говорит: «Ну что, начнем разбираться?», делит пачку пополам и половину выбрасывает в мусорное ведро. Новичок в шоке. Опытный: «А на фига нам неудачники?»
Показать же можно уже через спринт какое-то цельное и работающее решение. Пусть оно будет в виде тележки, подвозящей провод от генератора к площадке запуска, но оно будет работать.
Пример — «Проект займет от 1 до 3 месяцев». Вы уложились в 2, и это означает, что оценка была точной. Но нечеткой. Четкая оценка — «на реализацию фичи требуется 30 часов». Но вы, предположим, потратили 36, и это означает, что оценка, при всей ее определенности и четкости, была неточной. В данном случае точная оценка — от 30 до 40 часов.