Философия программирования. Некоторые принципы обучения

imageПреамбула

Доброго дня %user_name%. За годы накопленного опыта в сфере программирования у меня накопились некоторые наблюдения, заслуживающее того, что бы быть структурированными. Сегодня я поговорю о той части работы программистом где он соприкасается с необходимостью обучения. Постараюсь изложить некоторые неоднозначные принципы, а таких в программировании ой как много!



1. Программируйте как можно больше!

Кодить, кодить и еще раз кодить. Это то что чаще всего советуют более зрелые девелоперы начинающим. И кажется что этот совет действенный. Так и есть, но не совсем. Истинна намного глубже.

Для компании важно то, что бы каждый программист овладел инструментарием который используется на производстве и по возможности тот, который потенциально будет использоваться. Многие из начинающих программистов покупают толстенные книги по Android, Java EE, Qt или еще чему то что они используют на практике. Думаю все понимают что из этих книг усвоиться лишь та часть которую они действительно апробируют практикой в своих проектах.

Набрав некоторые знания программисты иногда начинают забавляться своими собственными задачами и все они сформированы следующим образом: «выбрать что-то что потенциально можно сделать теми средствами которые я знаю и реализовать на практике». Такой подход у 90 процентов молодого поколения. Которые начинают со временем оттачивать знания своего той области с которой они работают и ОЧЕНЬ замедляют свой рост как профессионала.

Мало кто изучив работу SQLite в Android начинает изучение ORM в связке с ORMlite если этого нету в его проекте на котором он задействован. Разумеется его код с каждым новым проектом становиться все более и более лучшим но… С того момента когда программист научился писать потоко-защищенный сингелтон каждый следующий инициативный проект в котором он его создает он будет попросту тратить свое время в холостую (быть может где-то на самом деле нужно использовать статическую фабрику?!?).

Сегодня существует целая армия программистов со стажем на Java которые уделяют не мало времени саморазвитию и довольно поверхностно знакомы с многопоточностью на практике ибо в их конкретных задачах это не требовалось!

Для того что бы активно расти над собой мало писать много, необходимо писать разнообразно. И да, это сопряжено с тем что вместо проторенного пути который программист может реализовать с закрытыми глазами необходимо выбирать что-то не изведанное, менее понятное и не всегда даже несущее прикладную выгоду (в каком либо конкретному случае). Выгодно ли это компании? НЕТ! Разумеется нет ибо такой программист может завалить сроки, создать потенциальные проблемы и вообще привести к состоянию когда часть кода придётся переписывать заново!

Выгодно ли это программисту? Могу смело утверждать что имея светлую голову на плечах спокойно можете перепрыгнуть с мидла (а иногда и джуна) на синьера за один-два года! Да это риск но он того стоит, да и в конечном счете необходимо помнить что каждый программист работает на себя самого да и компаний которые хотят взять себе толкового сотрудника всегда много.

2. Укладывайтесь в сроки

Сроки важны кампании. Они важны менеджерам которые не всегда хорошо разбираются в программировании. В крупных международных компаниях программисты часто жалуются на то, что сталкиваются с тем, что сроки вообще составляются чисто «бизнесами» без оглядки на разработчиков. Трудно последним объяснить зачем в этап разработки ПО включено тестирование без которого, как им кажется, процесс станет быстрее…

Несмотря на позицию менеджера/компании/начальника код должен быть протестирован! Unit тесты, это не панацея, но говорить о том, что дело уже завершено, нельзя, до тех пор, пока код не покрыт тестами. Работа программиста завершается не тогда когда «оно заработало», а когда вместе с ПЗ программист предоставляет следующее данные:
— сколько и при каких входных параметрах работает ПО;
— при каких типах входных параметров гарантируется на выходе корректный результат;
— какое поведение будет при некорректных параметрах подающиеся на любой (основной) модуль программы.

Без этого в сроки то может и уложитесь но надо понимать что в релиз программа выйдет с намного большим опозданием нежели изначально планировалось, так как минуя тесты выигрываешь битву но войну однозначно сливаешь…

3. Творите на этапе создания архитектуры

Хотите писать хорошие программы, изучите UML. Самый лучший софт который когда либо рождался из под моей клавиатуры был качественно спроектирован. Написанная архитектура должна быть масштабируема что бы легко включать потенциальные изменения (новые требования заказчика) без изменения архитектуры (ну или с минимальными изменениями). Так же качественная архитектура позволяет а самом раннем этапе создать ключевые характеристики программы и сформулировать требования к конечному продукту (по производительности или функционалу и т.д.). Именно тут можно составить все тесты для TDD.

