Комментарии 15
Чтобы познать дао кода, нужно написать много кода. Не написав много кода ты не познаешь ничего.
Ещё надо читать умные книги, да и не просто читать, а критически оценивать то, что пишут. Развивать системное мышление, общаться с людьми — пользователями, понимать их проблемы, которые решает ПО.
Это необходимое, но не достаточное условие. Важен не сам опыт, а его осмысление. Человек может годами воспроизводить одни и те же ошибки, и если он не способен в достаточной мере анализировать свои решения, то он может написать хоть тысячу строк, хоть миллион, но это ему слабо поможет.
Это превосходный пример узкого фокуса: целью было открыть замок с минимальным усилием.
Или наоборот, кто-то смотрел достаточно широко, чтобы задуматься о необходимости минимального подтверждения намерений пользователя перед потенциально небезопасным действием.
Да, такое поведение может быть опцией, но никак не действием по-умолчанию. Я бы туда еще и опциональную защиту проверкой отпечатка или кодом добавил — а ну как смартфон украдут, а пользователь не любит блокировку экрана?
Мне кажется, что проблема с приложениями ровно обратная — их облегчают настолько, что не остается даже элементарных опций, позволяющих использовать приложение более чем одним путем.
Мне кажется, что проблема с приложениями ровно обратная — их облегчают настолько, что не остается даже элементарных опций, позволяющих использовать приложение более чем одним путем.
Всё зависит от контекста. Если это входная дверь в квартиру, то я 10 раз подумаю над мыслью а стоит ли автоматизировать её открытие.
Если же мы разрабатываем систему дверей между отсеками на условном крейсере «Ентерпрайз», то автоматическое открывание по какому-то идентификатору личности, передаваемому по беспроводному каналу вполне может оказаться уместным.
Если же мы разрабатываем систему дверей между отсеками на условном крейсере «Ентерпрайз», то автоматическое открывание по какому-то идентификатору личности, передаваемому по беспроводному каналу вполне может оказаться уместным.
Кто то ломится в дверь. Подошел глянуть — упс, дверь открылась…
Типичный сюжет для ночного кошмара: кто-то ломится в дверь, я подхожу к ней и вижу что все замки почему-то открыты и остался один, который тоже открывается на глазах, и дверь уже начинает приоткрываться. Я начинаю спешно запирать, они снова отпираются…
Забавно узнать, что в реальности такой сценарий тоже возможен, да.
Забавно узнать, что в реальности такой сценарий тоже возможен, да.
Все эти манагерские песни быстро сменяются на противоположные, когда приходит время исправлять баги и вносить изменения в дизайн. "Нужно быть flexible" или даже (боги упасите) "разбираться в чужом коде". Т.е. когда нужно хренак и в продакшен — никто, кроме инженегра, не печётся о дизайне (фактически — о будущем). Дизайн, рефакторинг — это всё потом, а сейчас нужно быстро и грязно удовлетворять клиентов.
Здесь просто разные интересы. У разработчика — свои, а у манагера — свои. Соответственно, разработчик должен аргументтировать свою позицию и защищать свои интересы (чтобы потом исправлеия/изменения не были мучительной болью). Не дали время на вдумчивое исправление дизайна — извиняйте, в следующий раз проблемы будут потяжелее.
Кажется, программисты забыли о предназначении программного обеспечения — решать проблемы реального мира.
Если мы используем Bluetooth и предполагаем, что владелец телефона может войти в дом, зачем заставлять его доставать телефон и нажимать кнопку? Пусть дверь сама отпирается, когда телефон находится в радиусе 1 метра. Не нужно тратить время на дизайн и код графического интерфейса!
Этот вывод должен делать ux-проектировщик/продакт/аналитик/манагер/etc, а не разработчик.
программисты забыли… вывод должен делать ux-проектировщик/продакт/аналитик/манагер/etc, а не разработчик.
Споры об определениях
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Цель важнее кода