Комментарии 12
Есть продукт, который делают разработчики, исходя из собственноручно сформулированных требований. Есть продукт, который делают разработчики(возможно те же самые), исходя из требований, сформулированных заказчиком.
С чего вдруг одно будет разительно отличаться от другого? Непонятно…
P.S. Ну и если продолжить аналогию, то самым верным решением будет не пицца на вынос и не ресторан, а свой собственный повар, знающий все вкусы и привычки(всю внутренюю кухню, хе-хе).
Про рекламу не соглашусь. Реклама направленная на поиск штучного дорогого заказа потребует больше бюджета, чем реклама массового дешевого тиражного решения(при одинаковой отдаче от рекламы).
Если вы заказываете разработку с нуля у проверенных и зарекомендовавших себя разработчиков, можете быть уверены в двух вещах:
Этот код легко масштабируется, меняется, поддерживается и дополняется не только теми, кто его писал, но и любыми другими разработчиками.
На практике в этом как раз уверенным быть нельзя. На практике заказчик становится таким же заложником команды, как и в случае коробки. Вот только команда коробки имеет больше стимулов к обеспечению стабильности и качества релизов, чем команда разработки.
Конечно ключевое слово "проверенных и зарекомендовавших себя разработчиков", но это имеет отношение только к тем руководителям, кто создает далеко не первый свой проект, и по каждому он прошел с этой командой долгий путь доработок и решения проблем. И то, даже в этой ситуации нельзя быть уверенным — пришел другой прожект, сменился лид — и из идеальной команды поперло "как у всех"
Для небольших проектов это сойдет. Ну слепили мобильное приложение из кусков кода с того же стекоферфлоу, выкатили его в маркет, монетизировались на встроенной рекламе и забыли.
А для чего-то большого и долгоживущего не прокатит. Там быстро столкнетесь с тем, что тут слишком много ресурсов жрет, там слишком медленно работает, здесь вообще конфликтует с другим процессом в драке за разделяемый ресурс (кто ж из коробочников мог догадаться, что на ваш глобус кроме их совы еще будет дятел из другой коробки натягиваться...)
Это все решается за деньги. Но я не говорил, что коробка хорошо. И даже не спорил с тем, что заказная разработка даст продукт гораздо более кастомизированный, чем коробка. Я опровергал то, что заказная разработка даст более поддерживаемый и качественно написанный продукт, потому что она просто не заинтересована это делать, ибо оперирует деньгочасами =) И мой опыт работы с заказной разработкой с обеих сторон это подтверждает =)
Ну и заказная разработка точно так же облажается с нагрузкой, ибо там обычно усредненная квалификация и сильных архитекторов нет, которые изначально подложат соломку, а когда упало — быстро составят план как поднять.
И, к слову, локдаун показал это, когда на некоторые магазины, активно использующие аутсорс команды, свалилась огромная нагрузка и одни неделями не могли хоть как-то стабилизировать свои интернет-магазины.
Вот такой пример. Один (хотя их на самом деле можно выкатить вагон и маленькую тележку). Есть у нас документ, который называется «Нефункциональные требования к функционалу на платформе IBMi». В нем очень много чего написано. Для примера, вот такой пункт:
Использование MERGE для больших объёмов данных запрещено. На время выполнения создаются блокировки записей в количестве кратном выполненным изменениям, что при большом их объёме приводит к замедлению работы сервера.
Вот скажите — кто «из коробки» будет отказываться от MERGE для добавления/обновления пары тысяч строк в пользу более «кодоемких» решений просто потому что в конкретных условиях одного из пользователей это начинает тормозить т.к. данный процесс работает не один, а среди еще тысячи-другой процессов, какие-то из которых тоже обращаются к этому файлу?
И, повторюсь, таких требований у нас не одна страница. И все они «выстраданы». Есть целый пул «задач на оптимизацию» где переписывается исправно работающий код просто потому что он неэффективен и оказывает существенное влияние на загрузку и общую производительность системы в целом. Вот как это можно делать в случае «коробочных решений»? И кто этим должен заниматься? Коробочники? А оно им надо? Они свое уже получили с продажи коробки.
Поэтому, если человек при возникновении любой задачи упорно… у меня для вас плохие новости — вам достался тупой программист.
Все это верно но для тупых бизнес-систем. Если IQ выше 90 не тратьте свою жизнь на это, если есть выбор. Все эти «достаточно неглупые люди» на самом деле самодуры c мнением, глубоким и обоснованным, как у чат-бота.
Закалив свой ум в битве с серьезными задачи человек редко генерирует всякие глупости.
что за ересь. конечно нужно использовать чужой опыт. но не писать своё, а всё копировать со stackoverflow? на хабре?
наша цель как разработчиков есть подстраиваться под задачу, а не подстраивать задачу под нас, этим пусть интеграторы занимаются
Этот код написан специально под ваш бизнес
Этот код легко масштабируется, меняется, поддерживается и дополняется не только теми, кто его писал, но и любыми другими разработчиками.
Вы сами в это верите? код будет написан под ваш бизнес, но вероятность того что он будет ЛЕГКО масштабироваться и меняться близка к нулю.
Писать код так что бы он легко менялся и масштабировался надо уметь, дело не в том что бы писать под бизнес, дело в том что бы уметь так писать и не лениться так делать.
Сколько живу — ни разу не видел. У Яндексов спросите сколько раз они переписывали свои приложения и сколько там легаси, кода унаследованного и в котором ни кто ни когда не будет разбираться, который при необходимости — заменят другим, но ни когда не будет в нём разбираться.
Чего ждать от коробочных приложений?