Поддержка  •  Дневник  •  Без рекламы  •  О сайте  •  Реклама  •  Поставить баннер  •  Fleshlight  •  Прислать  •  Хроника  •  Translate Гости: 4    Участники: 0 Авторизация Авторизация   Регистрация 
Метод Научного Тыка
RULVEN
Поиск  
Blackball iMag | интернет-журнал
Каталог


Начало » Разработка ПО » Как улучшить свой стиль программирования?
Мне повезёт!

Как улучшить свой стиль программирования?


Добавлено: Пн 12.03.2018 • Sergeant
Источник: источник
Просмотров: 187
Комментарии: 0


Исповедь 1

Я — разработчик. От своих работодателей я постоянно слышу, что работаю медленно и часто всё усложняю без веской причины. И что мне пора бы что-то с этим сделать. Во избежание.

Весь мой опыт программирования складывается из университетских работ и пары лет пребывания в различных компаниях. Критикующие меня люди неоднократно говорили мне, что в целом я разбираюсь в теме, так что я далеко не клинический случай, как можно было подумать. Однако, очевидно, я выработал совсем не те программистские привычки (как минимум, на взгляд работодателя) и мне нужно срочно изменить их. Везде, где бы я ни работал, мои решения, использующие иерархии мелких классов с делегированием поведения, признавались плохими. Говорят, будто так и надо писать, но это не так. Потому что всё это «как надо» может стоить мне работы.

Я начал читать книги. В них я видел все то же самое, от чего пытался убежать. Например: для одной разовой работы я воспользовался похожим кодом из другого проекта, для чего привел его к общему интерфейсу. Мой коллега, разбирая ошибку, наткнулся на этот код и спросил меня зачем я сделал всё так сложно для одноразовой-то работы. Но для меня это не одноразовая работа! Оба проекта очень похожи и тот же самый абстрактный код можно было бы использовать еще в нескольких.

Замечу, что люди, которые меня критиковали, всегда были значительно опытнее меня. Поэтому здесь два варианта: либо что-то не так со всеми опытными разработчиками, либо что-то не так со мной.

Человек, оставив это сообщение на одном из популярных англоязычных ресурсов, попросил о помощи. Признание проблемы — половина решения. Человек искренне не понимает, что от него хотят и всей душой желает исправиться.

Решения мирового сообщества разделились на четыре группы:
1.«Забить», т.к. опытные программисты — просто дураки. И если они долго проработали, это еще не значит, что они опытны (много голосов).
2. Спросить у критиков, как бы они структурировали код (столько же голосов).
3. Напроситься программировать в пару / сходить на курсы (немного голосов).
4. «Ну так пиши проще!» — нет никакой гарантии, что требования к новым проектам хорошо лягут на заботливо разработанный интерфейс (1 голос).

Все эти советы не выходят из области, в которой сформулирован вопрос, и потому не могут решить главную проблему — «Так что мне сделать, чтобы улучшить свой стиль программирования?» Пункт 4 подбирается ближе всех, но всё же далек. Проблема глубже.

Что делать?

Ролевые игры. Часть 1

Вы и ваш двойник открыли бизнес по автоматизации чего-нибудь. Конкретно вы из вас двоих — директор.

Какая у вашего двойника часовая ставка? Возьмите калькулятор и поделите цифру, указанную в трудовом договоре на 160. Если вы совершаете эти действия в рабочее время, то поделите результат еще на 60. Вот на столько (+20% льготной ставки в ПФР + 0.2% за травматизм + 6% УСН (половину можно зачесть из налогов ПФР) = +23.2% минимум) вы нагрели своего работодателя, развлекаясь здесь со мной. Знаете, как выглядит миллион рублей? Вспомните объем (и, особенно, качество) написанного вами за последний год — вот это и есть миллион. Стоит покупать ваш труд? Вы, уже как директор, купили бы?

Рано или поздно вы подойдете к другому себе с простым вопросом «Когда будет готово?», с рациональным предложением «Работай быстрее» (потому что ты дорого мне обходишься) и с мудрым советом «Делай проще». Вас от души забавляют объяснения двойника, почему сроки затягиваются, потому что до того как стать директором, вы сами «отмазывались» точно так же и знаете, что за этим стоит.

Теперь ваш двойник оказался в той же ситуации, как и человек из первой исповеди. Вопрос в том, признает ли себя ваше второе я частью проблемы или спишет всё на начальника и прочие внешние обстоятельства.

А теперь, внимание, большой секрет. Для, вас, как директора, он уже никакой не секрет, а очевидная мысль — вам не нужны программисты. Вам надо решить проблему. Может, стоило заказать программу в другом месте или купить готовый модуль или вообще ничего не автоматизировать, а нанять людей на низкую зарплату. На текущий момент вы уже потратили 600 тыс. и не получили никакого пригодного результата.

