Comments 16
Для менеджеров любого уровня просто не интересно находиться в одной комнате с собственными представителями какой либо корпоративной разработки.
С представителями других фирм можно красиво посидеть, кофе с печеньками попить, по-болтать о гольфе, инвестициях, к ним командировки тонной напланировать, ещё лучше, если это другая страна итд...
Заголовок желтушный. Название должно быть - "Большие проекты убили вузовскую романтику". У автора всегда есть выбор - 400к в Амазоне, либо 70к в обычной компании из 20 человек. В линкедыне у автора какие-то полу-лид-консультант на Коболе и Джаве. Очередной разрушитель корпораций, который не смог вписаться в среду. Да, я вижу, что это перевод.
Вообщем то реализация задачи простейшим методом - это лучшее решение почти всегда. Не зачем усложнять, терять надёжность, повышать вероятности ошибок как в процессе написания, так и в процессе поддержки.
Не простейшим. Понятным. Или хорошо задокументированным. Утрируя: если быстрая сортировка нам сэкономит вагон денег, готовы ли мы пожертвовать пузырьком? Или таки наймем людей, которые смогут читать и поддерживать быструю сортировку?
Для конкретного продукта пузырька либо достаточно либо недостаточно. Если недостаточно, то наймут квиксортеров и так и будут поддерживать квиксорт. Если достаточно, зачем нанимать квиксортеров.
А еще я против того, чтобы поддержка фиксила баги. Продуктовую команду надо тыкать носом в их какашки и пусть они учитывают их на будущее.
Но ты же не ответил на вопрос. Ты просто написал "лучше хорошо, чем плохо". И сидишь - собираешь лайки от безработных студентов и реакт-кодерков. У тебя в задаче нужно хранить куча настраиваемых параметров. У тебя 2 выбора - константы в коде иди БД в соседнем репозитории, который тоже нужно покрывать тестами и делать PR's. Потом еще делать PR's в конфиги с заглушками. И только потом твой основной PR. И это всё из-за того, что продукт в 1кк строк кода и нужно много метрик по аналитике и остальному. Ну, студент-пузырёк за вечерок, что будешь делать?
Простейший по каким критериям? Нужно извлечь список пользователей- что проще, ORM или SQL? Что бы вы не выбрали всегда можно добавить требование которое сделает другой вариант простейшим. А это вырождается в зоопарк "тут было быстрее с SQL поэтому переложи свой список доменных объектов в список айдишников" ну и наоборот. Потом приходит архитектор который код уже 10 лет не писал и заявляет что все проблемы от отсутствия единообразия и вообще все объекты теперь храним как JSON потому что их так перекладывать легче.
Идти по пути наименьшего сопротивления это очень естественный процесс, однако не удивляйтесь что попадете вы только в локальный минимум.
Энтерпрайзные проекты убили профессию разработчика
Огляделся вокруг, увидел кучу людей на профессии "разработчик".
"Слухи о моей смерти преувеличены".
Есть противоположное мнение. Стандартизация ничего не убила, а сделала отрасль более доступной для более широкой аудитории.
Автор противопоставляет стандарты и своё желание доводить код до предельной оптимизации. Результат почти всегда находится где-то раньше по времени, чем максимальная оптимизация, и она попросту не нужна никому кроме разработчика. У каждого свои приоритеты, у меня вообще читаемость кода, а по теме статьи отвечу цитатой:
Преждевременная оптимизация — корень всех зол. © Дональд Кнут
Преждевременная оптимизация — корень всех зол. © Дональд Кнут
Цитата шикарная, слов нет. Вроде всё по делу сказано.
Только вот в реальности, люди прикрываясь этой цитатой пишут просто отвратный код. Потом ведь оптимизируем, когда поймём где оптимизировать. Опять всё логично, сначала ведь надо понять, где оптимизировать...
Проблема только в том, что в подавляющем количестве случаев "потом" не наступает. И никто не разбирается где надо оптимизировать. Не то что не знает как, а просто у него уже другие задачи. Хотя большинство и не знает как) И до оптимизации доходит только когда, условно, "прод падает".
Так вот и живем с этим уже много лет. 8 ядер по 2.2Ггц + 8Гб памяти в моём свежем андроиде с трудом могут отрисовать плавно скроллинг смс-ок. Странички с обычным контентом на сайте ставят на колени Core i7 и отъедают гигабайты памяти. Приложения жиреют в нехилой прогрессии не добавляя особо функционала... и т.д. и т.п.
А зачем оптимизировать-то? Вот когда жареный петух клюнет, тогда и займёмся, а пока не надо. Просто докупите памяти, новый мобильник или сервер...
Энтерпрайзные проекты убили профессию разработчика