Comments 25
Не совсем согласен с таким подходом. О будущем думать нужно. Пример: в Jira SDK нет нормальной поддержки транзакций, хотя если бы о них подумали заранее, боли было бы гораздо меньше. Вот история вопроса для тех, кому интересно: https://jira.atlassian.com/browse/JRASERVER-25808
Пытаться предугадывать надо не конкретные вещи, а те места, где изменения наиболее возможны и стелить абстракции заранее. Этим наверное и отличается новичок от неновичка: опытный знает, где можно быстро навернуть говнокода, взяв техдолг, а где техдолг будет не очень к месту.
А теперь скажите то же самое банкам, которые ищут COBOL-пенсионеров для новых фич в ПО.
В последнее время наблюдаю поворот "обратно к истокам", когда начинают ругать чрезмерный ООП подход, большую иерархию классов и over-engineering. Вон, новый-модный Rust без классов и наследования живёт и многим нравится.
Но нужен опыт. Пусть у нас есть Заказ и телефон. И нам потребовался добавить ещё один телефон.
И можно к полю user_phone добавить что-то вроде user_phone_alt и все.
А можно по-взрослому: делать список, в базе 1-ко-многим, динамическую форму с кнопками "добавить доп. телефон", "убрать телефон"...
Кто какой подход выберет? Чем обоснуете?
Плясать нужно от бизнеса. Если бизнес зуб даёт, что нужен только один альтернативный телефон, а ресурсов на масштабируемое решение не даёт - нужно добавлять поле в таблицу. Это будет быстро и просто, бизнес будет доволен. Но нужно объяснить бизнесу заранее, что если потом он захочет масштабируемое решение, то переделывать будет сложнее, чем если сделать такое решение сразу.
Правда в реалиях итераций может быть больше:
Один номер, зуб даю
Да, два, больше ни в жисть
Почту бы
ICQ номер надо
Мдя, да лучше бы это были "контактные данные"
...
Притом стоит отметить что это пример не из вариантов прокручивания фарша назад
Вполне возможно, что именно так всё и будет. А может и не будет. Задачи нужно решать здесь и сейчас и теми средствами, которые на это выделены. Всё предусмотреть заранее всё-равно невозможно.
а потом смотришь в код и кровавые слезы
Если код сразу был хорошо отрефакторен, то нет )
ага - сказали проверять что значение в диапазоне - индус так и сделал...
а про null ему не сказали)
Притом, естественно вокруг этой строчки кода выстраиваются машиночасы ci/cd и человекочасы организации испытаний, внедрения; следом отработка приёма багов и второй круг дополнения строчки проверкой на null )
Зато бурндаун красивый и ттм минимизируется)
Вообще-то, в новом-модном Rust иерархия всего навёрнута такая, что классическим ООП языкам и не снилось.
Где в Java у любого объекта есть hashCode() — там в Rust есть трейт Hash с методом hash, принимающим внешний Hasher.
Или взять реализацию sid::io::stdin(), которая возвращает Stdin, реализованный внутри как &'static Mutex<BufReader<StdinRaw>>. А у StdinRaw внутри лежит std::sys::stdio::Stdin, реализация которого зависит от платформы. Так, у std::sys::windows::stdio::Stdin внутри структура IncompleteUtf8, являющаяся буфером переменной длины от 0 до 4х байт и 16х-битный временный суррогат.
О, люди открыли для себя экстремальное программирование
Ещё бывает так, что разработчики видят возможность полезной фичи, маркетинг одобряет, а потом сейлзы делают из этого "уникальное торговое предложение" и заказчики оценивают. Редко,правда, но выстреливает.
Рациональное зерно тут есть, конечно. При этом грамотная архитектура сильно облегчает дальнейшее развитие. Но даже она не исключает траблов с добавлением некоторых фич. :)
по моему предсказание предсказанию рознь, мне кажется стоит разделять расширяемость и код написанный на будущее.
Ну примером расширяемости можно считать разделение логики сразу на model - view - controller даже в проекте который крайне прост в первой версии
А примером кода на будущего это написание каких-то функций в моделе которые быть может понадобятся в следующей версии
Вроде и то и то написано на будущее, но разница весьма солидная
А бывает, что ты стараешься заложить архитектуру на века и чтобы она была масштабируемая и в тоже время простая для потомков. И десять лет она действительно так и работает и бизнес расширяется, а потом из-за ошибок менеджмента бизнес закрывается и вместе с ним все твои красивые фичи просто выкидываются вместе с серверами. Не частый кейс, но в текущих реалиях вполне возможный.
В общем, это палка о двух концах. С одной стороны, действительно хочется увековечить себя своим кодом. А с другой стороны, действительно не знаешь как повернутся события.
Уверяю вас, на самом деле вы этого не знаете. Если повезет, потребности можно угадать, ну, может, в одном случае из десяти. В остальных девяти вы будете понапрасну тратить силы и усложнять систему в попытках приспособить под будущее то, что либо претерпит изменения, либо вообще не пригодится.
Хочу обсудить данное высказывание в целом и дополнить статью (как оригинальную, так и перевод), чтобы она была более полной, так как я не совсем согласен с высказыванием в том виде, в котором оно написано.
В первую очередь, каждый член команды - от руководителя, менеджера до разработчика, сотрудника отдела кадров и т.д. это часть компании. Каждый из них делает свою работу и приводит компанию тем или иным образом к успеху. Нельзя сказать, что кто-то лучше, а кто-то хуже.
Если экстраполировать данную мысль на статью, то "диктатура бизнеса" и "бизнес точно знает как делать деньги" это ложь. В первую очередь, все мы - люди. В первую очередь, важно человеческое отношение ко всем внутри всех отделов и между отделами. В первую очередь, важна хорошо выстроенная коммуникация и полное понимание и уважение между коллегами.
Каждый разработчик имеет полное право предложить пути и способы улучшения бизнес процессов, идеи по увеличению прибыли, идеи по улучшению корпоративной культуры и улучшения имиджа компании. Открытость к идеям - это ключ к росту бизнеса.
Следующий момент заключается в том, что я безусловно согласен с тем, что "тайное добавление кода на будущее" это плохо. Не стоит пытаться единолично сформировать решение всех проблем компании и закрыть все возможные исключительные случаи и создать систему, которая будет работать при любых входных данных - это не эффективный подход.
Аналогично, эту мысль мы можем экстраполировать и на Бизнес, он не может принимать эффективные решения самостоятельно, он не может знать как создать продукт, который через год-два не станет не поддерживаемым камнем, добавление новых фич в который будет невозможно.
Из этого, мы делаем вывод, что основа успешного бизнеса - это коммуникация. Бизнес хорошо понимает, чего бы хотел конечный пользователь от продукта в данный момент, а IT-отдел хорошо понимает как создать продукт, который будет работать, масштабироваться и будет легок в поддержке. Ключ здесь в том, чтобы бизнес был заинтересован в том, чтобы его продукт не сыпался от багов и каждая новая фича не создавала очередную волну нагрузки на Техническую поддержку и Отдел по работе с клиентами, а IT-отдел должен бережно относиться к тем средствам, которые, безусловно, затрачиваются на разработку.
Подводя итог последней мысли - нужно чтобы каждый четко понимал текущие цели и ключевые метрики по каждой фиче, компоненту, модулю, проекту в целом. При "диктатуре бизнеса" вы рискуете прийти к тому, что ваш разработчик и IT-отдел это набор "болванчиков", которые даже не понимают зачем были выпущены все те фичи, которые они разработали за последние месяцы-полгода-год.
Выводы которые хотелось бы здесь сделать:
1) Не тратьте деньги бизнеса понапрасну, то есть не пытайтесь принимать решения в одиночку. Вы - команда, проект - коллектив. Всегда нужно выносить свои идеи на обсуждения более чем с 1 человеком и, желательно, более чем из одного отдела (это, кстати, работает не только на проекте, но и в жизни в целом).
2) Не создавайте "культ бизнеса" и "культ все вокруг тупые, а я умный" (применимо ко всем сторонам конфликта). Помните о том, что каждый из нас в первую очередь человек, а не бог или гений, отдельно взятый человек может многое, но может и во многом ошибаться.
3) Объединяя первые два пункта - важен баланс, никогда не стоит фокусироваться либо только на бизнесе, либо только на Технической части. Важны все компоненты и все члены команды. Фокусируйтесь на эффективном управлении, эффективной коммуникации и работе над проблемами внутри компании.
Спасибо!
За что человеку минус, все правильно говорит. Разработчик если сам решил написать лишних фич или пытаться подумать за бизнес, лучше бы встретился с этим бизнесом и обсудил. По опыту знаю, что обычно сразу и становится понятно что надо делать, а что нет и, главное, всем понятно почему, включая и бизнес, и разработчиков.
Как справедливо было замечено в других комментариях, ситуация ситуации рознь. От себя добавлю, что с годами приобрел понимание, что нужно делать даже если никто не просит, и это позволяет меньше тратить время в дальнейшем. Уже не на первом рабочем месте получается работать по следующей схеме: полгода/год в достаточно жестком режиме, выстраивая архитектуру нужным образом, потом 2-3 года со значительным запасом свободного времени и минимальным временем на maintenance и техдолг. Это работает если вы тимлид с полномочиями по организации работы и принятию технических решений. Второе условие - нужно немного залезть в бизнес и понять как он устроен.
Мне кажется понимание простоты, лёгкости и достаточности для написания "расширяемого" кода можно достичь лишь с опытом, и в первую очередь с опытом понимания того как работает организация которая потребляет твои продукт.
Добавлю к статье абстрактный пример основанный на реальных событиях: старались писать просто и очевидно, с минимальной затратой по времени. Уточнили по 28 раз у аналитиков, заказчика, попробовали так и сяк, пописали тесты и пришли к выводу что действительно некоторая сущность в системе будет уникальной, единственной и незаменимой. Ну в итоге пару месяцев разработки, все хорошо. Год поддержки и наращивания функционала - все хорошо. Приходит заказчик и заявляет что теперь нужны 2 уникальных штуки. Оцениваем что переписывание всего накопленного, с учётом "не уникальности" - это ещё месяца 3.
Да, с одной стороны, если бы мы сразу не поверили заказчику и предусмотрели вариант, то возможно разработка была бы тебе 3 месяца, но в том числе и поддержка была бы дороже. Год положительной работы дал возможность заказчику легко пойти на длительную переделку, а если бы заложили сразу сложнее.. ну история не любит "если бы")
Вывод один: все нужно считать, как и нужно быть готовым к любым изменениям!)
Не пытайтесь приспособить свой код к будущему