Разработав архитектуру необходимо определиться с технологиями которые будут задействованы. После переходим к кодированию, где много времени придется потратить на изучение (смотри пункт 1), но НЕ творчество! Разумеется некоторые вещи можно реализовать по разному и это так же творчество, но думаю все же понятно о чем я сейчас. Придумали очередную «загогулину» и хочется ее тут же внедрить – поздно, подождите момента когда вновь будете творить концепты нового ПО, или новой версии. На этапе разработки и так хватает рисков связанных с реализацией концептов используя новые технологии или решения.

4. Всегда решайте причину проблемы

Очень часто программисты ставят проверку на null/NULL/0/etc в место того, что бы потратить время и понять почему стандартная системная функция вернула это нулевое значение, в то время когда не должна была! Важно знать суть, всегда, а не бороться с последствиями. Да, иногда решения требуют сейчас, и не дают времени на обучение и совершенствование мат. части. В таком случае лучше дольше посидеть на позиции джуна что бы иметь больше время для решения сложных проблем но все же учиться и еще раз учиться! Лишь тогда когда программист знает почему его приложение предсказуемо он может быть спокоен. Всегда стоит помнить что между знанием что ПО предсказуемо и знанием почему оно предсказуема пропасть в сотни часов обучения!

Послесловие

Многое сказанное у многих вызовет чувство не согласия. В первую очередь в вопросе того что все эти принципы стоит осуществлять на рабочих, боевых проектах. Я слышал у многих оппонентов точки зрения в стиле: все это да но применимо только на учебных проектах и не в коем случае не реальных где есть четкие сроки, требования, рамки. И в определенном смысле они правы, с одной оговоркой, если не начнете употреблять это все на всех своих проектах (как рабочих так и учебных) то скорость роста как специалиста резко уменьшиться. Ибо личное и свободное время не такое больше как рабочая неделя и исключение составляют те, у кого нет потребности работать, жизнь им подарила самый ценный ресурс – время которое в место работы можно тратить на саморазвитие и творчество перерастающее в прекрасный FrameWork, стартап, проект… Но все это тема еще одной статьи.
Поделиться публикацией