Большой Секрет Еще Раз: программисты никому не нужны. И программы тоже. То есть совсем. Людям интересны они сами, их проблемы и некоторые другие люди. Просто так получилось, что часть проблем можно решить написанием кода. Если бы те же проблемы решались струганием деревянных дощечек и покраской их в зеленый цвет, и это было бы дешевле — так бы и делали.

Если из всей статьи вы готовы запомнить лишь одну мысль, то запомните эту: Программирование не самоценно, а программисты — обслуживающий персонал.

Эта мысль может вас задеть — всё нормально. Чем раньше вы примете её, тем более ценным специалистом вы сможете стать. В нашей культуре считается, что лучше быть господином, нежели слугой. Но если подумать, то общество и вы находитесь в некоторых отношениях. В этих отношениях вы можете занять роль «добровольного слуги» и общество (в лице работодателя и довольных клиентов) щедро вознаградит вас за вашу заботу.

Ролевые игры. Часть 2

Зайдем с другой стороны: ваш двойник — директор, а вы — разработчик.

К вам вот-вот заглянет директор, а фабрика абстрактных автоматизаторов еще не дописана, SQL-запросы не отлажены да и вообще за полгода пришло понимание, что всё должно быть не так.

Дилема: никто не хочет работать тяп-ляп. Все хотят гордиться свое работой. Следовательно: (логическая ловушка) Да, я делаю медленно, зато правильно.
Если с «медленно» всё ясно, то что такое «правильно» — совсем не очевидно. На самом деле всё просто. «Правильно» — это когда за отведенный срок (±) появляется пригодная к использованию программа или сервис. Если ваше другое понятие «правильно» не приводит к появлению пригодного к использованию продукта за разумный срок, то ваше «правильно» никуда не годится. Тут нет простора для маневра. Вспомните, что программирование не самоценно.

Работа занимает всё отведенное на неё время. Если разработчику дать в три раза больше времени, он не напишет в три раза лучше. Он напишет в три раза больше кода того же качества, которое обычно выдает. Поэтому, всеми силами старайтесь получить нечто рабочее. Любой ценой. Ваша цель — работающая программа, неважно как написанная. Есть много т.н. называемых «грязных проблем» — это такие проблемы, которые непонятно как решать, пока не попробуешь решить. Пример: краш-тест машин. «Грязные» проблемы всплывут во время первого прохода и их можно будет учесть во время чистовой работы. Желательно, чужими руками.

Второй Большой Секрет: код — это всегда плохо. «Красивого» кода не бывает. Чем меньше кода, тем лучше. Любой код содержит ошибки, компромиссы и проблемы производительности.

  • Меньше классов, меньше функций, меньше кнопок, меньше связей и вообще — меньше.
  • Не пишите обобщенную функцию, если её функционал не встретился минимум три раза в разных местах.
  • Не пишите функции и методы класса до того, как у них появится пользователь. Т.е. сперва где-то появился вызов метода и только потом появился сам метод.
  • Вам не нужно три уровня наследования с шаблонным классом посередине.
  • Стандартный модуль вполне способен решить вашу задачу — почитайте еще раз документацию.
  • SQL — не единственное в мире хранилище. Очень много всего можно запросто хранить прямо в файлах в JSON.
  • Не думайте о системе «на вырост». Другие требования — другая система. Не пытаться строить в деревне небоскреб — это и есть архитектура
  • Этот алгоритм O(n^2) можно не оптимизировать до O(n logn), потому что в данном месте n никогда не больше 5, поскольку означает число задействованных пальцев на руке.
  • Вместо написания генератора таблицы её можно один раз сверстать в HTML — она незначительно меняется раз в полгода.
  • SVN — отличная система контроля версий. Особенно, когда вместе с вами её используют непрограммисты, работающие с вами над одним проектом.
  • Вам действительно нужно попиксельное освещение для визуализации мат.модели или стандартного GL_SMOOTH хватит? И, кстати, мы будем показывать её на выставке на 7-летнем ноутбуке со встроенной графикой.
  • Правда думаете, что цикл на итераторах работает быстрее, чем на индексах, особенно если сравнить первый и второй со временем доступа к диску?
  • Похожие классы в двух проектах — не повод связать один с другим. Считайте это случайным совпадением. Если вы сделаете общий класс, то отныне, при любом изменении, вам придется думать о двух проектах одновременно. Стоит ли это того? Вряд ли.
  • Доска с маркером + телефон с камерой отлично заменяют UML-диаграммы и большую часть программ прототипирования интерфейсов

 

Программист, принимающий во внимание коммерческие следствия своих решений, ценится на вес золота. Стив Макконел.

Исповедь 2

Всем привет. Я — руководитель группы разработки. От своих разработчиков я постоянно слышу, что они не успевают. Я понимаю, что мои разработчики могли бы работать быстрее (и даже заметно быстрее), если бы не усложняли всё без веской причины и почаще заглядывали бы в документацию. И мне пора бы что-то с этим сделать. Во избежание.

Весь мой опыт программирования складывается из школьных «проб пера», олимпиад, университетских работ, дополнительного образования, преподавательской деятельности, домашних проектов и 8 лет успешной работы в мелких, средних и крупных компаниях. В целом, я разбираюсь в теме. Очевидно, я выработал «те» программистcкие привычки (как минимум, на взгляд работодателя) и считаю нужным поделиться ими. Везде, где бы я ни работал, мои решения никогда не страдали манией «переиспользования». Говорят, будто так писать не хорошо, но это не так. Потому что всё это «как надо» может стоить работы не только мне.

Я читал книги и продолжаю читать. В книгах есть всё. Я пишу код почти каждый день (включая выходные: мне нравится писать код) и почти каждый день читаю документацию. У меня всё получилось далеко не сразу. Но я точно знаю, что терпение — самый короткий путь. Я никуда не спешу, потому что быстро — это медленно, но каждый день. Я отвязан от языка, парадигм, технологий и всего остального технофетиша. Мне просто нравится делать полезные программы для людей. Решать проблемы.

Замечу, что люди на похожих позициях (и самые продуктивные разработчики), придерживаются схожих мыслей. Поэтому здесь два варианта: либо что-то не так со всеми опытными разработчиками, либо что-то не так с…

P.S.
Третий секрет. Начните писать к commit'ах пользовательскую ценность добавленного кода. Не «добавил два метода», а «Теперь пользователю быстрее/легче/меньше...» или «появилась функция / изменилась реакция». Вам нечего написать? Вы ничего не сделали за день.



Мне нравится 0   Мне не нравится 0



Комментарии

Чтобы добавить видео с YouTube, нужно написать [@youtube=xxxxx] , где xxxxx – ID видео.


Комментарии: 0
Нет ни одного комментария.
RSS-лента
Поделиться ссылкой:
5 ошибок при разработке высоконагруженных сервисов 5 ошибок при разработке высоконагруженных сервисов
15 рецептов фрикасе из курицы на любой вкус 15 рецептов фрикасе из курицы на любой вкус
Скумбрия, запеченная в духовке: 15 лучших рецептов Скумбрия, запеченная в духовке: 15 лучших рецептов
Кривые развития программиста и немного об эффекте Даннинга—Крюгера
Мини стейки для канапе Мини стейки для канапе
Чай каркаде: полезные свойства и вред Чай каркаде: полезные свойства и вред
Кубанский комбинатор
Условные сигналы среди водителей
Кличка
Имитаторы свинга Имитаторы свинга

Новое
20 отличных рецептов куриных сердечек на мангале вчера, 09:06
20 отличных рецептов куриных сердечек на мангале
Какие полочные акустические системы стоит выбрать в 2023-2024 годах? Ср 15.05.2024
Какие полочные акустические системы стоит выбрать в 2023-2024 годах?
Архитектуры разработки ПО Пн 13.05.2024
Архитектуры разработки ПО
Сб 11.05.2024
Технический долг. Как не обанкротиться
Что такое технический долг и как им управлять Сб 11.05.2024
Что такое технический долг и как им управлять
20 рецептов из горбуши, которые станут вашими любимыми Сб 11.05.2024
20 рецептов из горбуши, которые станут вашими любимыми
Как работает спидометр в машине: вы всегда хотели это знать, но никто не мог объяснить на пальцах Ср 08.05.2024
Как работает спидометр в машине: вы всегда хотели это знать, но никто не мог объяснить на пальцах
5 ошибок при разработке высоконагруженных сервисов Пн 06.05.2024
5 ошибок при разработке высоконагруженных сервисов
20 способов приготовить куриные голени в духовке Вс 05.05.2024
20 способов приготовить куриные голени в духовке
Жаркое из курицы: 20 лёгких и вкусных рецептов Сб 04.05.2024
Жаркое из курицы: 20 лёгких и вкусных рецептов
Книги
Designing Data-Intensive Applications Вт 14.05.2024
Designing Data-Intensive Applications
Год: 2017
Fundamentals of Software Architecture Вт 07.05.2024
Fundamentals of Software Architecture
Год: 2020
Refactoring with C# Вт 23.04.2024
Refactoring with C#
Год: 2023

Разработано на основе BlackNight CMS
Release v.2024-05-19
© 2000–2024 Blackball
Дизайн & программирование:
О сайтеРеклама
Visitors
Web-site performed by Sergey Drozdov
BlackballРекламаСтатистикаПоддержка | МузыкаПлейлистыКиноВидеоИгрыАудиоПрограммыСтатьиКартинкиЮморФорумДневник сайтаПрислать контент