Comments 20
Спасибо, интересная тема.
Предпоследний абзац повторяется дважды, дважды.
Вообще, есть т.н. «спиральный подход» для «чистолистов», когда прототип выбрасывается нафиг. А для того, чтобы это не бесило, и проще было делать прототипы, есть языке с развитой системой типов — Хаскель, к примеру.
И там прототип делается на типах — которые можно рассматривать как очень маленькую дублирующую приблизительную реализацию. Соответственно, когда мы пишем прототип только на типах, оставляя кругом undefined, мы пишем мало, это легко выбрасывать и переписывать. А потом дырки undefined уже можно заполнять.
Дважды поправил, спасибо.
Да, у меня тоже спиральный подход, я даже думал это упомянуть, но решил не перегружать заметку. Но в моей спирали с сразу пишу небольшой код с ограниченной но законченной функциональностью, а потом пишу следующий вариант больше, на основе первого опыте. Это мне легче, чем сначала слепить кучу из вторсырья.
Ну да. Вообще для разных подсистем можно писать каскад прототипов.
Но вот языки с разработанной системой типов позволяют при должном умении писать "приблизительные программы". То есть, вместо детальной реализации алгоритма, вы пишете из каких типов в какие он работает. И если в мелочах вы более-менее правы, то всю систему целиком проверит компилятор. Таким образом, можно делать "наброски".
Но вот языки с разработанной системой типов позволяют при должном умении писать “приблизительные программы”.
ООП-языки тоже позволяют при должном умении разрабатывать программы сначала начерно, с заглушками на месте функциональности, а потом переписывать набело, с функциональностью. Но умение тут нужно уже другое.
Я, обычно, свой код как деревце выращиваю
Сначала появляется базовая реализация чего-то. Потом она постепенно расширяется слоями. Стараюсь придерживаться простой архитектуры, не овердизайнить раньше времени. Если в текущей архитектуре становится тесновато, ну, значит, настало времени её порефакторить
Иногда рефактиринг сводится к тому, чтобы по-другому посмотреть на имеющиеся вещи. В таком случае, изменения в коде минимальны, но могут быть переписаны комментарии или переименованы какие-нибудь штуки - обозначая пересмотренное направление развития, в которое то, что уже есть, более-менее аккуратно укладывается, как частный случай
Исключительно плохие примеры любителей отладки выставляют тут их (нас) в плохом свете и, на мой взгляд, несправедливо.
Полагаю, у всех когда-то был коллега, кто мог отправить в продакшн довольно большой кусок кода, ни разу его не запустив. Это был бы пример некомпетентного чистолиста.
Я сам предпочитаю как можно скорее запустить приложение, чтобы начать отлаживать. Пусть даже оно полностью состоит из заглушек, но главное, что все, что я пишу после того, как оно запущено - я могу потрогать, проверить любое предположение, поиграться со структурой данных и отладить, если что-то пошло не так. В целом в руках подержать то, что пока получается. При этом я редко использую готовый код и предпочитаю обходиться минимальным набором инструментов, когда возможно, а архитектура решений, которые получаются в итоге ничем (я надеюсь) не выдает того, что я не чистолист. Просто подход в том, чтобы думать и делать чередуя, а не разделяя эти процессы.
Я тоже стемлюсь запустить быстрее, но делаю для этого законченную версию с подмножеством фич. А потом иду на другой круг спирали, и делаю версию с большим количеством фич. Стараюсь избегать заглушек и копипасты того что не планирую иметь в будущем.
Я собственно не против людей которые предпочитают отлаживать, а не писать. Я против постановки таких тандемов, где те, кто склонен к отладке и имеют ограниченный опыт, ставится определять архитектуру, а люди с опытом в определении архитектуры - ставятся чтобы это очищать, особенно если он не любит процесс отладки вообще и отлаживать сделанный наспех чужой код в частности.
Тут намечается классификация разработчиков по ещё одному признаку
Одни способны придумать архитектуру из головы, а потом описать её в коде. Ну, по крайней мере, они говорят, что так могут. Живьём я такого не видел (чтобы архитектура при этом получилась удачная), но стандартные практики менеджмента считают такой сценарий развития желательным
Другим надо потрогать вещи руками, чтобы мысли стали на место. А без этого как-то не получается.
Часто выход для этих вторых в написании прототипов перед написанием настоящих реализаций.
Я тоже вру иногда, что делаю прототип, чтобы от меня отвязались. Но почему-то в конечном итоге прототип и становится финальной реализацией :)
Пришел я в начале 2000х на проект, где было заявлено что MySQL так крут что индексы не нужны, студенты писали, проект в продакшене заметно тупил, изучил запросы, добавил индексы и все залетало. Кто я был тогда? чистолист или кодокопатель?
Ахах, узнала в себе образцового чистолиста :D пока мои друзья обсуждают новый фреймворк, на котором «легче и быстрее» писать, я хвастаюсь за голову, понимая, сколько там будет дебага с такими призрачными ограничениями
К счастью авиация очень консервативная отрасль, до сих пор NOTAM через сеть AFTN передаются, то есть по факту через телеграф. А вы говорите ИИ ))
Изучил задачу;
Написал реализацию;
Исправил опечатки;
Работает!
Использую дебагер эпизодически, обычно для поиска segmentation fault или посмотреть стэк вызова, вообще не понимаю как можно более сложные ошибки найти с помощью дебагера.
И продукт, и подкомпоненты многократно переписываются прежде чем достигнута прочная и при этом гибкая структура. Это нервирует менеджмент.
Я - явный чистолист, но в целом обхожусь постоянным вялотекущим рефакторингом вместо многократного переписывания. В остальном всё сходится.
Отладчиком иногда пользуюсь в качестве калькулятора :)
Вот классификация - в точку. Именно так все и происходит в реальной жизни. Но термины такие "чистолисты" и "кодокопатели" (хотя они и передают суть - претензий нет) - ранее не встречались.
У меня по жизни сложилось впечатление, что написание своих программ и понимание чужих программ (оно же - программная археология) - это два разных навыка. А объединяет их только необходимость понимания, как работают программы: вообще или на конкретном языке, и приемов программирования. А дальше для написания собственных программ требуется умение творить: создавать абстракции и делать из них архитектурные решения, а для чтения чужих - умение понимать: реконструировать ход мысли другого человека, выделять используемые им абстракции и прояснять для себя созданные на их основе архитектурные решения. IMHO эторазные умения, хотя и некоторым образом связанные: например, знание типовых приемов программирования помогает в обоих случаях.
Чтобы вы поняли масштаб проблемы, скажу что в налабанном коде товарищ, назовем его Петей, использовал трехмерные массивы там где нужно было использовать дерево, и их в разных местах кода тройным циклом обходил.
Конкретно в этой истории самым интересным является то, как Петя прошел испытательный срок и как ему позволяли творить такую дичь в коде.
Ну он продержался конечно слишком долго (типа полгода), но потом его то ли уволили с концами, то ли отправили в отделение в другой стране с переводом на другой род деятельности. Этот момент я так и не понял, но мне пришлось все это экстренно переписывать, и я о нем больши никогда не слышал.
Тогда насколько релевантно судить о программистах вообще на базе таких персонажей, которые при нормальном отборе вообще не должны были бы дойти до работы?
Ну это был экстремальный случай попытки менеджмента использовать энергичного молодого человека чтобы что-то быстро написать с идеей подчистить это опытным. Правда и менеджмент в той компании был необычным - в нем сильную роль играл мужчина-HR со своими теориями как управлять инженерами. Такого я не видел ни до ни после - в нормальных компаниях HR-тетеньки вообще не лезут в управление проектами, а сосредоточены чисто на объяснении бенефитов и слежении, что все прошли тренинг по сексуальному харазменту.
Те, кто не любит отлаживать — против тех, кто не любит писать