Комментарии 16

    +7
    Мне понравился пост. Советы, лично для меня, не новы, но вдохновляет.

    Автору:

    Уделяйте больше внимания русскому языку. Этот пост тяжело читать. Надеюсь, что следующие будут лучше в этом плане.
      0
      Спасибо за оценку и поддержку. Вы правы, русский язык у меня посредственный (и он для меня не родной,) но я буду стараться улучшать свои навыки.
      +2
      У вас кончились, держите: ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,.
        +2
        Спасибо. Теперь бы еще правильно расставить.
        +1
        Тесты для TDD не составляются, а пишутся. И не в момент продумывания архитектуры, а при вводе каждого нового элемента поведения.
          +3
          1 — спорно, 2 — кэп, 3 — чушь, 4 — кэп.
            +1
            Порадовала ваша лаконичность
              0
              См. ниже ;)
              +3
              Соответственно, конкретика:

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

              3. Ну как бы сразу отправляемся читать Мартина Фаулера и прочих agile-гуру.
                0
                Да ладно вам, зачем вы так сурово к автору. Просто если бы он оформил свою заметку в одно предложение:«Постоянно развивайтесь.» было бы удобней, но абсолютно бездейственно.
              +4
              Коллеги, не делайте так как пишет автор никогда.

              1. Изучение всего и много, очень хорошо пока вы учитесь, как правило это студенческие годы,
              тогда да, можно учить и линуксы и потоки и over 9000 языков и фреймворков. Это время поиска себя.
              К окончанию ВУЗа же, уже стоит найти свою нишу, то что больше по душе, и наращивать свои знания в этой области, потому как знать хорошо абсолютно все, невозможно. А отличное знание одной-двух-трех областей обеспечит вам и достойную жизнь и интересные задачи, с которыми приятно будет заниматься.
              Это не значит, что не стоит пробовать, что-то новое, конечно, стоит, но только когда вы овладеете на достаточном уровне чем-то одним(двумя-тремя).

              2. В наше время тестирование не закладывают в сроки только в самых дремучих и отсталых компаниях, не ходите туда работать. Не ходите работать и туда где сроки ставит только «Бизнес» — потратите нервы, испортите карму.

              3. Проектирование — это здорово. Но проектирование != UML. Проектируйте так как вам удобнее. Не проектируйте большими кусками, если вы не старый бородатый дядька с 20+ годами стажа, от вас этого и не потребуют. Скорее всего максимум, что вы лично будете проектировать, это некоторые модули классов не более чем на 50-70. Разбивайте проектирование на подзадачи. Не проектируйте до последнего метода, все равно придется менять.
              Что такое TDD автор не знает, никто не пишет ВСЕ тесты сразу после проектирования архитектуры. Тесты пишутся вместе с кодом. Автор, открываем Бека и читаем.

              4. Капитанщина. На деле, гуру рекомендуют покрывать внешние вызовы тестами. Конечно, если недоступны родные тесты используемых библиотек. Если же они есть, изучите их, тесты — отличные примеры и документация возможностей.

              В единственном я согласен с автором, хотя он высказал это в более мягкой форме — Пиши код блеять!
                0
                Благодарю Вас за информативный комментарий
                1. Я не совсем об этом. Дело в том, что в любой сфере всегда есть огромное поле для обучения. Более того, после универа я стал обучаться намного больше и активнее. Взять например Android, работая с данной ОС мой путь (в плане изучения) был таков: программирование на Java под эту ОС, далее полез изучать вспомогательные фреймворки (ORM, аннотации и.д.), потом стал писать на C++ и а далее и вовсе начал ковырять исходники Android. Некоторые навыки не пригодились, но 99 процентов полученных знаний дали прикладную отдачу. И мой перечень того, что я хотел бы выучить в данной платформе и близко не близиться к концу, а скорее наоборот растет;
                2. Не соглашусь, однако и опровергнуть в силу многих обстоятельств не могу;
                3. Спасибо за совет, я судя по всему действительно плаваю в терминологии и по этому не четко изложил свою мысль, но, очень постараюсь исправиться к следующей статье;
                4. В последнем пункте я совсем говорил не о тестах а о необходимости изучать «физику процесса». Сегодня очень много программистов привыкли исправлять следствия а не причины и это печально =(
                  +1
                  1. Безусловно, если вы изучаете Android, значит вы должны знать все об андройде. С этим я согласен. Я о том что не стоит изучать сегодня Android, завтра WP, после завтра Symbian. Мало того, положа руку на сердце, разницы в итоге не много, если представляешь общую канву построения мобильных приложений, то опираясь на опыт одной платформы, относительно не сложно путем сравнения перелезть на другую, если жизнь заставит.
                  2. Объясню свою позицию — жизнь коротка, а работы для нашей профессии сейчас очень и очень много и хорошей работы тоже очень много, не стоит тратить жизнь на работу, которая приносит много проблем и держит в постоянном стрессе. Человек проводит на работе большую часть своей жизни, поэтому от работы надо получать удовольствие.
                  3. Кстати я Бека не зря рекомендую, все-таки он основоположник TDD, мало того Java (с которой вы работаете) наверное, самая удобная платформа для TDD, для нее есть практически все нужные инструменты хорошего качества.
                  4. Если изучать физику процесса в каждом случае, то никакого времени не хватит (я не говорю про Just for fun, я именно про рабочую ситуацию), по идее рассматривать любое внешнее приложение/библиотеку стоит как черный ящик, до тех пор пока ее поведение соответствует вашим ожиданиям, если что-то пошло не так, тогда да, можно разобраться.
                    +1
                    Я думаю мы с Вами стоим на одних позициях, так как согласен со всем сказанным Вами.

                    1. Думаю что «универсальный» разработчик часто является поверхностным, углубиться можно действительно лишь в очень узкий круг вопросов. Это и плюс и минус одновременно.
                    3. Огромное спасибо!
                    4. И я о том же, проблема в том что при возникновении вне штатных ситуаций многие исправляют следствия. Например перехватывают частные (неверные) случаи которые возвращает библиотека и корректируют результат. Тем самым усложняют код не нужными эвристиками не изучив суть. В остальных случаях я согласен, нету ни малейшей возможности изучить все что используешь(по крайней мере не сразу).

                0
                Содержание слабо отражает первую часть названия статьи. Мне нравиться такой вариант: «Некоторые принципы обучения программированию».
                  0
                  Хотелось бы написать еще пару статей по теме, попытался выделить общее для них.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое