Это снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений.
Аннотация
Закончил Факультет информационных технологий НГУ. За шестилетнюю профессиональную карьеру успел позаниматься как веб-интерфейсами автоматизированных систем на Java (и в какой-то момент чуть не умер со скуки), так и аудитом и проектированием различных интерфейсов пользователя. В данный момент работает веб-экспертом в компании Xored, Академгородок, Новосибирск.
- Докладчик
- Никита Прокопов
В докладе я расскажу о двух принципах написания кода, которые, как это обычно бывает, самые важные на свете и про них все забывают (или не знают).
Первый принцип — принцип простоты. На примерах будут рассмотрены проявления культа сложности у программистов и, обратно, преимущества постоянного упрощения и те прекрасные места, куда оно может привести.
Второй принцип — забота о пользователе. Вещь не менее очевидная, но и про нее часто забывают при разработке продуктов; в программировании, кажется, такая постановка вопроса в голову приходит людям еще реже. Назовем этот принцип коллего-ориентированным программированием.
Доклад строится вокруг примеров популярных инструментов разработчика, библиотек и фреймворков, личного опыта автора. Будет полезен начинающим программистам; заблудшим людям; тем, кто ищет правду и лучшего будущего для нас всех.
Видео
Видео в HD-качестве, смотрите в полноэкранном режиме.
HTML-код включения <iframe src="http://player.vimeo.com/video/23726142?byline=0&portrait=0" width="720" height="405" frameborder="0"></iframe>
- Скачать
http://ftp.linux.kiev.ua/pub/conference/peers/addconf/2011/1a2-philosophy-of-simplicity-prokopov.avs.avi
Для этого доклада нужен подкаст (аудиозапись)?
Примечания и отзывы
У Никиты Прокопова был интересный доклад о философии простоты, но снабжен он был не самыми лучшими (и даже местами возмутительными!) примерами. Нельзя же брать юниксовые команды с кучей параметров и на их приемре показывать как это неудобно по сравнению с однокнопочными интерфейсами, это же сравнение теплого с мягким! Но тема конечно затрагивает любого разработчика ПО.
И мысль правильная: максимальная простота во всем - наша цель. Кроме неудачных примеров никаких возражений тема не вызывает.
©
Весь доклад был построен на двух основных принципах:
- Первый принцип — принцип простоты.
- Второй принцип — забота о пользователе.
Доклад интересный, хотя ничего нового, вроде и не рассказал. По поводу не совсем корректных примеров уже писали. При повторном просмотре виде сложилось впечатление, что рассказывает сам для себя, причем местами слишком быстро, наверное, слайдов слишком много.
В остальном все нормально. Посмотреть, думаю, стоит, особенно любителям все усложнять. ©
Следующим был Никита Прокопов с выступлением про простоту. Задорное название предвещало веселье в духе, скажем, опуса Павла Кудинова про кошерные костыли. А получилось чуть менее чем полностью унылое ношение воды решетом. Кроме довольно неумелых попыток затроллить линуксоидов нечего и вспомнить. Ни фана, ни трюков. Предложение автора бороться со сложностью методом ее игнорирования категорически не поддерживаю. ©
Философия простоты. С одной стороны я со всем в докладе согласен, с другой — и чего об этом рассказывать, вроде все очевидно.
Интересный доклад.
Основная мысль — о том, что программисты часто реализуют сложные решения по разным причинам. И часто — внутренне тяготеют к сложным решениям. А правильно — стремиться к простоте. Поэтому лекция — еретическая, против культа сложности программиста (используешь сложный редактор — крут).
В проблемной части достаточно много экстремистских примеров — про простоту, которая игнорирует разнообразие мира. Я вижу реальные причины — разные люди, разные задачи, в которых востребовано разное использование продукта. С другой стороны, сложность растет и по другим причинам — накапливаясь исторически, или из-за отложенных решений. Все это надо убирать (рефакторинг), но этого не делают.
Экстремизм в проблемной части не мешает предлагаемым решениям быть вполне конструктивными:
- Вопросы Почему и Зачем
- Забота о пользователе
- Использовать шаблоны только когда они нужны, а не тотально по коду
- Коллего-ориентированное программирование — думайте о своих товарищах
Да, многие решения очевидны. Только в реальном мире почему-то не слишком используется :(
Я: Решение могут быть в синтезе и за плоскостью, типа общезначимых конфигов, отделенных от конкретных систем в примере с конфигами и настройками. Об этом в докладе не было. Еще было достаточно много спорных примеров улучшения решений. Однако сам доклад — безусловно интересно слушать, он будет собственные мысли.
Доклад-напоминание о том, что нужно думать о тех для кого пишешь, и о тех, с кем пишешь, не усложнять им жизнь лишний раз.
Не все советы, к сожалению, применимы к нашим системам. Например ответ на сакраментальный вопрос «Кто кого использует — пользователь систему или система пользователя?» далеко не всегда очевиден.
Проще для пользователя
- Обновления системы должны быть незаметными для пользователя
- не требовать его внимания
- не тратить его время
- не удивлять его резкими изменениями
Хороший пример — Google Chrome
- Система должна сама выполнять рутинные операции по собственному обслуживание
— плохой пример — Git, где тупую команду по сжатию БД репозитория пользователь должен запускать сам
- Не должно быть диалогов с одной кнопкой, тем более модальных — не нужно тратить время пользователя там, где он ничего не решает и не может сделать
- Не надо выносить внутренний мир программы на пользователя — очень мало пользователей способны читать стеки
Проще для программиста (Коллего-ориентированное программирование)
Главный принцип — YAGNI, «you aint gonna need it».
Слишком сложные структуры
- Интерфейсы с единственной реализацией — зло
- Использование паттернов только ради паттернов — тоже зло
Еще был сомнительный пример, главным тезисом которого было что Hibernate — это плохо, потому что в нам 4000 классов. Я его понимаю так — плохо то, что использовать приходится все 4000 классов, нельзя взять только то, что нужно.
такая простота тоже недешево обходится — монолитные системы создавать проще
Закрытость
- Sealed(final)-классы. Упрощают жизнь разработчику фреймворка, но сильно портят его пользователям. Автор привет в пример Wicket, но c Uni.Net у нас те же проблемы(
Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.